[External] : Re: Object to ObjectMonitor mapping using a HashTable to avoid displaced headers

[Kennke, Roman]

Hi Axel,

>> How bad is that? Have you ever observed this to be an actual problem? (It seems kind-of the reverse of what is currently done with the INFLATING protocol and doesn’t seem very much worse than that. Correct me if I’m wrong here.)
> 
> 
> No, never observed it being an issue. Hitting the window between  `is_being_async_deflated()` transitioning the markWord is so small that I do not believe that it has been observed.
> 
> However before we added resizing to the HashTable there were runs where we had internal buckets with linked lists of size >100. Noticable time was then spent in insert, so I would guess that similar times would seen for remove (walking the links was costly). So the window until a thread could inflate again would be significant. This more of a TTS problem. Any safepoint would still need to also wait for the deflation thread to finish removing the ObjectMonitor from the hash table, put polling for safepoint earlier from inflating threads means that the worst time would be MAX(deflation, inflation + enter) instead of deflation +  inflation  + enter.

Ok, thanks for the explanation.

>> Uhhh, ok. Wait a second, aren’t threads that want to inflate a monitor already at a safepoint?
> 
> They are just java threads running in VM. Or do you mean something else?

My understanding was that a Java thread in VM would not prevent reaching a safepoint. Maybe I mis-remember.

> Speaking of which. I was going to ask you how we should handle development (especially if more are getting involved).
> 
> For now I will work on changes based on the OMWorld Lilliput branch. And replicate (cherry-pick) these where applicable into my private mainline based branch. Until I am an official committer in the Lilliput I believe me and StefanK can figure out the technicalities around pushing to the branch.
> 
> So essentially, work on Lilliput/OMWorld, keep a private branch based the latest mainline merged in Lilliput/master (with OMWorld work replicated) and keep merging in Lilliput/master into Lilliput/OMWorld.

I am not sure. I tend to think that we should perhaps leave Lilliput itself out of the equation for now. Could we do development in a branch off of mainline JDK? I can set-up such a branch in the Lilliput repo, and I can also do regular merges from mainline JDK and to the omworld-lilliput branch, but I think main work should be based on latest JDK to keep the changes clean from extra Lilliput fluff and also to be able to do proper apples-to-apples comparisons.

>> Ugh. Any idea why that is so?
> 
> Only speculations. The compiled vs not compiled issue seems like a more binary thing where we might be (maybe for good reasons) more restrictive than necessary.

Sounds like this is a ‘primary’ issue.

> The C1 vs C2 issue is probably caused by many factors, and I have nothing but educated guesses here. Something for engineers more versed in the compiler to tackle.

Yeah, as far as I know this could be a pre-existing problem. At least I know that some workloads are at the mercy of compiler heuristics.

>> I would suggest to break up your efforts into tasks that are absolutely essential, and tasks/ideas that can be done after the first big thing has landed and stabilized. This would follow pretty much the structure of this document - focus on primary stuff first, and do most of the rest later. It’s just so hard to handle so many moving parts at the same time.
> 
> Sounds good. After recursive lightweight is integrated in mainline and merged into Lilliput (and OMWorld) there should be a lot less code motion surrounding the affected code. I will create sub-tasks (and figure out their dependencies) as you suggest.
> 

Great! I’m happy to help!

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