Work queue overflow during re-mark?

[Jon Masamitsu]

Justin,

The queue mentioned is a per thread queue that
is used to remember objects that need to be
examined.  When the queue overflows, the objects
are put in a global queue which expands as needed
and which is shared by other GC threads.  The objects
do get examined in the current GC (it's just
remembered via the global queue).
The cost of an overflow is that the
global queue is used and access to the global queue
must be synchronized.  I don't recall if there
is a workaround for this.  I don't think
there is.  Maybe someone else on the alias knows.

Jon

Justin Ellison wrote:
> Hello all,
> 
> I'm running 1.4.2_17 on Solaris 9 Sparc.
> 
> When I was running 1.4.2_12 on the same system, I was experiencing bug
> 6558100.  I was able to get a fix backported to 1.4.2, and the fix was
> released in 1.4.2_17.
> 
> The bug where the VM crashed is certainly resolved, but occasionally I
> still get *a lot* of these lines printed to stdout:
> Java HotSpot(TM) Server VM warning: Work queue overflow during re-mark
> 
> By a lot, I mean 144,347 times since the VM was started 6 days ago.
> 
> The usage scenario is a website running jsps that make heavy use of
> caching in heap.  The log entries seem to follow cases where the
> caches are being cleared.  This makes sense, as a cache full of
> objects that all of a sudden become available for GC might fill a
> fixed queue.
> 
> My question is twofold - what is the impact of this, and is there any
> workaround for it?  I'm willing to sacrifice a little heap to increase
> that array size if need be.  Also, do those objects get GC'd next time
> around, or do they stick around?
> 
> Justin
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use