On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich <vita...@gmail.com> wrote: >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax <fo...@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 ? > >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.christ...@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.christ...@oracle.com> >> >>> À: "core-libs-dev" <core-libs-dev@openjdk.java.net>, >"hotspot-dev" >> ><hotspot-...@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 Android device with K-9 Mail. Please excuse my brevity.
