[concurrency-interest] @Contended (JEP-142)

Nathan Reynolds nathan.reynolds at oracle.com
Fri Nov 30 12:00:06 EST 2012


Heap analysis tools have to guess at is the size of a reference and 
header.  The tool doesn't know if the heap dump was taken on a 32-bit 
JVM, a 64-bit JVM with compressed references or a 64-bit JVM with 
uncompressed references.  Some tools use some heuristics to guess at the 
size of the reference and hence guess at the header size too.  Field 
padding is going to make this even more difficult because the tool now 
has to guess which processor it was running on.  It would be very 
helpful if the heap dump would provide size information to make object 
size calculations accurate.  Inaccurate object size information pushes 
for the wrong optimization projects.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Architect | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
On 11/30/2012 7:32 AM, Vitaly Davidovich wrote:
>
> Why is header reported as 12 bytes? Should that not be two words (16 
> bytes on x64)?
>
> Yeah, the state I'd like us to be in is for heap analysis tools 
> working offline (I.e. against an hprof file) to have enough info to be 
> able to indicate to the user that the object size has padding 
> applied.  The existing 8 byte alignment is well understood/realized so 
> people doing size estimates in their head take it into account.  But 
> 128 byte padding per field may cause some confusion :).
>
> Sent from my phone
>
> On Nov 30, 2012 9:17 AM, "Aleksey Shipilev" 
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
>
>     Oh yes, but the same argument applies for "just" the gaps in field
>     layout due to field alignment.
>
>     This is a very simple proof-of-concept experiment, take the regression
>     test from the @Contended patch:
>
>         // int1 is padded
>         public static class Test2 {
>             @Contended               private int int1;
>                                      private int int2;
>         }
>
>     ...and run it with
>     https://github.com/shipilev/java-field-layout
>
>     ...it will show you:
>
>     $
>     ~/trunks/jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java
>     -javaagent:target/field-layout.jar -cp
>     target/field-layout.jar:/home/shade/trunks/jdk8/hotspot/test/runtime/8003985/
>     net.openjdk.tools.fieldlayout.MainAnalyzer Test8003985\$Test2
>
>     Test8003985.Test2
>        (header 12 bytes)
>       12   4             int Test2.int2
>        (gap 128 bytes)
>      144   4             int Test2.int1
>     Instrumentation reports 280 bytes per instance
>
>     ...the correct layout via Unsafe, and the exact object size,
>     aligned to
>     word size. So that info is available in VM. jhat/MAT, however,
>     will show
>     this object to retain only 24 bytes. AFAIK, this is just the glitch in
>     Hotspot's HPROF dump code, which we can fix.
>
>     -Aleksey.
>
>     On 11/30/2012 05:48 PM, Vitaly Davidovich wrote:
>     > Right,  but I meant that the tool will report proper size but
>     developer
>     > looking at that number may not immediately understand why the
>     reported
>     > size is larger than expected if padding is applied.  If the tool can
>     > know that @Contended is present, it can indicate that to the
>     developer.
>     > I'm not familiar with the heap dump file format so don't know if
>     there
>     > will be enough info for the tool there.  I don't think
>     instrumentation
>     > applies here as the tool is interpreting a dump file and not
>     profiling a
>     > live application?
>     >
>     > Sent from my phone
>     >
>     > On Nov 30, 2012 8:41 AM, "Aleksey Shipilev"
>     <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>
>     > <mailto:aleksey.shipilev at oracle.com
>     <mailto:aleksey.shipilev at oracle.com>>> wrote:
>     >
>     >     On 11/30/2012 05:36 PM, Vitaly Davidovich wrote:
>     >     > What's the plan for making this info available in heap
>     dumps (taken
>     >     > using jmap)? I'd imagine tools like Eclipse MAT may want
>     to indicate
>     >     > that a given instance of a class has padding applied.
>      Otherwise, the
>     >     > object size reported won't match expectation (without
>     knowing that
>     >     > padding was applied).
>     >
>     >     Can't speak for other implementations, but HotSpot would
>     report the
>     >     proper sizes/offset via Instrumentation.objectSize and
>     >     Unsafe.*fieldOffset. As long as tooling is not doing dumb
>     >     "sum(fieldTypeCount*fieldSizeAsMandatedByJLS)", it should
>     pick up the
>     >     proper sizes.
>     >
>     >     -Aleksey.
>     >
>     >
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121130/d6ef7a70/attachment.html>


More information about the Concurrency-interest mailing list