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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Remi Forax
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" <[hidden email]>
> À: "core-libs-dev" <[hidden email]>, "hotspot-dev" <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

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

Brent Christian-2
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" <[hidden email]>
>> À: "core-libs-dev" <[hidden email]>, "hotspot-dev" <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|

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

Remi Forax
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 ?

Rémi


On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <[hidden email]> 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" <[hidden email]>
>>> À: "core-libs-dev" <[hidden email]>, "hotspot-dev"
><[hidden email]>
>>> 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.
Reply | Threaded
Open this post in threaded view
|

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

Vitaly Davidovich
On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <[hidden email]> 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 <
> [hidden email]> 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" <[hidden email]>
> >>> À: "core-libs-dev" <[hidden email]>, "hotspot-dev"
> ><[hidden email]>
> >>> 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
Reply | Threaded
Open this post in threaded view
|

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

Brent Christian-2
In reply to this post by Remi Forax
On 11/07/2017 09:45 AM, mandy chung wrote:
>
> StackFrameInfo.java
>
>   38     // Footprint improvement: MemberName::clazz can replace
>   39     // StackFrameInfo::declaringClass.
>
> The above comment can be removed.

Whoops - thanks.

> 41 private final boolean retainClassRef;
>
> JVMS [1] has a note about Hotspot implementation of boolean array that
> is encoded as a byte array.  That explains JOL output that this boolean
> field is 8-bit in our implementation.  This field could be changed to a
> byte to hold additional flags, if any in the future.  It may be good to
> change this to a byte making the field size explicit.

Thanks for the link and explanation.  I agree with making the change now.

Updated webrev here:
http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/

-Brent

Reply | Threaded
Open this post in threaded view
|

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

Remi Forax
In reply to this post by Vitaly Davidovich


On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich <[hidden email]> wrote:

>On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <[hidden email]> 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?

My question is more given you have compressed oops  (and compressed klass) why the header is 12 bytes and not 8 bytes (a two words header).

so why the  mark word is 8 bytes and not 4 ? At worst it's a pointer and again you can use the compressed oops trick ?

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

yes, right.

Remi

>
>>
>>
>> Rémi
>>
>>
>> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
>> [hidden email]> 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" <[hidden email]>
>> >>> À: "core-libs-dev" <[hidden email]>,
>"hotspot-dev"
>> ><[hidden email]>
>> >>> 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 Android device with K-9 Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|

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

Vitaly Davidovich
On Tue, Nov 7, 2017 at 3:45 PM Remi Forax <[hidden email]> wrote:

>
>
> On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich <
> [hidden email]> wrote:
> >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <[hidden email]> 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?
>
> My question is more given you have compressed oops  (and compressed klass)
> why the header is 12 bytes and not 8 bytes (a two words header).
>
> so why the  mark word is 8 bytes and not 4 ? At worst it's a pointer and
> again you can use the compressed oops trick ?

http://hg.openjdk.java.net/jdk9/hs/hotspot/file/c68024d52834/src/share/vm/oops/markOop.hpp
has
a description of the layout - it’s not a pointer per se (although some
states do encode one) but a bunch of metadata.

>
>
> >
> >I think many folks would be upset if a boolean wasn’t stored as a byte
> >:).
>
> yes, right.
>
> Remi
>
> >
> >>
> >>
> >> Rémi
> >>
> >>
> >> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian <
> >> [hidden email]> 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" <[hidden email]>
> >> >>> À: "core-libs-dev" <[hidden email]>,
> >"hotspot-dev"
> >> ><[hidden email]>
> >> >>> 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 Android device with K-9 Mail. Please excuse my brevity.
>
--
Sent from my phone