No class unloading by default?

Roman Kennke rkennke at redhat.com
Fri Oct 26 15:23:39 UTC 2018


> On 10/26/2018 04:00 AM, Roman Kennke wrote:
>> I believe we should not disable 'conc' class unloading by default. This
>> seems just wrong. It means that we're risking to pile up classes and
>> lots of auxiliary stuff like strings unless we run into full-gc which we
>> hope that we never have to do. Piling up that stuff means to negatively
>> impact our pause times. (Yes I know, class unloading also negatively
>> impacts pause times, but...) How is this setting justified?
> 
> http://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-May/006026.html
> 
> That is the tradeoff, it was called out at the time we disabled CU by default, and you acked it ;)
> 

Yeah. I am not really sure about it... We already had the 'let's
class-unload every N-th cycle' remedy. Maybe it would be useful to have
a better heuristic that let's class-unloading kick in when, say, one of
the affected structures (e.g. system-dict) has grown too large? Relying
on full-gc just seems wrong if we really want to not go there to begin
with...

Anyhow, I have a working patch here that does fully concurrent
string-table handling independend of class unloading. Fully concurrent
meaning just that: scan stringtable during conc-mark, evac+update during
conc-evac and keep it updated by doing storeval-barrier on stores into
the table. While concurrently cleaning the table during conc-evac we
return logical NULL for entries that are physically not yet cleaned but
not-reachable (and possibly broken because reclaimed already).

Not sure if we want that before upstreaming though. It introduces a
bunch of stuff that prepares for similar other stuff like concurrent
JNI/JVMTI handles (which should be easy to now) and ultimately
concurrent reference processing and class unloading (I've got halfway
prototype for conc ref processing too).

http://cr.openjdk.java.net/~rkennke/conc-stringtable/webrev.00/

 This does help with piling-up strings even if class unloading is disabled.

(It's not ready yet, it's lacking traversal impl, and verifier needs
some adjustment to deal with 'broken' intermediate state between marking
and evac...)

(We might want to go with a less adventurous approach for the start, and
make string table handling independent of class unloading, but still
handled during pause. This should be fairly straightforward.)

Roman



More information about the shenandoah-dev mailing list