RFR 8232733: Remove need to grab Threads_lock while processing handshakes

[David Holmes]

Hi Patricio,

On 7/12/2019 5:40 am, Patricio Chilano wrote:
> Hi all,
> 
> Please review the following patch that removes the requirement of having 
> to acquire the Threads_lock while processing handshakes. The guarantee 
> that the JavaThread being handshaked will not exit and its memory be 
> freed is already provided by using SMR ThreadsLists. With respect to the 
> comments that the Threads_lock is needed to avoid a suspended JavaThread 
> from being resumed, that will not be a problem since the JavaThread will 
> still make the proper transition after being resumed and will block if 
> needed for the handshake.
> 
> Tested with mach5, tiers1-7.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232733
> Webrev: http://cr.openjdk.java.net/~pchilanomate/8232733/v01/webrev/

src/hotspot/share/runtime/handshake.cpp

  151       // We need to re-think this with SMR ThreadsList.
  152       // There is an assumption in the code that the Threads_lock 
should be
  153       // locked during certain phases.
  154       {
  155         MutexLocker ml(Threads_lock);

The way I read that comment is that the SMR code expects the 
Threads_lock to be held during certain phases of the handshake code. Is 
that not what it meant?

Ditto for where we use the JavaThreadIteratorWithHandle. If we didn't 
need the Threads_lock while using the JavaThreadIteratorWithHandle why 
were we taking it? Were we just overly cautious/conservative?

Thanks,
David


> Thanks,
> 
> Patricio