RFR (XS) JDK-8006280 - structure packing for 64-bit

[Coleen Phillimore]

This looks good.   Luckily doesn't impact the serviceability agent.

The field _alloc_count could be removed completely because from what we 
can tell, nobody uses the allocation profiler.   There's a bug filed for 
that.

Coleen

On 01/23/2013 03:09 PM, Ioi Lam wrote:
> WebRev:
> http://cr.openjdk.java.net/~iklam/8006280/reorder_metadata_001/
>
> Bug: Need to reorder metadata structures to reduce size (64-bit)
>      https://jbs.oracle.com/bugs/browse/JDK-8006280
>
> Sponsor: Jiangli
>
> Summary:
>
> On x64:
>
>    + Klass: 8 byte reduction
>    + InstanceKlass: 8 byte reduction (in addition to reduction in Klass)
>    + Method: 8 byte reduction
>
>    This is verified by using the "pahole" script (as described in bug report)
>
> On ARM-EABI:
>
>    I also manually verify that this change for ARM-EABI (which requires
>    8-byte alignment for jlong but not pointers):
>
>    + Klass: 8 byte reduction
>    + InstanceKlass: no change (apart from Klass reduction) -- no jlong fields
>    + Method: no change -- no jlong fields
>
>    Before: (linux_armvfp_2.6-productEmb/jre/lib/arm/minimal/libjvm.diz
>
>      (gdb) p &((Klass*)0)->_alloc_count
>      $1 = (juint *) 0x58
>      (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time
>      $2 = (jlong *) 0x60
>      (gdb) p sizeof(Klass)
>      $3 = 120
>
>      The "hole" was at address 0x5c
>
>    After:
>
>      (gdb) p &((Klass*)0)->_access_flags
>      $7 = (AccessFlags *) 0x54
>      (gdb) p &((Klass*)0)->_last_biased_lock_bulk_revocation_time
>      $8 = (jlong *) 0x58
>      (gdb) p sizeof(Klass)
>      $6 = 112
>
> Tests run:
>
> + JPRT -- (hotspot only, on hotspotwest queue, including embedded builds)
>
> + UTE/vm.quick.testlist, 100% passed
>
>
> Thanks
> Ioi
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130123/7f13b0f7/attachment.html