News for hackers. Stuff that matters.
Re:Allocation on the JVM: Down the rabbit hole by alblue on Tuesday July 12, 2016 @12:56AM (#12076832)
One other way of finding how much memory is used is to enlist JMH's -prof gc option to see what gets generated between runs. I used this to see what StringBuffer did in http://alblue.bandlem.com/2016/04/jmh-stringbuffer-stringbui...

You can run the test with and without C2 (eg with -Xint) to see the effects on the inlining/escape analysis, and (on Linux) with -prof asm to see where the code is taking time.

Re:Allocation on the JVM: Down the rabbit hole by haneefmubarak on Monday July 11, 2016 @07:56PM (#12075710)
So... Why exactly does it need 24 bytes if a long is only 8 bytes (64 bits)?
Re:Allocation on the JVM: Down the rabbit hole by kaushiks on Monday July 11, 2016 @07:59PM (#12075721)
For the 16 byte (on x86_64) header (markOop, klass *).
Re:Allocation on the JVM: Down the rabbit hole by jcdavis on Monday July 11, 2016 @08:09PM (#12075770)
The header is only 12 bytes with compressedOops (which most people use), but the long is aligned on an 8 byte boundary so the advantage is wasted here.
Re:Allocation on the JVM: Down the rabbit hole by alblue on Monday July 11, 2016 @11:27PM (#12076543)
And even if the long wasn't on an aligned boundary, the object itself is. So you either have padding at the start or end of the object.
Re:Allocation on the JVM: Down the rabbit hole by antoaravinth on Wednesday July 13, 2016 @12:38PM (#12087551)
I always love to see the under hood concepts. I open articles like these and give up reading half way through. As the text goes I will be lost in air. Is there any book which explains JVM underhood process? If so it will be great!