Race and double-counting objects in task balancing code?

[Roman Kennke]

I think I know what it is. This is the first GC mode in Shenandoah that 
also traces newly allocated objects. I believe what I am seeing is that 
the GC thread doesn't see the updated region top yet, and thus fails the 
assertion live <= used.

Roman

> Hi there,
> 
> I'm currently chasing a failure of TestGCThreadGroups.java with 
> Traversal GC. I'm getting objects double counted and liveness going off 
> the rails. It only seems to happen with ConcGCThreads > ParallelGCThreads.
> 
> I am wondering what prevents GC workers from stealing oops off of queues 
> that are currently transferred to 'regular' queues. ? Might we have a 
> race there? Is this transferral thread-safe wrt to stealing? Or am I 
> missing something? Please have a look at the last patch:
> 
> http://cr.openjdk.java.net/~rkennke/traversal/webrev.03/
> 
> around:
> 
> shenandoahTraversalGC.cpp mark_loop_work()
> 
> The code is almost 100% identical to what we do in 
> shenandoahConcurrentMark.cpp
> 
> I wonder if simply letting fewer GC threads steal from extra queues 
> might be the safer way to transfer work from extra queues?
> 
> Roman