RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo)

Vitaly Davidovich vitalyd at gmail.com
Tue Nov 7 19:48:43 UTC 2017


On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax at univ-mlv.fr> wrote:

> My bad,
> I've calculated that the header was 8 bytes instead of 12, so I've
> supposed that the boolean was not stored in a byte.
>
> For my culture, why the header is 12 bytes, the pointer to the vtable is
> on 64bits and can not be compressed like the other oops ?

It’s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark word
and a 4 byte compressed klass ptr.  It’s 16 bytes without compressed klass
ptr.  Or are you asking something else Remi?

I think many folks would be upset if a boolean wasn’t stored as a byte :).

>
>
> Rémi
>
>
> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
> brent.christian at oracle.com> wrote:
> >Hi, Remi
> >
> >Thanks for the idea.  From my reading of the jol ouput:
> >
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
> >
> >
> >
> >I believe retainClassRef is already being stored in a single byte (i.e.
> >
> >SIZE of 1):
> >
> >  OFFSET  SIZE     TYPE DESCRIPTION
> >...
> >      10     1  boolean StackFrameInfo.retainClassRef
> >
> >Thanks,
> >-Brent
> >
> >On 11/6/17 11:45 PM, Remi Forax wrote:
> >> Hi Brent,
> >> if you declare retainClassRef as a byte, you can even compress the
> >data structure a little bit more, no ?
> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte.
> >> Given that bci is a short, the VM will put both bci and
> >retainClassRef on the same 32 bits slot.
> >>
> >> cheers,
> >> Rémi
> >>
> >> ----- Mail original -----
> >>> De: "Brent Christian" <brent.christian at oracle.com>
> >>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> ><hotspot-dev at openjdk.java.net>
> >>> Envoyé: Mardi 7 Novembre 2017 01:23:16
> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of
> >java.lang.StackFrameInfo)
> >>
> >>> Hi,
> >>>
> >>> There are a couple opportunities to reduce the memory footprint of
> >>> java.lang.StackFrameInfo (the internal implementation of
> >>> java.lang.StackWalker.StackFrame):
> >>>
> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed
> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with
> >bitmap to
> >>> save footprint
> >>>
> >>> I had a look using jol[3].  Removing only 'walker' helps only under
> >32-
> >>> and 64-bit, but not with compressed oops.  Removing both 'walker'
> >and
> >>> 'declaringClass' brings a benefit to compressed oops as well (though
> >not
> >>> for 16-byte aligned).
> >>>
> >>> The size change, in bytes, for each execution mode is as follows:
> >>>
> >>>                               32-bit: 32->24
> >>>                               64-bit: 56->40
> >>>                   64/compressed oops: 32->24
> >>> 64/compressed oops, 16-byte aligned: 32->32
> >>>
> >>> (For reference, the jol reports for the baseline and specimen are at
> >[4]
> >>> and [5], respectively.)
> >>>
> >>> Please review my code change for this.  The webrev is here:
> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/
> >>>
> >>> An automated test run is in progress.
> >>>
> >>> Thanks!
> >>> -Brent
> >>>
> >>> --
> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682
> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925
> >>> 3. http://openjdk.java.net/projects/code-tools/jol/
> >>> 4.
> >>>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt
> >>> 5.
> >>>
> >
> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-- 
Sent from my phone


More information about the hotspot-dev mailing list