[RFR] (M) 8143608: Don't 64-bit align start of InstanceKlass vtable, itable, and nonstatic_oopmap on 32-bit systems

[Mikael Gerdin]

Hi Chris,

Not a review but I'm fairly sure that you need to update the 
serviceability agent to reflect these changes, see for example:

public long getSize() {
   return Oop.alignObjectSize(
getHeaderSize() +
Oop.alignObjectOffset(getVtableLen()) +
Oop.alignObjectOffset(getItableLen()) + 
Oop.alignObjectOffset(getNonstaticOopMapSize()));
   }

in InstanceKlass.java

/Mikael

On 2015-12-04 23:02, Chris Plummer wrote:
> Hello,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8143608
> http://cr.openjdk.java.net/~cjplummer/8143608/webrev.00/webrev.hotspot/
>
> A bit of background would help. The InstanceKlass object has a number of
> variable length fields that are laid out after the declared fields. When
> an InstanceKlass object is allocated, extra memory is allocated for it
> to leave room for these fields. The first three of these fields are
> vtable, itable, and nonstatic_oopmap. They are all arrays of HeapWord
> sized values, which means void* size, which means they only need 32-bit
> alignment on 32-bit systems. However, they have always been 64-bit
> aligned. This webrev removes the forced 64-bit alignment on 32-bit
> systems, saving footprint.
>
> This change affects all 32-bit platforms. It should have no net impact
> on 64-bit platforms since the fields remain (naturally) 64-bit aligned
> (unless of course I've introduced a bug). The intent is to not change
> what is done for 64-bit platforms.
>
> BTW, there is a change to AARCH64, which may seem odd at first. It just
> removes an "if" block where the condition should always have evaluated
> to false, so it should have no net affect.
>
> Tested with JPRT "-testset hotspot". Please let me know if you think
> there are any additional tests that should be run.
>
> thanks,
>
> Chris
>