Object to ObjectMonitor mapping using a HashTable to avoid displaced headers

[Kennke, Roman]

Hi Axel,

> We at Oracle have been working on an effort to make the Klass* stable (and avoid displaced headers) with Lilliput’s 64-bit headers.
> 

This is great stuff!

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

This sounds nice! It will simplify and 'unlock' a number of things in Lilliput:
- Currently, we require a branch on the fast-path of any code that accesses the Klass*, e.g. for any runtime type-checking, etc. This has caused some (minor, but still) regressions in some workloads. With your work, this will no longer be necessary.
- ZGC support, because I could never get ZGC to properly coordinate with the monitor-deflation protocol, which has been necessary to safely access the Klass*. I guess this is why you consider this a must-have (and I agree).
- Looking forward, towards 4-byte headers (aka Lilliput 2), compact-identity-hashcode will also be much simpler because when headers can be displaced, and we are in the process of copying/extending an object, which object does the displaced header refer to - the old or the new?
- And of course get rid of all things that have to do with displaced headers.

I am curious: have you made any performance studies, yet? How does it look? (I will certainly do some of my own later, but will not get to it this week. Traveling to FOSDEM/OCW the rest of the week.)

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

I have created the branch:
https://github.com/openjdk/lilliput/tree/omworld

And the PR to track it (and easily see the diff vs mainline Lilliput):
https://github.com/openjdk/lilliput/pull/127/files

I noticed that you, Axel, have no role in Lilliput, yet. I will propose you for Lilliput Committer ASAP, then you can work directly on that branch. I don’t think we want reviews/PRs for changes going to that branch. (Except, I am not sure if committers can push directly to repos, or if only the maintainer can do that? We need to see.)

I’ve got a whole lot of follow-up stuff (see above) that I would like to do on top of OMWorld - I would suggest to do that in another branch to keep the OMWorld changes and the other experimental stuff separate.

Thank you, Axel! This looks like very useful work!

Cheers,
Roman




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