From jaromir.hamala at gmail.com  Sat Oct 10 17:12:16 2015
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Sat, 10 Oct 2015 20:12:16 +0300
Subject: Bug in "loss due alignment" report?
Message-ID: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>

Hello,

I'm not sure if that's a bug or feature, but I have this code:

public static void main(String[] args) {
        int size = 1;
        byte[] b = new byte[size];

        out.println(ClassLayout.parseClass(b.getClass()).toPrintable(b));
    }

it yields following output:

[B object internals:
 OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
      0     4       (object header)                01 00 00 00 (0000 0001
0000 0000 0000 0000 0000 0000)
      4     4       (object header)                00 00 00 00 (0000 0000
0000 0000 0000 0000 0000 0000)
      8     4       (object header)                84 01 fc df (1000 0100
0000 0001 1111 1100 1101 1111)
     12     4   int [B.length                      N/A
     16     0  byte [B.<elements>                  N/A
     16     8       (loss due to the next object alignment)
Instance size: 24 bytes (reported by Instrumentation API)
Space losses: 0 bytes internal + 8 bytes external = 8 bytes total

The alignment waste should be 7 and not 8 bytes and the element size should
be 1. I realize it can be tricky to fix as the class parser does not have
an access to the actual object instance, but the current report is rather
misleading.

Cheers,
Jaromir

-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry

From aleksey.shipilev at oracle.com  Mon Oct 12 14:32:41 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Mon, 12 Oct 2015 14:32:41 +0000
Subject: hg: code-tools/jol: 7901529: GraphLayout addition/subtraction methods
Message-ID: <201510121432.t9CEWfvx012294@aojmv0008.oracle.com>

Changeset: 25bac17a379f
Author:    shade
Date:      2015-10-12 17:32 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/25bac17a379f

7901529: GraphLayout addition/subtraction methods

! jol-core/src/main/java/org/openjdk/jol/info/GraphLayout.java
+ jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_24_Difference.java


From aleksey.shipilev at oracle.com  Mon Oct 12 19:31:34 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Mon, 12 Oct 2015 19:31:34 +0000
Subject: hg: code-tools/jol: 7901530: ClassLayout should handle
	variable-length instances properly
Message-ID: <201510121931.t9CJVYQj008498@aojmv0008.oracle.com>

Changeset: c851de7dd320
Author:    shade
Date:      2015-10-12 22:31 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/c851de7dd320

7901530: ClassLayout should handle variable-length instances properly

! jol-cli/src/main/java/org/openjdk/jol/operations/ObjectInternals.java
! jol-core/src/main/java/org/openjdk/jol/info/ClassData.java
! jol-core/src/main/java/org/openjdk/jol/info/ClassLayout.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_11_ClassWord.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_12_ThinLocking.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_13_BiasedLocking.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_14_FatLocking.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_15_IdentityHashCode.java
! jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_19_Promotion.java
+ jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_25_ArrayAlignment.java


From aleksey.shipilev at oracle.com  Mon Oct 12 19:32:52 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 12 Oct 2015 22:32:52 +0300
Subject: Bug in "loss due alignment" report?
In-Reply-To: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
References: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
Message-ID: <561C0AE4.8010602@oracle.com>

Hi Jaromir,

On 10/10/2015 08:12 PM, Jaromir Hamala wrote:
> The alignment waste should be 7 and not 8 bytes and the element size should
> be 1. I realize it can be tricky to fix as the class parser does not have
> an access to the actual object instance, but the current report is rather
> misleading.

Yes, I agree.

And the reason you provided is exactly what is happening. Without
changing the class parser to accept the instance itself, it would be
hard to accommodate any variable-length instance.

Luckily, this is easy enough to fix. See:
 https://bugs.openjdk.java.net/browse/CODETOOLS-7901530

Notably, see a new sample:
 http://hg.openjdk.java.net/code-tools/jol/file/tip/jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_25_ArrayAlignment.java

Please test!

Thanks,
-Aleksey


From jaromir.hamala at gmail.com  Tue Oct 13 08:14:06 2015
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Tue, 13 Oct 2015 11:14:06 +0300
Subject: Bug in "loss due alignment" report?
In-Reply-To: <561C0AE4.8010602@oracle.com>
References: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
	<561C0AE4.8010602@oracle.com>
Message-ID: <CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>

Hi Aleksey,

the `parseInstance()`works nicely, thanks! However the old code is now
throwing NPE:

public static void main(String[] args) {
        int size = 1;
        byte[] b = new byte[size];

        out.println(ClassLayout.parseClass(b.getClass()).toPrintable(b));
    }


Exception in thread "main" java.lang.NullPointerException
at org.openjdk.jol.info.ClassData.arrayLength(ClassData.java:68)
at org.openjdk.jol.info.ClassData.parseArray(ClassData.java:89)
at org.openjdk.jol.info.ClassData.parse(ClassData.java:95)
at org.openjdk.jol.info.ClassData.parseClass(ClassData.java:64)
at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:66)
at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:50)
at
org.openjdk.jol.samples.JOLSample_01_Basic.main(JOLSample_01_Basic.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)

Cheers,
Jaromir



On Mon, Oct 12, 2015 at 10:32 PM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi Jaromir,
>
> On 10/10/2015 08:12 PM, Jaromir Hamala wrote:
> > The alignment waste should be 7 and not 8 bytes and the element size
> should
> > be 1. I realize it can be tricky to fix as the class parser does not have
> > an access to the actual object instance, but the current report is rather
> > misleading.
>
> Yes, I agree.
>
> And the reason you provided is exactly what is happening. Without
> changing the class parser to accept the instance itself, it would be
> hard to accommodate any variable-length instance.
>
> Luckily, this is easy enough to fix. See:
>  https://bugs.openjdk.java.net/browse/CODETOOLS-7901530
>
> Notably, see a new sample:
>
> http://hg.openjdk.java.net/code-tools/jol/file/tip/jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_25_ArrayAlignment.java
>
> Please test!
>
> Thanks,
> -Aleksey
>
>


-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry

From jaromir.hamala at gmail.com  Tue Oct 13 08:27:02 2015
From: jaromir.hamala at gmail.com (Jaromir Hamala)
Date: Tue, 13 Oct 2015 11:27:02 +0300
Subject: Bug in "loss due alignment" report?
In-Reply-To: <CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>
References: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
	<561C0AE4.8010602@oracle.com>
	<CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>
Message-ID: <CAMxXA684_HM-e+XGSt7R7Wc+8OSO6xrhEGcegy=E7CKm7gegQA@mail.gmail.com>

perhaps one more improvement could be done:
 OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
      0     4       (object header)                01 00 00 00 (0000 0001
0000 0000 0000 0000 0000 0000)
      4     4       (object header)                00 00 00 00 (0000 0000
0000 0000 0000 0000 0000 0000)
      8     4       (object header)                0a 02 fc df (0000 1010
0000 0010 1111 1100 1101 1111)
     12     4   int [I.length                      N/A
     16     8   int [I.<elements>                  N/A


It would be nice to show the actual array length in the value column.

I believe you deliberately decided not to interpret HotSpot internal data,
but this one could be done safely. It's just a convenience thing anyway as
the length can be calculated from size even now.

Cheers,
Jaromir


On Tue, Oct 13, 2015 at 11:14 AM, Jaromir Hamala <jaromir.hamala at gmail.com>
wrote:

> Hi Aleksey,
>
> the `parseInstance()`works nicely, thanks! However the old code is now
> throwing NPE:
>
> public static void main(String[] args) {
>         int size = 1;
>         byte[] b = new byte[size];
>
>         out.println(ClassLayout.parseClass(b.getClass()).toPrintable(b));
>     }
>
>
> Exception in thread "main" java.lang.NullPointerException
> at org.openjdk.jol.info.ClassData.arrayLength(ClassData.java:68)
> at org.openjdk.jol.info.ClassData.parseArray(ClassData.java:89)
> at org.openjdk.jol.info.ClassData.parse(ClassData.java:95)
> at org.openjdk.jol.info.ClassData.parseClass(ClassData.java:64)
> at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:66)
> at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:50)
> at
> org.openjdk.jol.samples.JOLSample_01_Basic.main(JOLSample_01_Basic.java:58)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
>
> Cheers,
> Jaromir
>
>
>
> On Mon, Oct 12, 2015 at 10:32 PM, Aleksey Shipilev <
> aleksey.shipilev at oracle.com> wrote:
>
>> Hi Jaromir,
>>
>> On 10/10/2015 08:12 PM, Jaromir Hamala wrote:
>> > The alignment waste should be 7 and not 8 bytes and the element size
>> should
>> > be 1. I realize it can be tricky to fix as the class parser does not
>> have
>> > an access to the actual object instance, but the current report is
>> rather
>> > misleading.
>>
>> Yes, I agree.
>>
>> And the reason you provided is exactly what is happening. Without
>> changing the class parser to accept the instance itself, it would be
>> hard to accommodate any variable-length instance.
>>
>> Luckily, this is easy enough to fix. See:
>>  https://bugs.openjdk.java.net/browse/CODETOOLS-7901530
>>
>> Notably, see a new sample:
>>
>> http://hg.openjdk.java.net/code-tools/jol/file/tip/jol-samples/src/main/java/org/openjdk/jol/samples/JOLSample_25_ArrayAlignment.java
>>
>> Please test!
>>
>> Thanks,
>> -Aleksey
>>
>>
>
>
> --
> ?Perfection is achieved, not when there is nothing more to add, but when
> there is nothing left to take away.?
> Antoine de Saint Exup?ry
>



-- 
?Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.?
Antoine de Saint Exup?ry

From aleksey.shipilev at oracle.com  Tue Oct 13 09:40:56 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Tue, 13 Oct 2015 09:40:56 +0000
Subject: hg: code-tools/jol: Fix NPE regression after 7901530.
Message-ID: <201510130940.t9D9eulG007123@aojmv0008.oracle.com>

Changeset: ebd10e5c3366
Author:    shade
Date:      2015-10-13 12:36 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/ebd10e5c3366

Fix NPE regression after 7901530.

! jol-core/src/main/java/org/openjdk/jol/info/ClassData.java


From aleksey.shipilev at oracle.com  Tue Oct 13 09:41:22 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 13 Oct 2015 12:41:22 +0300
Subject: Bug in "loss due alignment" report?
In-Reply-To: <CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>
References: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
	<561C0AE4.8010602@oracle.com>
	<CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>
Message-ID: <561CD1C2.9060104@oracle.com>

On 10/13/2015 11:14 AM, Jaromir Hamala wrote:
> public static void main(String[] args) {
>         int size = 1;
>         byte[] b = new byte[size];
> 
>         out.println(ClassLayout.parseClass(b.getClass()).toPrintable(b));
>     }
> 
> Exception in thread "main" java.lang.NullPointerException
> at org.openjdk.jol.info.ClassData.arrayLength(ClassData.java:68)
> at org.openjdk.jol.info.ClassData.parseArray(ClassData.java:89)
> at org.openjdk.jol.info.ClassData.parse(ClassData.java:95)
> at org.openjdk.jol.info.ClassData.parseClass(ClassData.java:64)
> at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:66)
> at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:50)

