OpenJDK G1 Patch

Kirk Pepperdine kirk.pepperdine at gmail.com
Wed May 23 14:07:40 UTC 2018


> On May 23, 2018, at 1:32 PM, Gil Tene <gil at azul.com> wrote:
> 
> 
> 
>> On May 23, 2018, at 11:38 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com> wrote:
>> 
>> 
>>> On May 23, 2018, at 9:36 AM, Michal Frajt <michal at frajt.eu> wrote:
>>> 
>>> Hi Kirk,
>>> 
>>> I’m just on the back end of the Oracle Dev tour in Japan… Once I land I’ll work on the test case to hopefully sort out what is happening with references and G1 (if this is indeed the cause of the grief I’ve been trying to sort through) and I do plan on sharing the results.
>>> -	please share with us your finding, we would like to know how the G1 handles processing of weak references which are across all regions, we simply need to get them cleaned within a certain time at least (our CMSTriggerInterval)
>>> -	we have had similar issue with the Azul C4 where the weak references behave(d) very differently, when you just shortly access a weak reference referent, the weak reference won’t be cleaned in the next C4 major cycle (like minutes interval), so you have to stop accessing it which goes completely against the weak reference (or soft reference) idea
>> 
>> Indeed, this feels like a bug.. certainly doesn’t meet WeakReference definitions as I understand it.
> 
> That *is* the WeakReference definition. Weak references are only cleared if their referent is determined to
> be weakly reachable. Doing a WeakReference.get() produces a strong reference, making the referent
> strongly reachable, and by-definition preventing the weak reference from being cleared until that strong
> reference is itself proven to be unreachable. Doing WeakReference.get() concurrently with collection activity
> will prevent that weak reference from being cleared in that cycle. Doing so continually and concurrently
> with all future collection activity has an obvious and well defined effect of preventing the reference from
> ever being cleared.

This makes complete sense… This is a bit of a “race” in that if the GC runs at the right time the weakly referenced object will be collected otherwise it will be “accidentally" strong. My guess is this is even trickier when marking concurrently… If this truly is a hot-get then you most likely shouldn’t be using a weak reference. It feels like an accident waiting to happen…. A poor replacement for a proper eviction policy if this is used in a cache.

> 
> C4 and G1 (and ZGC and Shenandoah) all treat WeakRefs the same [well established and correct] way
> in this regard AFAIK.

Not sure about G1.. well I’m sure it treats weak refs correctly but there is also something going on that isn’t allowing G1 to collect weak references as one would expect… maybe it’s like the time stamp issue in C4 that kept soft references live when they shouldn’t have been.

Kind regards,
Kirk


More information about the hotspot-dev mailing list