RFR: Traversal: Don't traverse new objects

[Roman Kennke]

And also notice that this solves the potential termination problem because it bounds the set of objects to be traversed to the preexisting objects.

Roman


Am 5. Februar 2018 12:16:59 MEZ schrieb Roman Kennke <rkennke at redhat.com>:
>With Traversal GC I'm currently observing final-pauses of several dozen
>
>(e.g. ~70) ms. Turns out that almost all of it is just traversing 
>just-allocated objects. It occurs to me that this is pointless work: 
>we're not going to evacuate any new object during this cycle, and 
>liveness information may not be that useful either into next cycle 
>because it usually degenerates quickly (for new stuff). Let's not 
>traverse new-alloc-regions, and don't count liveness there, which means
>
>it's going to end up in next cycle's cset (just like the alloc-regions 
>between cycles). This cuts pauses down to 3-4ms. Yay!
>
>Notice that this is safe because new objects don't point to anything, 
>and any ref stored into new objects during the pause get picked up by 
>the enqueing barrier for I-U.
>
>Notice that we *do* need to traverse and account evac-regions, because 
>they have references pointing to interesting stuff. Hence the 
>disctinction for is_alloc_region() (better ideas welcome!).
>
>Also notice that this opens up an interesting opportunity for
>optimizing 
>the enqueue-barrier: we could now elide ENQBs on objects known to be 
>new. (In addition to known-NULL, which we already check, and 
>already-enqueued, which we don't do yet. We could also do pretty much 
>what we do with WBs and RBs and hoist them out of loops, etc. Lots of 
>work to do there, and opportunities for improvements).
>
>http://cr.openjdk.java.net/~rkennke/traversal-no-traverse-new/webrev.00/
>
>Ok?
>
>Roman

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