News for hackers. Stuff that matters.

A comment on 3 billion items in Java Map with 16 GB RAM. Parent comment

Re:3 billion items in Java Map with 16 GB RAM by Tharkun on Sunday November 11, 2012 @02:22PM (#4770306)
With each consecutive insert in the collection, the available memory shrinks, the GC detects this, and attempts to free some of it. As long as more memory (the 15GB) can be allocated, this isn't much of a problem. However, at some point there is hardly any memory left: the 15GB is all but allocated, and very little memory can be freed with each run. So the GC runs ever more often, to the point that it starts to slow down the system.

Before you say "well that's stupid", realise that the alternative would throwing an OutOfMemoryError, in which case the JVM would terminate. A slow JVM is better than no JVM.

[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by fcoury on Sunday November 11, 2012 @02:27PM (#4770321)
I disagree. A slow JVM can go on and on and the perception may be that the system is up. I think in this scenario a fail fast is much more interesting, since in a normal system, the fact that the JVM is down would trigger some manual intervention which seems like is needed anyways.
[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by spartango on Sunday November 11, 2012 @03:22PM (#4770471)
I might like the JVM to fail-fast rather than plod along in a bogged down state, but if I did, I wouldn't want it to wholesale crash (throwing an OutOfMemoryException), but instead have my monitoring system start to throttle the work its doing and get other processes to help out (scaling).

Indeed, you can do this; the JVM has simple facilities to report the memory use and heap status, which you can monitor and use to proactively scale around the bogged-down VM.

[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by eonwe on Sunday November 11, 2012 @03:04PM (#4770419)
You can get such functionality in Oracle's JVM by using the command line option -XX:+UseGCOverheadLimit.

This will cause OOM-exception to be thrown when at least 98% of program time is used in garbage collection and at most 2% of the total memory is reclaimed in such collections.

[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by markokocic on Sunday November 11, 2012 @06:09PM (#4770905)
Java GC is one of the finest pieces of engineering. It can be configured and tweaked in million[1] ways to provide one with the behaviour that he wants to see.

[1]http://www.oracle.com/technetwork/java/javase/tech/vmoptions...

[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by suresk on Sunday November 11, 2012 @02:52PM (#4770383)
The behavior you want, I think, kind of depends.

Regardless, since Java 6 (I think), if the GC time becomes excessive (where "excessive" means x% of time is spent in GC and less than y% of memory is reclaimed in each GC cycle), an OutOfMemoryError will be thrown. This can be disabled.

[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by scott_s on Sunday November 11, 2012 @05:07PM (#4770736)
Failure as default is usually not a good policy for a runtime system.
[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by SoftwareMaven on Sunday November 11, 2012 @06:05PM (#4770886)
Failure as a default is how Erlang manages to keep systems up with 5+ 9's reliability. The difference is that, with Erlang, the entire system and the applications built on it are designed around that.
[ Parent | on HN ]
Re:3 billion items in Java Map with 16 GB RAM by scott_s on Sunday November 11, 2012 @06:12PM (#4770922)
When there is high memory pressure, the default behavior in Erlang is to fail rather than continue garbage-collection?
[ Parent | on HN ]