monitors explosion

[Peter Levart]

On 05/26/11, Peter Levart wrote:
> What I tried to achieve with the code was to establish a situation where one thread (Allocator) inflated/allocated the monitor and another thread (Collector) freed it so that it was returned to it's private list. But I don't know if that is what is going on. 1st I don't know exactly when the monitor has to be inflated/allocated: at the first uncontended entry into the synchronized block or at the first contended synchronyzation. 2nd I don't know exactly when the monitor is freed (returned to the private free list) and to which thread's free list (the one that allocated it or the one that is freeing it). Is there any documentation about what code is generated by JIT? There are helpfull comments in synchronize.cpp but I haven't yet been able to grasp the whole picture about monitors.
>

Looking at synchronizer.cpp for some more time, I can now understand a little better what the lifecycle of ObjectMonitor is. If I understand the code correctly (for the case when MonitorInUseLists is 0), ObjectMonitors are omAlloc-ed from thread's local free list and when it gets empty a chunk of them is transfered to it from global free list while holding list lock. If global free list gets empty then new block of monitors is created.

omRelease on the other hand can only be called after omAlloc by the same thread and when the allocated ObjectMonitor could not be used (because of unsuccessful CAS) so omRelease can not accumulate monitors allocated by other threads as I suspected at first.

Idle monitors are deassociated from objects and returned directly to global free list in STW safepoint by deflate_idle_monitors.

So the only possibility that we get so many monitors in circulation is that scavenging can not keep up with allocation. In other words, we get 2M monitors because running threads allocate 2M monitors between 2 consecutive scavenges.

Just a thought: If MonitorInUseLists is true. Could in this situation omAlloc work as following:

1 - allocate from thread local free list until it gets empty
2 - deflate idle monitors from a local inUse list and return them to local free list and retry 1 if any got returned
3 - reprovision from global free list and retry 1 if any got reprovisioned
4 - create new monitors on global free list and retry 1

Is deflating permissible while in amAlloc() ?


Regards, Peter