Ooops. Fixed:
 http://hg.openjdk.java.net/code-tools/jol/rev/ebd10e5c3366

Thanks,
-Aleksey



From aleksey.shipilev at oracle.com  Tue Oct 13 11:25:25 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Tue, 13 Oct 2015 11:25:25 +0000
Subject: hg: code-tools/jol: 7901531: Array length should be introspected as
	well
Message-ID: <201510131125.t9DBPPWO025697@aojmv0008.oracle.com>

Changeset: bf386b19040f
Author:    shade
Date:      2015-10-13 14:25 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/bf386b19040f

7901531: Array length should be introspected as well

! jol-core/src/main/java/org/openjdk/jol/datamodel/CurrentDataModel.java
! jol-core/src/main/java/org/openjdk/jol/datamodel/DataModel.java
! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_32_DataModel.java
! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_64_COOPS_DataModel.java
! jol-core/src/main/java/org/openjdk/jol/datamodel/X86_64_DataModel.java
! jol-core/src/main/java/org/openjdk/jol/layouters/CurrentLayouter.java
! jol-core/src/main/java/org/openjdk/jol/layouters/HotSpotLayouter.java
! jol-core/src/main/java/org/openjdk/jol/layouters/RawLayouter.java
! jol-core/src/main/java/org/openjdk/jol/util/VMSupport.java


