RFR: [8u] OOME in SurrogateLockerThread deadlocks the GC cycle

[Roman Kennke]

Ok fine then. This does not negatively impact parralelization, and also doesn't potentially raise TLAB related issues either.

Roman

Am 3. Oktober 2017 15:01:46 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>On 10/03/2017 02:52 PM, Roman Kennke wrote:
>> Am 03.10.2017 um 14:43 schrieb Aleksey Shipilev:
>>> On 10/03/2017 12:06 PM, Roman Kennke wrote:
>>>> Looks good.
>>>> It probably makes sense to evac the pll even before the root
>processor parallelizes root evac?
>>> Maybe, maybe not? Current placement guarantees first evac, and keeps
>the root evacuation code in
>>> common place, and keeps patch at bare minimum. I like that two last
>parts about it.
>
>> It doesn't exactly guarantee first evac, it just makes it more
>likely. There might well be one or
>> more worker threads getting scheduled ahead of the one that evacs the
>pll. 
>
>Yes, and it would also go via the path that tries to evac the PLL. So
>every thread would try to evac
>PLL the first thing, pushing scheduling out of equation. At least that
>was the intent :)
>
>> That's why I proposed to maybe even explictely evac the pll from the
>VMThread, even before we
>> spin up the workers. But this might well be overkill (considering the
>other parts of the fix that
>> already ensure smooth handling in case of failure). I leave the
>decision up to you :-)
>Yeah, seems like overkill. Well, current thing is also overkill, but
>more concise one, and it is
>gone in 9 and 10 anyway. I looked through the places where
>process_evacuate_roots is called, and
>there are exceptional paths that also need to be taken care of. Leaving
>PLL evac inside
>ShenandoahRootEvacuator seems less messy.
>
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.