ObjectSynchronizer iterate only in-use monitors?

[David Holmes]

Hi Thomas,

 >   is there a problem to just activate this by default and avoid adding
 > an (experimental) option?

Yes! Whether you add an experimental flag to turn this on, or make it 
the default and add a product flag to run it off, it will need to be 
controllable. You need a lot of bake time for these kinds of changes and 
if they break things in the wild there must be a way for customers to go 
back to the old behaviour. And of course it is the only reasonable way 
to do side-by-side performance comparisons.

Cheers,
David
-----

On 16/05/2017 5:54 PM, Thomas Schatzl wrote:
> 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?
>
> Thanks,
>   Thomas
>