RFR 8231146: Heap object size
frederic.parain at oracle.com
Fri Sep 20 18:00:53 UTC 2019
JOL has a mix of information taken from a live type from a running JVM,
and information from simulation modes. For the latter, the old layout
algorithm used by the JVM has been reproduced in the JOL tool.
Valhalla has already switched to another layout algorithm that JOL
knows nothing about, so all simulation modes are unable to produce
correct results for inline types.
Optimizing field layouts is still a work win progress. Unless it is
a blocking issue, I’d suggest to wait for the final version of the
field layout algorithm before fixing JOL’s simulation mode.
Anyway, JOL will need a refresh because of some layout options going
away. For instance, the field allocation style option has been deprecated,
and will be removed in a few versions).
> On Sep 20, 2019, at 13:06, Mandy Chung <mandy.chung at oracle.com> wrote:
> JOL seems to hard code the oop size as a pointer size in certain implementation of DataModel?
> I believe JVM TI GetObjectSize and Instrumentation::getObjectSize already support inline classes. It'd good to verify.
> On 9/20/19 9:38 AM, Roger Riggs wrote:
>> Yes, JOL will need an update. It thinks all object fields size is just a reference (4).
>> I included an inline class Point(int x, int y)...
>> Regards, Roger
>> M Layout Simulation (org.openjdk.jol.datamodel.CurrentDataModel at 433f4e98, field allocation style: 2)
>> Class150176 object internals:
>> OFFSET SIZE TYPE DESCRIPTION VALUE
>> 0 12 (object header) N/A
>> 12 4 (alignment/padding gap)
>> 16 8 long Class150175.field1 N/A
>> 24 2 short Class150175.field2 N/A
>> 26 1 byte Class150175.field3 N/A
>> 27 1 (alignment/padding gap)
>> 28 4 java.lang.Object Class150175.field0 N/A
>> 32 4 org.openjdk.jol.util.Point Class150176.field1 N/A
>> 36 4 org.openjdk.jol.util.Point Class150176.field3 N/A
>> 40 8 double Class150176.field2 N/A
>> 48 2 short Class150176.field0 N/A
>> 50 6 (loss due to the next object alignment)
>> Instance size: 56 bytes
>> Space losses: 5 bytes internal + 6 bytes external = 11 bytes total
>> On 9/20/19 9:03 AM, Roger Riggs wrote:
>>> Hi Aleksey,
>>> I'll have to try it, but I don't expect it to be able to understand the embedding
>>> in objects or arrays without an update.
>>> This is for exploratory work on using inline classes and algorthms.
>>> JOL is not in an API in java.base that can be used to dynamically adjust
>>> data structures based on actual embedding.
>>> I expect any long term APIs to be different and more detailed.
>>> Thanks, Roger
>>> On 9/20/19 8:47 AM, Aleksey Shipilev wrote:
>>>> On 9/17/19 10:00 PM, Roger Riggs wrote:
>>>>> In prototyping with inline classes it will be useful to know an approximation of the size of an
>>>>> object in the heap while prototyping various tradoffs in performance and data structures.
>>>> Any reason why JOL does not work?
>>>> It already calls through the existing interfaces to figure out the object size.
More information about the valhalla-dev