Hi, Remi Thanks for the idea. From my reading of the jol ouput: http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.... 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@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "hotspot-dev" <hotspot-dev@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....

On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax@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@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....

...

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@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "hotspot-dev" <hotspot-dev@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....

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- Sent from my phone

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

On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich < vitalyd@gmail.com> wrote:

...

On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <forax@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?

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/oo... 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 < brent.christian@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....

...

...

...

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@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "hotspot-dev" <hotspot-dev@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....

...

...

-- 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

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