RFR(S): 8186437: Lock held when compiler thread creation is aborted.

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Sat Aug 26 13:22:44 UTC 2017


Hi Vladimir, 

thanks a lot!

Best regards,
  Goetz.

> -----Original Message-----
> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
> Sent: Friday, August 25, 2017 10:52 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is
> aborted.
> 
> Looks good. I will sponsor it.
> 
> Thanks,
> Vladimir
> 
> On 8/24/17 11:56 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > could I please get a second review? I also please need a sponsor.
> >
> > Thanks,
> >    Goetz.
> >
> >
> >> -----Original Message-----
> >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
> >> bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> >> Sent: Dienstag, 22. August 2017 16:38
> >> To: Thomas Stüfe <thomas.stuefe at gmail.com>
> >> Cc: hotspot-compiler-dev at openjdk.java.net
> >> Subject: RE: RFR(S): 8186437: Lock held when compiler thread creation is
> >> aborted.
> >>
> >> Hi Thomas,
> >>
> >> thanks for the review!
> >>
> >> The control flow is just as in JVM_StartThread, there even an
> >> extra variable is maintained for the error case that is used only once.
> >>
> >> Best regards,
> >>    Goetz.
> >>
> >>
> >>> -----Original Message-----
> >>> From: Thomas Stüfe [mailto:thomas.stuefe at gmail.com]
> >>> Sent: Dienstag, 22. August 2017 15:37
> >>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>> Cc: hotspot-compiler-dev at openjdk.java.net
> >>> Subject: Re: RFR(S): 8186437: Lock held when compiler thread creation is
> >>> aborted.
> >>>
> >>> Hi Goetz,
> >>>
> >>>
> >>>
> >>> On Tue, Aug 22, 2017 at 3:19 PM, Lindenmaier, Goetz
> >>> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com> >
> wrote:
> >>>
> >>>
> >>> 	Hi,
> >>>
> >>> 	Could I please get reviews for this small change? I also please need a
> >>> sponsor.
> >>> 	http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/
> >>> <http://cr.openjdk.java.net/~goetz/wr17/8186437-compThrLock/>
> >>>
> >>> 	When the VM is aborted because compiler thread creation fails (seen
> >>> in
> >>> 	TestOprionsWithRanges with huge stack size) the Thread_lock was
> not
> >>> 	released.
> >>>
> >>>
> >>>
> >>>
> >>> Seems fine, if a bit difficult to read. Alternatively, one could have
> unlocked
> >>> manually - after all, we are never leaving this function, so the
> ~MutexLocker.
> >>> That would have preserved the control.
> >>>
> >>> Cheers, Thomas
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 	Best regards,
> >>> 	  Goetz.
> >>>
> >>>
> >


More information about the hotspot-compiler-dev mailing list