ObjectSynchronizer iterate only in-use monitors?

[Roman Kennke]

Am 16.05.2017 um 09:54 schrieb Thomas Schatzl:
> Hi,
>
> On Tue, 2017-05-16 at 09:43 +0200, Roman Kennke wrote:
>> Am 16.05.2017 um 08:52 schrieb David Holmes:
>>> Correction ...
>>>
>>> On 16/05/2017 2:49 PM, David Holmes wrote:
>>>> On 16/05/2017 12:52 AM, Roman Kennke wrote:
>>>>> Am 11.05.2017 um 09:44 schrieb Robbin Ehn:
> [...]
>>>> synchronization and the fact that deflation only happens at
>>>> safepoints.
>>> This might not be as fragile as I was initially thinking, but a
>>> good design walkthrough of Monitor-lifecycle will be essential for
>>> understanding any subtleties of existing and proposed approaches.
>> I realized that monitor deflation depends strictly on all Java
>> threads having arrived at safepoint. If a thread starts deflating its
>> monitors while other threads are still in the process of getting to a
>> safepoint, those other threads could mess with the monitors that the
>> first threads is attempting to deflate. This is a no-go.
>>
>> However, I devised a scheme that works well: instead of letting the
>> VM thread deflate all idle monitors after all threads arrived, and
>> doing so single-threaded, I am now letting GC worker threads deflate
>> idle monitors right before scanning/processing the synchronizer
>> roots. E.g.:
>>
>> http://cr.openjdk.java.net/~rkennke/deflate-per-thread/webrev.01/
>>  
>> I can probably collapse monitor deflation and iteration into one pass
>> too.
>   is there a problem to just activate this by default and avoid adding
> an (experimental) option? Even experimental options are part of the
> public API (as they can be accessed in the product) and need a CSR
> request to add and need to go through the usual long-winded procedure
> to remove later (after we find out after 10 years that nobody ever
> actually uses that one).
>
> I mean, this change seems to be a win in all cases (or at most be as
> slow as before), so why allow the user to mess with it?

There's no problem. I made it this way mostly for me to be able to test
and compare side-by-side easily :-) Will post RFR without the flag after
I've done some more testing...

Roman