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