22 ms·
Was this done with the G1 garbage collector brought in by Java 7 if not this is worth a new test. It fixes a lot of problems that used to be introduced, and as
by gravypod 11y ago
Was this done with the G1 garbage collector brought in by Java 7 if not this is worth a new test.
It fixes a lot of problems that used to be introduced, and as long as you let it run wild with memory, and you are doing some parallelized work like everything real world, you should not see this problem.
There should be either no more, or less, stop the world.
There are a few things you can do to also avoid this problem all together:
The biggest improvement in speed vs memory will come from not passing primitive as function parameters. When you are doing this, you are passing-by-value, not passing-by-reference. If you wrap a bunch of ints to a function that you are using you can save a lot of allocation cycles.
Another good change that you can make would be an object pool. There is a really good and fast implementation in JMonkeyEngine/LWJGL. They have a low level, thread happy, object pool.
- needusername 11y agoSee the logs he posted [Full GC [PSYoungGen: 10752K->9707K(142848K)] [ParOldGen: 232384K->232244K(485888K)] 243136K->241951K(628736K) [PSPermGen: 3162K->3161K(21504K)], 1,5265450 secs ] -> parallel old A full GC frees 140k of old 1045k of young memory. He's almost running out of memory with parallel old. He needs to run a way larger heap. G1 isn't going to be any better with a live set the size he has in combination with his max heap. All this explained in Java Performance [1] http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/0137142528 http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/01371...
- polyfractal 11y agoJust a note, G1 probably still isn't ready for rock-solid production usage. E.g. bugs like this are still cropping up: https://bugs.openjdk.java.net/browse/JDK-8148175 https://bugs.openjdk.java.net/browse/JDK-8148175 That's a pretty scary bug. Who knows how stuff like that will trash your data if you aren't properly checksumming everything. CMS and other GCs have the advantage of years of bug-squashing and tuning. G1 is exciting, but I wouldn't personally use it on anything important for quite some time.
- gravypod 11y agoThat bug does not seem to effect Java 7, it only mentions 8u80 and 9. Still very bad though.
- polyfractal 11y agoYep, just more recent versions, and it's been fixed too. But if you watch the bugs that keep popping up for G1 you see stuff like this fairly regularly. Of course, that's a totally unfair comparison: CMS has had a decade of bug squashing...I'm sure it had equally scary bugs when it was new. But that's the point. Don't use new, shiny GC's because they are still squishing bugs :) (Sorry, preaching to the choir, I just get frustrated by everyone claiming G1 will solve all their problems without investigating potential downsides)
- needusername 11y agoActually CMS is only five years older than G1. The first published papers for G1 are from 2004. But yes, G1 has a long history of scary bugs. There was a time a few years ago where practically every week a crashing bug was fixed. G1 addresses certain problem areas of CMS and replaces them with others. Honestly I hope in ten years from now we have better choices in HotSpot than CMS or G1 but right now it doesn't look like it (if you don't count Shenandoah with has other issues). Having that said I have recently seen G1 performing exceptionally well in production: 120ms GC pauses with a 120 MB/s sustained allocation rate with basically default settings (apart from GC logging).
- kev009 11y agoIt seems semi-common to run HBase with G1GC now days.