3 ms·

There must be some end user (positive) impact of memory compaction in Java. But I do not see in benchmarks where Java programs takes 2-10 times more memory and

• the8472 10y ago
  Those benchmarks are of limited use since the JVM has startup costs which get armortized over time. Full performance is only achieved after JIT warmup. AOT would improve that, but on openjdk that's experimental and few people use other JVMs that support AOT out of the box. About the memory footprint: The runtime is larger, so there's a baseline cost you have to pay for the JITs. But baseline != linear cost. If you have a long-running applications that run more than a few seconds and crunch more than a few MB of data those numbers would change. So unless you're using the JVM for one-shot script execution those benchmarks are not representative. And if you do then there would be certain optimizations that one could apply. > There must be some end user (positive) impact of memory compaction in Java. Fewer CPU cycles overhead per unit of work, i.e. better throughput, which does seem to be an issue for gogc[0]. No risk of quasi-leaks in the allocator due to fragmentation. Reduced cache misses[1] [0] https://github.com/golang/go/issues/14161 https://github.com/golang/go/issues/14161 [1] http://stackoverflow.com/q/31225252/1362755 http://stackoverflow.com/q/31225252/1362755
  • geodel 10y ago
    > About the memory footprint: The runtime is larger, so there's a baseline cost you have to pay for the JITs. But baseline != linear cost. I do not think so. Here is explanation about Java memory bloat in typically used data structures. https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...
    • the8472 10y ago
      That is true - although typed arrays will solve that in the future - but the benchmarks you cite (e.g. fannkuch-redux) still run into a memory floor created by the larger runtime. Also, `regex-dna` will probably benefit from compact strings in java 9. And some of the longer-running benchmarks are in fact faster on java, so I think that supports my point about warmup.
      • igouy 10y ago
        > (e.g. fannkuch-redux) still run into a memory floor Yes, apart from reverse-complement, regex-dna, k-nucleotide, binary-trees. > Also, `regex-dna` will probably benefit from compact strings in java 9. Do you actually know that com.basistech will re-write their library to use compact strings? > I think that supports my point I think that's called cherry picking.
  • igouy 10y ago
    > Those benchmarks are of limited use since the JVM has startup costs which get armortized over time. -- Benchmarks are of limited use. -- Are JVM startup costs significant? http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
• zigzigzag 10y ago
  The end user benefit is stability. A runtime that compacts the heap cannot ever die due to OOM situation caused by heap fragmentation, whereas if you don't compact then the performance of an app can degrade over time and eventually the program may terminate unexpectedly.
• funny_falcon 10y ago
  binary-trees benchmark is much faster on Java than on Go.
  • igouy 10y ago
    > faster on Java than on Go go version go1.7 linux/amd64 OP "Sub-millisecond GC pauses in Go 1.8"