Weak Ref Processing

[Ing. Michal Frajt (Luxonit s.r.o.)]

> because precleaning takes care of them

The precleaning running in the concurrent cycle (Traversal Mode) takes in
our case significant portion of the concurrent cycle. Not sure,

but the source code indicates to me that the precleaning is done with 1
worker only (not using all ConcGCThreads threads available).

Something to be improved?

 

> Enqueueuing (putting references on associated ReferenceQueue, if any), is
done in final-mark STW pause as well.

Enqueueuing 150k weak references has already significant impact to the
final-mark STW pause in our case. It can easily jump from 5ms to 30ms range

just because of the enqueueuing need. We are even considering to create an
application solution for 'slowly' clearing strong references to split

enqueueuing over several cycles.

 

Generally I would prefer to promote a bit more in the presentation the
Traversal mode healthy impact to handling references. The deadly embracing 

references problem due to the SATB marking is simply not there. All works
like in the first generation of garbage collectors (serial, parallel, CMS).
For us it 

is a core requirement and we have huge interest in non-SATB markers like
Traversal mode implements in Shenandoah. I think Roman names it 'partial

incremental update' marker. The capability of Shenandoah to offer different
markers in general is something to be mentioned as well.

 

Michal

 

Date: Mon, 1 Apr 2019 17:23:26 +0200

From: Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com> >

To: Simone Bordet <simone.bordet at gmail.com <mailto:simone.bordet at gmail.com>
>,

                shenandoah-dev at openjdk.java.net
<mailto:shenandoah-dev at openjdk.java.net> 

Subject: Re: Weak Ref Processing

Message-ID: <e2f229fd-2091-4261-0a71-e754db4d18a8 at redhat.com
<mailto:e2f229fd-2091-4261-0a71-e754db4d18a8 at redhat.com> >

Content-Type: text/plain; charset=utf-8

 

On 4/1/19 5:12 PM, Simone Bordet wrote:

> I'm preparing for a conference session about Shenandoah (and ZGC), and

> I would like to confirm how Shenandoah does Weak (et al.) Reference

> Processing.

> 

> As far as I understand, weak reference processing is still a STW

> operation during the final mark phase, so GC parallel but not GC

> concurrent. Is that correct?

 

Depends on what "processing" means. The performance model for weakrefs is a
bit complicated.

 

Discovery (figuring out the references that exist in heap) is still done
concurrently during

concurrent mark. Precleaning (purging the references that have definitely
alive referents) is done

concurrently after mark. Processing (figuring out what to do with references
that have dead

referents, for example, clearing them or marking through the reachable
referent) is done in

final-mark STW pause. Enqueueuing (putting references on associated
ReferenceQueue, if any), is done

in final-mark STW pause as well.

 

So, the pause time depends on the weak references _churn_. For
references+referents that stay alive

there is little to no overhead (because precleaning takes care of them). For
references that die

along with referents, the cost is zero (because discovery never finds them).
For references that

have always clear referents (i.e. everything except finalizable), the
processing cost does not

involve marking through the suddenly reachable subgraph, so the cost is also
low, but not as low as

you might want, hence the desire to have concurrent reference processing.

 

Reference processing is performed by multiple parallel workers. When in
pause, it is guided by

ParallelGCThreads. In concurrent mode, by ConcGCThreads, and mostly
piggybacking on the actual GC

threads that do the marking.

 

> Is there any plan to make it concurrent, if not already?

 

Roman had a prototype, I would let him talk about it.

 

-Aleksey