From aleksey.shipilev at oracle.com  Tue Oct 13 11:26:48 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 13 Oct 2015 14:26:48 +0300
Subject: Bug in "loss due alignment" report?
In-Reply-To: <CAMxXA684_HM-e+XGSt7R7Wc+8OSO6xrhEGcegy=E7CKm7gegQA@mail.gmail.com>
References: <CAMxXA69KaZvrMjk0cyZS-ZkzvP1=U32ZJ0VUGr1d4sO=n82=kA@mail.gmail.com>
	<561C0AE4.8010602@oracle.com>
	<CAMxXA6-W6w94G4=oDtij6xvS52tY5xgmg17Mo4_uuv2g0LpHZg@mail.gmail.com>
	<CAMxXA684_HM-e+XGSt7R7Wc+8OSO6xrhEGcegy=E7CKm7gegQA@mail.gmail.com>
Message-ID: <561CEA78.3020307@oracle.com>

On 10/13/2015 11:27 AM, Jaromir Hamala wrote:
> perhaps one more improvement could be done:
>  OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
>       0     4       (object header)                01 00 00 00 (0000
> 0001 0000 0000 0000 0000 0000 0000)
>       4     4       (object header)                00 00 00 00 (0000
> 0000 0000 0000 0000 0000 0000 0000)
>       8     4       (object header)                0a 02 fc df (0000
> 1010 0000 0010 1111 1100 1101 1111)
>      12     4   int [I.length                      N/A
>      16     8   int [I.<elements>                  N/A
> 
> 
> It would be nice to show the actual array length in the value column. 
> 
> I believe you deliberately decided not to interpret HotSpot internal
> data, but this one could be done safely. It's just a convenience thing
> anyway as the length can be calculated from size even now.

Yeah, in Hotspot, the array length is logically a part of object header.
So we can piggyback on that introspection:
  https://bugs.openjdk.java.net/browse/CODETOOLS-7901531

Thanks,
-Aleksey



From aleksey.shipilev at oracle.com  Tue Oct 13 11:35:02 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Tue, 13 Oct 2015 11:35:02 +0000
Subject: hg: code-tools/jol: 7901532: Object header data should be also
	printed in decimal
Message-ID: <201510131135.t9DBZ2Xj027719@aojmv0008.oracle.com>

Changeset: 79ff1eed2037
Author:    shade
Date:      2015-10-13 14:34 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/79ff1eed2037

7901532: Object header data should be also printed in decimal

! jol-core/src/main/java/org/openjdk/jol/info/ClassLayout.java


From aleksey.shipilev at oracle.com  Tue Oct 13 11:44:27 2015
From: aleksey.shipilev at oracle.com (aleksey.shipilev at oracle.com)
Date: Tue, 13 Oct 2015 11:44:27 +0000
Subject: hg: code-tools/jol: 7901533: GraphLayout.parseInstance multiple roots
	method mismatches the actual arrays
Message-ID: <201510131144.t9DBiRFT029280@aojmv0008.oracle.com>

Changeset: 684f549ca3a9
Author:    shade
Date:      2015-10-13 14:44 +0300
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/684f549ca3a9

7901533: GraphLayout.parseInstance multiple roots method mismatches the actual arrays

! jol-core/src/main/java/org/openjdk/jol/info/GraphLayout.java