how to handle automatically synchronized blocks

[Remi Forax]

yes,
i've a raw prototype of an agent that transform monitorenter/monitorexit/wait/notify to use j.u.c.ReentrantLock instead.

My first idea was to add the ReentranLock (and Condition) as field but i've found that impractical because it means you need to be able to associate the object used by the synchronized block to the field that contains that object and for most of the existing code, an inter-procedural analysis is required.
So my current prototype works by using a locked weak hashmap that associate a couple ReentrantLock/Condition to the monitor object.
It's not pretty and it has the stupid side effect of making the G1 pauses longer that they should.

Rémi 

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Cristian Lorenzetto" <cristian.lorenzetto at gmail.com>, "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Mardi 13 Août 2019 15:47:00
> Objet: Re: how to handle automatically synchronized blocks

> On 13/08/2019 11:38, Cristian Lorenzetto wrote:
>> I have a project with many synchronized blocks using fibers and threads .
>> I was studing a way to solve this problem with fibers. Synchronized blocks
>> now works just with threads. I found a solution but is a bit complex and
>> long for a single developer.
>> Essentially using instrumentation i change bytecode replacing the old
>> synchonized block instruction with a block working also with fibers.
>> No one developed a similr solution?

> I think Rémi Forax was looking tooling too, I think to replace monitors
> with j.u.c. locks and probably Condition objects for using monitor
> wait/notify. You don't of course need to change all usage of monitors,
> it should only be the places where do you are doing blocking operations
> while holding a monitor. If you run with -Djdk.tracePinnedThreads=full
> (or "short") then it may help you identify the places where this arises.
> 
> -Alan