ObjectSynchronizer iterate only in-use monitors?

[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?

Thanks,
  Thomas