Hi,

FYI, Oracle has a fix for the G1GC hang in UIMA waiting for review:

Issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8009536
Webrev: 
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-March/006215.html
Patch: http://cr.openjdk.java.net/~johnc/8009536/webrev.0/

Thanks to John Cuthbertson and Bengt Rutisson @ Oracle for fixing so fast! We 
just have to wait for a new JDK8 build with that fix included (and some more 
for the other Lucene-related bugs).
Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -----Original Message-----
> From: Mark Miller [mailto:markrmil...@gmail.com]
> Sent: Wednesday, March 06, 2013 7:52 PM
> To: dev@lucene.apache.org
> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32 bit)
> 
> Awesome work Uwe! Nice job getting this some attention.
> 
> - mark
> 
> On Mar 6, 2013, at 10:41 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> 
> > It seems that there is already an explanation from the Oracle engineer:
> >
> >> -----Original Message-----
> >> From: John Cuthbertson [mailto:john.cuthbert...@oracle.com]
> >> Sent: Wednesday, March 06, 2013 7:04 PM
> >> To: Thomas Schatzl
> >> Cc: Uwe Schindler; hotspot-gc-...@openjdk.java.net; 'David Holmes';
> >> 'Dawid Weiss'; hotspot-...@openjdk.java.net
> >> Subject: Re: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32
> >> bit)
> >>
> >> Hi Everyone,
> >>
> >> All:
> >> I've looked at the bug report (haven't tried to reproduce it yet) and
> >> Bengt's analysis is correct. The concurrent mark thread is entering
> >> the synchronization protocol in a marking step call. That code is
> >> waiting for some non-existent workers to terminate before proceeding.
> >> Normally we shouldn't be entering that code but I think we overflowed
> >> the global marking stack (I updated the CR at ~1am my time with that
> >> conjecture). I think I missed a set_phase() call to tell the parallel
> >> terminator that we only have one thread and it's picking up the
> >> number of workers that executed the remark parallel task.
> >>
> >> Thomas: you were on the right track with your comment about the
> >> marking stack size.
> >>
> >> David:
> >> Thanks for helping out here. The stack trace you mentioned was for
> >> one the refinement threads - a concurrent GC thread. When a
> >> concurrent GC thread "joins" the suspendible thread set, it means
> >> that it will observe and participate in safepoint operations, i.e.
> >> the thread will notice that it should reach a safepoint and the safepoint
> synchronizer code will wait for it to block.
> >> When we wish a concurrent GC thread to not observe safepoints, that
> >> thread leaves the suspendible thread set. I think the name could be a
> >> bit better and Tony, before he left, had a change that used a scoped
> >> object to join and leave the STS that hasn't been integrated yet.
> >> IIRC Tony wasn't happy with the name he chose for that also.
> >>
> >> Uwe:
> >> Thanks for bringing this up and my apologies for not replying sooner.
> >> I will have a fix fairly soon. If I'm correct about it being caused
> >> by overflowing the marking stack you can work around the issue by
> >> increasing the MarkStackSize.you could try increasing it to 2M or 4M
> >> entries (which is the current max size).
> >>
> >> Cheers,
> >>
> >> JohnC
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Uwe Schindler [mailto:u...@thetaphi.de]
> >> Sent: Wednesday, March 06, 2013 1:35 PM
> >> To: dev@lucene.apache.org
> >> Subject: FW: JVM hanging when using G1GC on JDK8 b78 or b79 (Linux 32
> >> bit)
> >>
> >> They already understood the G1GC problem with JDK 8 b78/b79 and
> >> working on a fix. This was really fast:
> >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-
> >> March/006128.html
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> H.-H.-Meier-Allee 63, D-28213 Bremen
> >> http://www.thetaphi.de
> >> eMail: u...@thetaphi.de
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to