Object to ObjectMonitor mapping using a HashTable to avoid displaced headers

[Kennke, Roman]

Hi there,

I now have a change vs the omworld branch (adding an NMT category for the OM table). How do we want to handle workflow in this branch? Should we do the usual post a PR, get a review, integrate thing? I think this would be useful to keep people aware of what’s happening.

Also, I have made some experiments with Renaissance’s philosophers benchmark, a brutal OM churner.

First observation without deflation, to get an idea how many OMs the workload allocates:

OMWorld (no deflation):
-           Synchronization (reserved=194421072, committed=194421072)
                            (malloc=194421072 #304595) (peak=194421176 #304596)
-           Object Monitors (reserved=3997340672, committed=3997340672)
                            (malloc=3997340672 #19217984) (at peak)
-                  OM World (reserved=324265096, committed=324265096)
                            (malloc=324265096 #19217988) (at peak)
Legacy (no deflation):
-           Synchronization (reserved=347673408, committed=347673408)
                            (malloc=347673408 #540453) (peak=347673512 #540454)
-           Object Monitors (reserved=7136973168, committed=7136973168)
                            (malloc=7136973168 #34312371) (at peak)

It looks like Legacy locking allocates ~34 million OMs, while OMWorld only 19 million. So far so good.

However, the picture changes with deflation turned on:

OMWorld:
-           Synchronization (reserved=92498024, committed=92498024)
                            (malloc=92498024 #146656) (peak=95537040 #151437)
-           Object Monitors (reserved=1750823568, committed=1750823568)
                            (malloc=1750823568 #8417421) (peak=1958719776 #9416922)
-                  OM World (reserved=151456088, committed=151456088)
                            (malloc=151456088 #8417425) (peak=152173976 #8462293)
Legacy:
-           Synchronization (reserved=27548072, committed=27548072)
                            (malloc=27548072 #46324) (peak=35675592 #59184)
-           Object Monitors (reserved=511949360, committed=511949360)
                            (malloc=511949360 #2461295) (peak=731033680 #3514585)

Here, OM usage peaks at 9.5 million with OMWorld while it’s only 3.5 million with legacy.

I don’t have an explanation, yet. Maybe deflation simply got slower and can’t keep up (or rather, can keep up even less than with legacy, because I believe deflation is overloaded either way). Maybe there are other interactions. Dunno yet.

Also, the NMT stats give a nice view on how much extra memory the table takes (less than 1/10th per OM) and how many extra OMs are allocated because of (presumably) deflation conflicts (11%).

If you have anything that you want me to look at, let me know. I’ll keep looking around and use the problem as a vehicle to familiarize myself with OMWorld.

Cheers,
Roman

> On Feb 20, 2024, at 5:41 PM, Kennke, Roman <rkennke at amazon.de> wrote:
> 
> I have also set-up a non-Lilliput branch:
> 
> https://github.com/openjdk/lilliput/tree/omworld-jdk
> 
> I suggest to use that as the main branch for working on OMWorld stuff together. From there, we can and should merge to:
> 
> https://github.com/openjdk/lilliput/tree/omworld
> 
> Axel, could you merge-in the LW recursive work from latest mainline JDK?
> 
> Cheers,
> Roman
> 
>> On Jan 31, 2024, at 4:41 PM, Axel Boldt-Christmas <axel.boldt-christmas at oracle.com> wrote:
>> 
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>> 
>> Hello, 
>> 
>> We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput’s 64-bit headers.
>> 
>> Some background to the issue. 
>> With the introduction of Lilliput and 64-bit headers it creates a scenario where both the narrowKlass* and the ObjectMonitor* cannot fit inside the markWord at the same time. The current solution is to place the Klass* in a displaced header. LM_LIGHTWEIGHT was introduced to the JDK project partially because the same issue existed with LM_LEGACY and the BasicLock*. 
>> 
>> Having the Klass* not be displaced is something we see it as a pre-requisite for integrating Lilliput in the JDK.
>> 
>> As mentioned we have been working on a solution which uses an external hash table to map objects to their respective ObjectMonitor. With per thread caches to speed up retrieval in compiled code. The work has been done under the name OMWorld (ObjectMonitor World). The solution was initially based on LM_LIGHTWEIGHT but has been separated into a fourth locking mode.
>> 
>> It is time to open up the work to the broader community, and make it part of the Lilliput project. Creating a central base to work from inside the Lilliput project and repository. 
>> 
>> Here are the latest rebased branches both on the OpenJDK/JDK master and the OpenJDK/Lilliput master. 
>> 
>>> Latest OMWorld on Mainline: https://github.com/xmas92/jdk/tree/omworld-as-new-lm
>>> Latest OMWorld on Lilliput: https://github.com/xmas92/lilliput/tree/omworld-as-new-lm-on-lilliput
>> 
>> Hopefully Roman can coordinate the creation of branches in the Lilliput repo which we all can work against.
>> 
>> Sincerely
>> // Axel Boldt-Christmas
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879