From ysr1729 at gmail.com Thu Dec 1 09:08:15 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 1 Dec 2011 01:08:15 -0800 Subject: RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj In-Reply-To: <4ED6829F.8060702@oracle.com> References: <4ED6829F.8060702@oracle.com> Message-ID: Hi John -- I am wondering if we should simply prevent the second closure application if we have already done it once. That is easy to set-up. Of course such a test penalizes all collectors when they scan Reference objects, but perhaps the cost of the test will be lost in the noise of all the other test-logic when scanning Reference objects... But since G1 deals with multiple scans anyway, perhaps this is not worth worrying over. I also have some related questions: what forces G1 to have to deal with the multiple scan possibility anyway? I had previously incorrectly assumed that G1's remembered set scanning also avoids multiple scans of any reference... In the scenario that you outlined, when the second thread processes the reference the second time, how does it determine that it should do nothing? (I guess I am asking for a pointer to the code that does the processing of the stack elements and does the recursive copying.) thanks! -- ramki On Wed, Nov 30, 2011 at 11:23 AM, John Cuthbertson < john.cuthbertson at oracle.com> wrote: > Hi Everyone, > > Can I have a couple of volunteers look over the fix for this CR? The > webrev can be found at: http://http://cr.openjdk.java.** > net/~johnc/7114095/webrev.0/ > > Summary: > As a result of the changes for 4965777, we could apply the > G1ParScanClosure twice to the discovered field of a reference object. Once > because the closure itself has the apply_to_weak_discovered_field attribute > (as I think it should) and the other because of the changes for 4965777. > This causes the discovered field of an evacuated reference object to be > pushed to the _refs_to_scan queue twice. Normally this is not a problem as > the evacuation code can handle seeing the same object more than once. In > this case however, if the result of the first push is stolen and the > referenced object successfully evacuated by another worker thread, then the > assert is too strong. The other worker will update the discovered field to > point to the new location while the current thread is pushing the > discovered field for the second time. As a result when the current thread > executes the assert, the discovered field could have been updated and trips > the assert. > > The solution is to weaken the assert slightly. > > Testing: Both failing test cases running continuously overnight (they > typically fail within a few iterations); the GC test suite with a delay in > the offending code; jprt. > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Thu Dec 1 18:47:02 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 01 Dec 2011 10:47:02 -0800 Subject: RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj In-Reply-To: References: <4ED6829F.8060702@oracle.com> Message-ID: <4ED7CBA6.9070505@oracle.com> Hi Ramki, Response inline.... On 12/01/11 01:08, Srinivas Ramakrishna wrote: > Hi John -- I am wondering if we should simply prevent the second > closure application if we have already > done it once. That is easy to set-up. Of course such a test penalizes > all collectors when they scan Reference objects, but perhaps the cost > of the test > will be lost in the noise of all the other test-logic when scanning > Reference objects... Yes this is straight forward to do - but as you said it will add an additional clause to the if-condition that's around the second application. I have verified that this does seem to fix the problem. If I go with this approach - do you foresee any issues with skipping the second application of the closure to the discovered field? I don't think there is but it's worth asking the original author. :) I went with the fix that's in the webrev because it only touches G1 code. > But since G1 deals with multiple scans anyway, perhaps this is not > worth worrying over. > > I also have some related questions: what forces G1 to have to deal > with the multiple scan possibility anyway? > I had previously incorrectly assumed that G1's remembered set scanning > also avoids multiple scans of any > reference... During RSet scanning - the closure claims a group of cards. That along with a couple of "is_in_cset" tests seem to be enough to prevent multiple scans of the same reference field (i.e. pushing the same reference field on to the _refs_to_scan queue more than once). > In the scenario that you outlined, when the second thread processes > the reference the second > time, how does it determine that it should do nothing? (I guess I am > asking for a pointer to the > code that does the processing of the stack elements and does the > recursive copying.) The failing assert indicates that reference fields should only be pushed on to the _refs_to_scan queue once and mostly that seems to be the case. After an object is evacuated, the worker that successfully installs the forwarding pointer iterates over the reference fields of the evacuated object, applying the G1ParScanClosure. Since this is done by the thread that claims the object - we shouldn't see multiple pushes of the same reference field unless the closure is applied to the reference field multiple times. The discovered field of reference objects is the only field I've seen being pushed twice. As reference fields are popped from the _refs_to_scan queue, a copy closure is applied to them. This takes place in G1ParScanThreadState::deal_with_reference(). I believe the call in question comes from G1ParScanThreadState::trim_queue(). The copy closure dereferences the field and first checks that the referenced object is in the CSet before attempting to evacuate the object. This code is in G1ParCopyClosure::do_oop_work() and G1ParCopyHelper::copy_to_survivor_space() in g1CollectedHeap.cpp. The evacuation code has to handle multiple reference fields that point to the same object (an already evacuated object will not pass the "is_in_cset" check), and it looks like it can handle seeing the same reference field twice. The worst that I think can happen is that the reference field may be updated twice (to point to the same evacuated object). A while back, the evacuation code took a fourth template parameter - a boolean that indicated whether the "is_in_cset" check could be skipped, i.e. it was assumed that the closure would only be applied to objects in the collection set. If we still had that code then we wouldn't be able to handle this scenario. Does this answer your questions? Thanks, JohnC From jon.masamitsu at oracle.com Thu Dec 1 22:01:30 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 01 Dec 2011 22:01:30 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7106024: CMS: Removed unused code for precleaning in remark phase Message-ID: <20111201220132.4909F474EA@hg.openjdk.java.net> Changeset: ea640b5e949a Author: jmasa Date: 2011-11-22 14:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/ea640b5e949a 7106024: CMS: Removed unused code for precleaning in remark phase Summary: Remove dead code. Reviewed-by: stefank, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp From jon.masamitsu at oracle.com Fri Dec 2 01:54:24 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 02 Dec 2011 01:54:24 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure Message-ID: <20111202015426.4BC3F474F9@hg.openjdk.java.net> Changeset: 7913e93dca52 Author: jmasa Date: 2011-11-22 14:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7913e93dca52 7112997: Remove obsolete code ResetObjectsClosure and VerifyUpdateClosure Summary: Remove obsolete code. Reviewed-by: brutisso, ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp From john.coomes at oracle.com Fri Dec 2 04:50:30 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:50:30 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b15 for changeset a4f28069d44a Message-ID: <20111202045030.E5BC347508@hg.openjdk.java.net> Changeset: 4e06ae613e99 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/4e06ae613e99 Added tag jdk8-b15 for changeset a4f28069d44a ! .hgtags From john.coomes at oracle.com Fri Dec 2 04:50:39 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:50:39 +0000 Subject: hg: hsx/hotspot-gc/corba: 3 new changesets Message-ID: <20111202045042.67DD847509@hg.openjdk.java.net> Changeset: 44c269731425 Author: coffeys Date: 2011-11-11 10:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/44c269731425 7091388: Regular unexplained npe's from corba libs after system has been running for days Reviewed-by: alanb ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java Changeset: 7da69e7175a7 Author: lana Date: 2011-11-18 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/7da69e7175a7 Merge Changeset: 82dc033975bb Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/82dc033975bb Added tag jdk8-b15 for changeset 7da69e7175a7 ! .hgtags From john.coomes at oracle.com Fri Dec 2 04:50:48 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:50:48 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b15 for changeset 804f666d6d44 Message-ID: <20111202045048.2E9C24750A@hg.openjdk.java.net> Changeset: 8181f7634e4a Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/8181f7634e4a Added tag jdk8-b15 for changeset 804f666d6d44 ! .hgtags From john.coomes at oracle.com Fri Dec 2 04:50:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:50:53 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b15 for changeset c9ab96ff23d5 Message-ID: <20111202045053.759D54750B@hg.openjdk.java.net> Changeset: 76e37e606354 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/76e37e606354 Added tag jdk8-b15 for changeset c9ab96ff23d5 ! .hgtags From john.coomes at oracle.com Fri Dec 2 04:51:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 04:51:47 +0000 Subject: hg: hsx/hotspot-gc/jdk: 34 new changesets Message-ID: <20111202045734.9FE9647511@hg.openjdk.java.net> Changeset: 89952dc5be8e Author: prr Date: 2011-11-17 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/89952dc5be8e 7113017: Use POSIX compliant include file headers in sun/awt/medialib/mlib_types.h Reviewed-by: prr, bae Contributed-by: littlee at linux.vnet.ibm.com ! src/share/native/sun/awt/medialib/mlib_types.h Changeset: 60331bbcf4ad Author: lana Date: 2011-11-18 16:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/60331bbcf4ad Merge Changeset: f410b91caf45 Author: weijun Date: 2011-11-09 09:30 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f410b91caf45 7107019: sun.security.krb5.internal.ccache.CCacheInputStream.readCred does not use auth data Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java Changeset: 52be75d060f9 Author: weijun Date: 2011-11-09 15:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/52be75d060f9 7109096: keytool -genkeypair needn't call -selfcert Reviewed-by: xuelei ! src/share/classes/sun/security/tools/CertAndKeyGen.java ! src/share/classes/sun/security/tools/KeyTool.java Changeset: d6a5da5f6ba0 Author: dl Date: 2011-11-10 12:21 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d6a5da5f6ba0 7107516: LinkedBlockingQueue/Deque.drainTo(Collection, int) returns 'maxElements' if its value is negative Reviewed-by: chegar, mduigou, dholmes ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java Changeset: 0ccfb35cce26 Author: michaelm Date: 2011-11-10 15:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0ccfb35cce26 7110484: HttpServer.stop() not closing selector Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ServerImpl.java Changeset: e5d65a583c15 Author: michaelm Date: 2011-11-10 15:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e5d65a583c15 Merge Changeset: 830d2e46023a Author: lancea Date: 2011-11-10 11:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/830d2e46023a 7110111: Minor Java SE javadoc & Constructor clean up Reviewed-by: alanb, darcy Contributed-by: Martin Desruisseaux ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/util/jar/Attributes.java Changeset: 9dd994f319ee Author: coffeys Date: 2011-11-11 10:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9dd994f319ee 7105952: Improve finalisation for FileInputStream/FileOutputStream/RandomAccessFile Reviewed-by: alanb ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/solaris/classes/java/io/FileDescriptor.java ! src/windows/classes/java/io/FileDescriptor.java - test/java/io/FileDescriptor/FileChannelFDTest.java + test/java/io/FileDescriptor/Sharing.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 5c7c83a6ee24 Author: xuelei Date: 2011-11-14 01:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5c7c83a6ee24 7111548: unexpected debug log message Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: 68fc55d12ae6 Author: chegar Date: 2011-11-14 10:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/68fc55d12ae6 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself Reviewed-by: alanb, chegar Contributed-by: kurchi.subhra.hazra at oracle.com ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: c740519fe83a Author: weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: cd6d236e863b Author: okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author: okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1266e72f7896 Merge Changeset: 398442b00b2b Author: ksrini Date: 2011-11-16 12:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/398442b00b2b 7112160: jdk8 javadoc failure in jdk/make/docs javadoc: error - java.lang.OutOfMemoryError Reviewed-by: ohair, katleman ! make/docs/Makefile Changeset: 3cd7dcf4a302 Author: mchung Date: 2011-11-17 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3cd7dcf4a302 7067691: java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung Contributed-by: gary.adams at oracle.com ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: 5bfff9616b86 Author: weijun Date: 2011-11-18 16:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5bfff9616b86 7077172: KerberosTime does not take into account system clock adjustement Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/KerberosTime.java Changeset: cd37d8066437 Author: lana Date: 2011-11-18 11:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd37d8066437 Merge ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: c98235762b30 Author: alanb Date: 2011-11-19 19:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c98235762b30 6818464: TEST_BUG: java/util/Timer/KillThread.java failing intermittently Reviewed-by: dholmes, alanb, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 8be37eae9598 Author: alanb Date: 2011-11-19 19:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8be37eae9598 6731620: TEST_BUG: java/util/Timer/Args.java is too optimistic about the execution time of System.out.printf Reviewed-by: dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/Args.java Changeset: 450c17e4808d Author: alanb Date: 2011-11-19 20:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/450c17e4808d 6860309: TEST_BUG: Insufficient sleep time in java/lang/Runtime/exec/StreamsSurviveDestroy.java Reviewed-by: alanb, dholmes, forax Contributed-by: gary.adams at oracle.com ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java Changeset: 184578f3e8b9 Author: alanb Date: 2011-11-21 12:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/184578f3e8b9 7084033: TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently Reviewed-by: forax, chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/Stop.java Changeset: 2db942c7eb9c Author: alanb Date: 2011-11-21 12:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2db942c7eb9c 7114125: TEST_BUG: java/util/Timer/KillThread.java should use volatile cross thread variable declaration Reviewed-by: dholmes, alanb Contributed-by: gary.adams at oracle.com ! test/java/util/Timer/KillThread.java Changeset: 81987765cb81 Author: ngmr Date: 2011-11-11 14:40 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/81987765cb81 7112670: Inet4AddressImpl should use getaddrinfo/getnameinfo Reviewed-by: chegar, alanb, mduigou, ngmr Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h Changeset: ee2fa62fb09f Author: ngmr Date: 2011-11-22 09:51 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ee2fa62fb09f 7114558: Inet4AddressImpl should use memset (rather than bzero) and NI_MAXHOST (rather than MAXHOSTNAMELEN) Reviewed-by: chegar Contributed-by: Neil Richards ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 1945abeb82a0 Author: mullan Date: 2011-11-22 08:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1945abeb82a0 7093090: Reduce synchronization in java.security.Policy.getPolicyNoCheck Reviewed-by: valeriep ! src/share/classes/java/security/Policy.java Changeset: bb8f19b80557 Author: mullan Date: 2011-11-22 09:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/bb8f19b80557 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: b4d7020c2a40 Author: mullan Date: 2011-11-22 09:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b4d7020c2a40 Merge Changeset: 82151e860a64 Author: xuelei Date: 2011-11-23 03:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/82151e860a64 7113275: compatibility issue with MD2 trust anchor and old X509TrustManager Summary: also reviewed by Dennis.Gu at oracle.com Reviewed-by: mullan ! src/share/classes/sun/security/ssl/SSLContextImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java Changeset: 7eb0debca9b3 Author: chegar Date: 2011-11-23 12:30 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7eb0debca9b3 6776144: java/lang/ThreadGroup/NullThreadName.java fails with Thread group is not destroyed ,fastdebug LINUX Reviewed-by: chegar, dholmes Contributed-by: gary.adams at oracle.com ! test/java/lang/ThreadGroup/NullThreadName.java Changeset: d27f0b2f1476 Author: coffeys Date: 2011-11-23 14:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d27f0b2f1476 7102369: remove java.rmi.server.codebase property parsing from registyimpl 7094468: rmiregistry clean up Reviewed-by: smarks ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java + test/java/rmi/registry/readTest/readTest.java + test/java/rmi/registry/readTest/readTest.sh + test/java/rmi/registry/readTest/testPkg/Client.java + test/java/rmi/registry/readTest/testPkg/Hello.java + test/java/rmi/registry/readTest/testPkg/Server.java Changeset: 855675a4235b Author: lana Date: 2011-11-23 11:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/855675a4235b Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 3c248d0e2c48 Author: lana Date: 2011-11-28 15:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3c248d0e2c48 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 929597c6e777 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/929597c6e777 Added tag jdk8-b15 for changeset 3c248d0e2c48 ! .hgtags From ysr1729 at gmail.com Fri Dec 2 07:51:28 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 1 Dec 2011 23:51:28 -0800 Subject: RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj In-Reply-To: <4ED7CBA6.9070505@oracle.com> References: <4ED6829F.8060702@oracle.com> <4ED7CBA6.9070505@oracle.com> Message-ID: On Thu, Dec 1, 2011 at 10:47 AM, John Cuthbertson < john.cuthbertson at oracle.com> wrote: > Hi Ramki, > > Response inline.... > > > On 12/01/11 01:08, Srinivas Ramakrishna wrote: > >> Hi John -- I am wondering if we should simply prevent the second closure >> application if we have already >> done it once. That is easy to set-up. Of course such a test penalizes all >> collectors when they scan Reference objects, but perhaps the cost of the >> test >> will be lost in the noise of all the other test-logic when scanning >> Reference objects... >> > > Yes this is straight forward to do - but as you said it will add an > additional clause to the if-condition that's around the second application. > I have verified that this does seem to fix the problem. If I go with this > approach - do you foresee any issues with skipping the second application > of the closure to the discovered field? I don't think there is but it's > worth asking the original author. :) I went with the fix that's in the > webrev because it only touches G1 code. The only time we will be skipping the second application is when it's already been done in the earlier clause, which fires only for G1. So it will be skipped only in the case of G1 and then only in the case of closures that want to apply to the discovered field regardless. So I don't see any correctness issue (i.e. brittleness) arising from this approach. The only possible concern was, as we both seem to agree, in the possible performance impact of the additional boolean clause in the if-test (and it's initialization). I suspect the perf impact will be in the noise. Thus it would seem as though the only reason to prefer one or the other would be based on "taste". > > But since G1 deals with multiple scans anyway, perhaps this is not worth >> worrying over. >> >> I also have some related questions: what forces G1 to have to deal with >> the multiple scan possibility anyway? >> I had previously incorrectly assumed that G1's remembered set scanning >> also avoids multiple scans of any >> reference... >> > > During RSet scanning - the closure claims a group of cards. That along > with a couple of "is_in_cset" tests seem to be enough to prevent multiple > scans of the same reference field (i.e. pushing the same reference field on > to the _refs_to_scan queue more than once). Good. > > > In the scenario that you outlined, when the second thread processes the >> reference the second >> time, how does it determine that it should do nothing? (I guess I am >> asking for a pointer to the >> code that does the processing of the stack elements and does the >> recursive copying.) >> > > The failing assert indicates that reference fields should only be pushed > on to the _refs_to_scan queue once and mostly that seems to be the case. > After an object is evacuated, the worker that successfully installs the > forwarding pointer iterates over the reference fields of the evacuated > object, applying the G1ParScanClosure. Since this is done by the thread > that claims the object - we shouldn't see multiple pushes of the same > reference field unless the closure is applied to the reference field > multiple times. The discovered field of reference objects is the only > field I've seen being pushed twice. > > As reference fields are popped from the _refs_to_scan queue, a copy > closure is applied to them. This takes place in G1ParScanThreadState::deal_ > **with_reference(). I believe the call in question comes from > G1ParScanThreadState::trim_**queue(). The copy closure dereferences the > field and first checks that the referenced object is in the CSet before > attempting to evacuate the object. This code is in > G1ParCopyClosure::do_oop_work(**) and G1ParCopyHelper::copy_to_**survivor_space() > in g1CollectedHeap.cpp. > > The evacuation code has to handle multiple reference fields that point to > the same object (an already evacuated object will not pass the "is_in_cset" > check), and it looks like it can handle seeing the same reference field > twice. The worst that I think can happen is that the reference field may be > updated twice (to point to the same evacuated object). > > A while back, the evacuation code took a fourth template parameter - a > boolean that indicated whether the "is_in_cset" check could be skipped, > i.e. it was assumed that the closure would only be applied to objects in > the collection set. If we still had that code then we wouldn't be able to > handle this scenario. > > Does this answer your questions? > Very nicely. Thanks for the crystal clear explanation!! I'll let you decide which of the two approaches looks better to you. Left to myself I might be slightly inclined to go with the new solution of never letting a reference appear twice in the "gray list" by modifying the refernce object scanning. But I'm fine with either solution based on how you, Tony etc. feel about it. thanks John! -- ramki > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Fri Dec 2 10:05:17 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 02 Dec 2011 05:05:17 -0500 Subject: RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj In-Reply-To: <4ED6829F.8060702@oracle.com> References: <4ED6829F.8060702@oracle.com> Message-ID: <4ED8A2DD.7040408@oracle.com> John, The change is fine, please ship it. Having said that, I would ultimately like to ensure that during a GC we guarantee to scan each field only once (IIRC, all other GCs do that). Right now, as John pointed out in a previous e-mail, the code is robust with regards to fields being scanned twice. The reason this can happen (apart from the scenario described here) is that when we scan cards pointed to by RSets (and a single card might be included in different RSets that are scanned separately) we don't atomically claim each card (we put an indicator that a thread is scanning the card but not with an atomic operation). The reason this was done was to cut down on atomic operations during GC and it assumes that the number of cards that will be scanned twice will probably be quite small (which is most likely true). Unfortunately, in order for the code to be robust wrt being able to scan the same field twice (and keep in mind this happens really infrequently) we have to pay the penalty of an extra "is in CSet" test for each oop* we push/pop on/from the taskqueue (and said test is a bit more expensive in G1 compared to the "is young" test in the other GCs). If we can go back to guaranteeing that each field is scanned once, we can get rid of one of those tests and speed up / simplify the GC operation a bit. We should try to do that. I'll open a CR. But, John, meanwhile please push this. Tony On 11/30/2011 02:23 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers look over the fix for this CR? The > webrev can be found at: > http://http://cr.openjdk.java.net/~johnc/7114095/webrev.0/ > > Summary: > As a result of the changes for 4965777, we could apply the > G1ParScanClosure twice to the discovered field of a reference object. > Once because the closure itself has the apply_to_weak_discovered_field > attribute (as I think it should) and the other because of the changes > for 4965777. This causes the discovered field of an evacuated > reference object to be pushed to the _refs_to_scan queue twice. > Normally this is not a problem as the evacuation code can handle > seeing the same object more than once. In this case however, if the > result of the first push is stolen and the referenced object > successfully evacuated by another worker thread, then the assert is > too strong. The other worker will update the discovered field to > point to the new location while the current thread is pushing the > discovered field for the second time. As a result when the current > thread executes the assert, the discovered field could have been > updated and trips the assert. > > The solution is to weaken the assert slightly. > > Testing: Both failing test cases running continuously overnight (they > typically fail within a few iterations); the GC test suite with a > delay in the offending code; jprt. > > Thanks, > > JohnC From john.cuthbertson at oracle.com Fri Dec 2 18:09:17 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 02 Dec 2011 10:09:17 -0800 Subject: RFR (XS): 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj In-Reply-To: <4ED8A2DD.7040408@oracle.com> References: <4ED6829F.8060702@oracle.com> <4ED8A2DD.7040408@oracle.com> Message-ID: <4ED9144D.3060409@oracle.com> Hi Tony, Ramki, Thanks for the reviews. I'll push the change that's in the current webrev and add the patch which stops pushing the discovered field twice to the CR that Tony has filed. Thanks, JohnC On 12/2/2011 2:05 AM, Tony Printezis wrote: > John, > > The change is fine, please ship it. > > Having said that, I would ultimately like to ensure that during a GC > we guarantee to scan each field only once (IIRC, all other GCs do > that). Right now, as John pointed out in a previous e-mail, the code > is robust with regards to fields being scanned twice. The reason this > can happen (apart from the scenario described here) is that when we > scan cards pointed to by RSets (and a single card might be included in > different RSets that are scanned separately) we don't atomically claim > each card (we put an indicator that a thread is scanning the card but > not with an atomic operation). The reason this was done was to cut > down on atomic operations during GC and it assumes that the number of > cards that will be scanned twice will probably be quite small (which > is most likely true). Unfortunately, in order for the code to be > robust wrt being able to scan the same field twice (and keep in mind > this happens really infrequently) we have to pay the penalty of an > extra "is in CSet" test for each oop* we push/pop on/from the > taskqueue (and said test is a bit more expensive in G1 compared to the > "is young" test in the other GCs). If we can go back to guaranteeing > that each field is scanned once, we can get rid of one of those tests > and speed up / simplify the GC operation a bit. We should try to do > that. I'll open a CR. But, John, meanwhile please push this. > > Tony > > On 11/30/2011 02:23 PM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers look over the fix for this CR? The >> webrev can be found at: >> http://http://cr.openjdk.java.net/~johnc/7114095/webrev.0/ >> >> Summary: >> As a result of the changes for 4965777, we could apply the >> G1ParScanClosure twice to the discovered field of a reference object. >> Once because the closure itself has the >> apply_to_weak_discovered_field attribute (as I think it should) and >> the other because of the changes for 4965777. This causes the >> discovered field of an evacuated reference object to be pushed to the >> _refs_to_scan queue twice. Normally this is not a problem as the >> evacuation code can handle seeing the same object more than once. In >> this case however, if the result of the first push is stolen and the >> referenced object successfully evacuated by another worker thread, >> then the assert is too strong. The other worker will update the >> discovered field to point to the new location while the current >> thread is pushing the discovered field for the second time. As a >> result when the current thread executes the assert, the discovered >> field could have been updated and trips the assert. >> >> The solution is to weaken the assert slightly. >> >> Testing: Both failing test cases running continuously overnight (they >> typically fail within a few iterations); the GC test suite with a >> delay in the offending code; jprt. >> >> Thanks, >> >> JohnC From john.coomes at oracle.com Fri Dec 2 21:53:20 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Dec 2011 21:53:20 +0000 Subject: hg: hsx/hotspot-gc/langtools: 34 new changesets Message-ID: <20111202215433.0E73C47525@hg.openjdk.java.net> Changeset: b5d0b8effc85 Author: mcimadamore Date: 2011-10-17 12:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b5d0b8effc85 7097436: Project Coin: duplicate varargs warnings on method annotated with @SafeVarargs Summary: Duplicate aliasing check during subtyping leads to spurious varargs diagnostic Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/varargs/7097436/T7097436.java + test/tools/javac/varargs/7097436/T7097436.out ! test/tools/javac/varargs/warning/Warn5.java Changeset: 3cdfa97e1be9 Author: mcimadamore Date: 2011-10-17 12:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3cdfa97e1be9 7093325: Redundant entry in bytecode exception table Summary: Inlining of finalizers does not update gaps list accordingly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T7093325.java Changeset: 366c233eb838 Author: mcimadamore Date: 2011-10-19 16:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/366c233eb838 7102515: javac running very very long and not returning Summary: Verbose resolution diagnostics slow down with operator resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/7102515/T7102515.java + test/tools/javac/7102515/T7102515.out Changeset: d2cbb77469ed Author: jjg Date: 2011-10-19 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d2cbb77469ed 7101146: Paths should more directly managed by BaseFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java Changeset: b4021c520e40 Author: jjh Date: 2011-10-21 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b4021c520e40 7098530: tools/javac/javazip/Test.sh can fail on Windows Summary: Fix cygpath command to properly convert path Reviewed-by: jjg ! test/tools/javac/javazip/Test.sh Changeset: d346ab55031b Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d346ab55031b 7096014: Javac tokens should retain state Summary: Refactor javac tokens from enum constants to stateful instances (to keep track of position, comments, etc.) Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/main/AptJavaCompiler.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java ! src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/ScannerFactory.java - src/share/classes/com/sun/tools/javac/parser/Token.java + src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/depDocComment/DeprecatedDocComment3.java + test/tools/javac/tree/DocCommentToplevelTest.java Changeset: 05814303a056 Author: mcimadamore Date: 2011-10-24 13:00 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/05814303a056 7098660: Write better overload resolution/inference tests Summary: Add overload/inference debug diagnostics - added test harness using annotations to check outcome of overload resolution/inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ApplicableMethodFound.java + test/tools/javac/diags/examples/ApplicableMethodFound1.java + test/tools/javac/diags/examples/DeferredMethodInst.java + test/tools/javac/diags/examples/FullInstSig.java + test/tools/javac/diags/examples/NotApplicableMethodFound.java + test/tools/javac/diags/examples/PartialInstSig.java + test/tools/javac/diags/examples/VerboseResolveMulti.java + test/tools/javac/diags/examples/VerboseResolveMulti1.java + test/tools/javac/resolve/Candidate.java + test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/ResolveHarness.java + test/tools/javac/resolve/TraceResolve.java + test/tools/javac/resolve/tests/BoxedReturnTypeInference.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverInferred.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceOverVarargs.java + test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java + test/tools/javac/resolve/tests/PrimitiveOverload.java + test/tools/javac/resolve/tests/PrimitiveReturnTypeInference.java + test/tools/javac/resolve/tests/ReferenceOverInferred.java + test/tools/javac/resolve/tests/ReferenceOverVarargs.java + test/tools/javac/resolve/tests/ReferenceOverload.java Changeset: b73a9be0b993 Author: mcimadamore Date: 2011-10-25 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b73a9be0b993 7104618: MessageInfo.java is failing after lexer changes Summary: Two langtools regression tests cannot be built due to a bad import statement Reviewed-by: jjg ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: d830d28fc72e Author: jjg Date: 2011-10-25 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/d830d28fc72e 7104039: refactor/cleanup javac Paths class Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Locations.java - src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: a1eaf78ababb Author: jjh Date: 2011-10-25 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/a1eaf78ababb 7104905: Java SE build fails on call to CreateSymbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/Locations.java Changeset: 52df2131e294 Author: lana Date: 2011-10-25 21:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/52df2131e294 Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: f2d6ed25857d Author: lana Date: 2011-10-28 17:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f2d6ed25857d Merge - src/share/classes/com/sun/tools/javac/file/Paths.java - src/share/classes/com/sun/tools/javac/parser/DocCommentScanner.java - src/share/classes/com/sun/tools/javac/parser/Keywords.java - src/share/classes/com/sun/tools/javac/parser/Token.java Changeset: ae25163501bc Author: katleman Date: 2011-11-03 10:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ae25163501bc Added tag jdk8-b12 for changeset f2d6ed25857d ! .hgtags Changeset: 65444e7998e3 Author: katleman Date: 2011-11-10 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/65444e7998e3 Added tag jdk8-b13 for changeset ae25163501bc ! .hgtags Changeset: e52159ff8d0c Author: lana Date: 2011-10-25 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e52159ff8d0c Merge Changeset: 897b72b2751b Author: lana Date: 2011-10-26 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/897b72b2751b Merge - src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 9e2eb4bc49eb Author: jjh Date: 2011-11-01 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9e2eb4bc49eb 7101933: langtools jtreg tests do not work with jprt on windows Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1 and JCK to JCK8. Reviewed-by: jjg, ohair ! test/Makefile Changeset: 56830d5cb5bb Author: mcimadamore Date: 2011-11-04 12:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/56830d5cb5bb 7104201: Refactor DocCommentScanner Summary: Add new Comment helper class to parse contents of comments in source code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java + test/tools/javac/depDocComment/DeprecatedDocComment4.java + test/tools/javac/depDocComment/DeprecatedDocComment4.out Changeset: 11c184155128 Author: lana Date: 2011-11-05 00:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/11c184155128 Merge Changeset: ca49d50318dc Author: jjg Date: 2011-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ca49d50318dc 6921494: provide way to print javac tree tag values Reviewed-by: jjg, mcimadamore Contributed-by: vicenterz at yahoo.es ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: b7003a6a530b Author: lana Date: 2011-11-14 18:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/b7003a6a530b Merge Changeset: 15ea1c763273 Author: asaha Date: 2011-06-27 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/15ea1c763273 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif Changeset: c79cf0f04be6 Author: asaha Date: 2011-06-28 08:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c79cf0f04be6 Merge Changeset: 34e175c1fabc Author: asaha Date: 2011-07-19 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/34e175c1fabc Merge Changeset: c4478931e22d Author: asaha Date: 2011-11-07 21:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c4478931e22d Merge Changeset: 58f1325d72b2 Author: lana Date: 2011-11-14 18:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/58f1325d72b2 Merge Changeset: 16906df5bffc Author: katleman Date: 2011-11-17 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/16906df5bffc Added tag jdk8-b14 for changeset 58f1325d72b2 ! .hgtags Changeset: 36553cb94345 Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/36553cb94345 7108668: allow Log to be initialized and used earlier Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: ae361e7f435a Author: jjg Date: 2011-11-08 17:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ae361e7f435a 7108669: cleanup Log methods for direct printing to streams Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/JavacOption.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6410653/T6410653.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java Changeset: c1238fcc9515 Author: ksrini Date: 2011-11-14 08:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c1238fcc9515 7110974: (javac) add coding conventions and style checkers for langtools Reviewed-by: jjg ! make/build.properties ! make/build.xml + make/conf/checkstyle-emacs.xsl + make/conf/checkstyle-langtools.xml Changeset: 7375d4979bd3 Author: ksrini Date: 2011-11-14 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/7375d4979bd3 7106166: (javac) re-factor EndPos parser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java - src/share/classes/com/sun/tools/javac/parser/EndPosParser.java + src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/TreePosTest.java Changeset: f07d6f55d39a Author: lana Date: 2011-11-18 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/f07d6f55d39a Merge Changeset: 07599bd780ca Author: jjh Date: 2011-11-19 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/07599bd780ca 7110611: compiler message file broken for javac -fullversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: ec2c0973cc31 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ec2c0973cc31 Added tag jdk8-b15 for changeset 07599bd780ca ! .hgtags From john.cuthbertson at oracle.com Fri Dec 2 23:38:05 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 02 Dec 2011 23:38:05 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj Message-ID: <20111202233807.8739047547@hg.openjdk.java.net> Changeset: 4406629aa157 Author: johnc Date: 2011-12-02 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4406629aa157 7114095: G1: assert(obj == oopDesc::load_decode_heap_oop(p)) failed: p should still be pointing to obj Summary: As a result of the changes for 4965777, the G1 reference field scanning closure could be applied to the discovered field of a reference object twice. The failing assert is too strong if the result of the first application of the closure is stolen, and the referenced object, evacuated by another worker thread. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp From tony.printezis at oracle.com Mon Dec 5 16:57:42 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 05 Dec 2011 11:57:42 -0500 Subject: CRR (M): 7114678: G1: various small fixes, code cleanup, and refactoring In-Reply-To: <4ECBC49B.2020701@oracle.com> References: <4ECBC49B.2020701@oracle.com> Message-ID: <4EDCF806.7010003@oracle.com> Hi all, I have an updated webrev for these changes: http://cr.openjdk.java.net/~tonyp/7114678/webrev.1/webrev.all/ The breakdown is as before: http://cr.openjdk.java.net/~tonyp/7114678/webrev.1/webrev.0.G1LongLineFix/ http://cr.openjdk.java.net/~tonyp/7114678/webrev.1/webrev.1.G1PreHRIter/ (the latter is similar to the first version, with some additional changes to deal with Jon's dynamic GC worker changeset) And I have some additional refactoring which will help to keep some loops that use the iterators more concise: http://cr.openjdk.java.net/~tonyp/7114678/webrev.1/webrev.2.G1PreHRIterRefactor/ Here's the description from the CR: * We have a lot of switch statements on the VerifyOption embedded in the code. I abstracted them away in dedicated methods on G1CollectedHeap. * Introduced the CSetChooserParUpdater class which is used to add regions to the CollectionSetChooser array, either in parallel or (for completeness) serially. Currently, the code for the latter is embedded in the ParKnownGarbageHRClosure class and it's good to abstract it away. Tony On 11/22/2011 10:49 AM, Tony Printezis wrote: > Hi all, > > I have a bunch of small fixes I'd like to get reviewed. A lot of these > changes are a prelude to changing the way we iterate over heap regions > in G1 and I'd like to push them separately so that they can get tested > separately. > > The webrev is here: > > http://cr.openjdk.java.net/~tonyp/7114678/webrev.0/webrev.all/ > > It might be easier to look at it in two pieces given that one very > long line in g1CollectedHeap.cpp is making some view of the webrev a > bit hard to read (and with apologies as said long line was my fault). > So, here's the webrev to break down this line: > > http://cr.openjdk.java.net/~tonyp/7114678/webrev.0/webrev.0.G1LongLineFix/ > > > And here's the rest: > > http://cr.openjdk.java.net/~tonyp/7114678/webrev.0/webrev.1.G1PreHRIter/ > > I pasted the list of fixes (taken from the CR) below. Even though > there are lots of them, most of them are small / very self contained. > If you feel I should push some of these separately, I'll be happy to > do so. > > Tony > > > These fixes include (in no particular order): > > * Split up a very long single line "Heap Regions: (Y=young(eden), > SU=young(survivor), ..." into multiple ones. > > * Changed some of the iterations (in particular, all parallel > iterations) to skip continues humongous regions. This will ultimately > make the parallel iterator easier to write. In some cases, I had to > put logic in the body of the iteration to handle humongous regions > specially (e.g., when resetting GC time stamps). > > * Introduced G1CollectedHeap::reset_gc_time_stamps(HeapRegion* hr) > which resets the GC time stamp of the given region, as well as any > associated continues humongous regions if hr is starts humongous. > > * Introduced and call (non-product) check_gc_time_stamps() method that > ensures the GC time stamps of all regions have been correctly reset. > (If this sounds a bit paranoid: the GC time stamps getting out of sync > can result in really subtle and hard-to-reproduce/detect bugs.) > > * Factored out two heap region iterations into separate methods: > clear_rsets_post_compaction() (the iteration with > PostMCRemSetClearClosure) and print_hrs_post_compaction() (the > iteration with PostCompactionPrinterClosure). > > * Introduced G1CollectedHeap::start_region_for_worker() which > calculates which region each parallel worker should start from during > parallel iterations. > > * In G1MarkSweep, we currently use a closure to find the first region > in the heap. This is a bit unnecessary. I replaced it with getting > region 0 directly. > > * Re-implemeneted the HeapRegion::next_compaction_space() not to use > an iterator. Iterators actually wrap around which is not appropriate > here. > > * Remove G1CollectedHeap::heap_region_iterate_from() as it's not used > any more. > > * I removed the FILTERINTOCSCLOSURE_DOHISTOGRAMCOUNT and > FILTEROUTOFREGIONCLOSURE_DOHISTOGRAMCOUNT switches, along with any > associated fields and variables, as they are not used any more. > > * verify_dirty_young_regions() does not call dirty_dirty_young_list() > on first_survivor_region() any more as it's unnecessary: the list > starting from first_region() actually includes the survivors. > > * Removed the G1RSCountHisto develop parameter and associate closures. > > * Updated the HS_FORMAT macros to also show whether a region is > humongous (HS / HC), old (O), or free (F) instead of only showing > whether it's eden or survivor (the abbreviations are the same as what > we use for our per-region output). > > * Introduced two convenience methods on HeapRegion: > - region_num() returns the number of distinct regions that are covered > by the region (1 if non-humongous, >= 1 if humongous); I also updated > the HeapRegionSet classes to use this method instead of essentially > replicating the functionality > - last_hc_index() returns the index+1 of the last continues humongous > region associated with the target starts humongous region > > > > From tony.printezis at oracle.com Mon Dec 5 17:21:33 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 05 Dec 2011 12:21:33 -0500 Subject: G1 discovers same garbage again? In-Reply-To: <4ED5EAE1.2020102@java4.info> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> Message-ID: <4EDCFD9D.5040005@oracle.com> Florian, inline. On 11/30/2011 03:35 AM, Florian Binder wrote: >>> The application calculates the whole time with 10 threads some ratios >>> (high cpu load). This is done without producing any garbage. About two >>> times a minute a request is sent which produce a littlebit garbage. >>> Since we are working with realtime data we are interested in very short >>> stop-the-world pauses. Therefore we have used the CMS gc in the past >>> until we have got problems with fragmentation now. >> Since you don't produce much garbage how come you have fragmentation? >> Do you keep the results for all the requests you serve? > This data is hold one day and every night it is droped and reinitialized. > We have a lot of different server with big memory and have had problems > with fragmentation on few of them. I assume you know when the data will be dropped and reinitialized, right? Can you do a Full GC (with System.gc()) after you re-initialize the heap. This typically helps a lot with CMS. > This was the cause I am experiencing > with g1 in general. I am not sure if we had fragmentation on this one. G1 should not have fragmentation issues at the small / medium size object level. It might only if you allocate a lot of very large arrays (0.5MB+). > Today I tried the g1 with another server which surely have had a problem > with fragmented heap, but this one did not start wit g1. I got several > different exceptions (NoClassDefFound, NullPointerException or even a > jvm-crash ;-)). But I think I will write you another email especially > for this, because it is started with a lot of special parameters (e.g. > -Xms39G -Xmx39G -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16 > -XX:+UseLargePages). Does it work without compressed oops? I wonder whether we somewhere don't deal with the 16-byte alignment correctly. >>> Therefore I am trying the g1. >>> >>> This seemed to work very well at first. The stw-pauses were, except the >>> cleanup pause, >> Out of curiosity: how long are the cleanup pauses? > I think they were about 150ms. This is acceptable for me, but in > proportion to the garbage-collection of 30ms it is very long and > therefore I was wondering. Well, it's not acceptable to me. ;-) >>> The second cause for my email is the crazy behaviour after a few hours: >>> After the startup of the server it uses about 13.5 gb old-gen memory and >>> generates very slowly eden-garbage. Since the new allocated memory is >>> mostly garbage the (young) garbage collections are very fast and g1 >>> decides to grow up the eden space. This works 4 times until eden space >>> has more than about 3.5 gb memory. After this the gc is making much more >>> collections and while the collections it discovers new garbage (probably >>> the old one again). >> I'm not quite sure what you mean by "it discovers new garbage". For >> young GCs, G1 (and our other GCs) will reclaim any young objects that >> will discover to be dead (more accurately: that it will not discover >> to be live). >> >>> Eden memory usage jumps between 0 and 3.5gb even >>> though I am sure the java-application is not making more than before. >> Well, that's not good. :-) Can you try to explicitly set the young gen >> size with -Xmn3g say, to see what happens? > With "it discovers new garbage" I mean that during the garbage > collection the eden space usage jumps up to 3gb. Then it cleans up the > whole garbage (eden usage is 0) and a few seconds later the eden usage > jumps again up. You can see this in the 1h eden-space snapshot: > http://java4.info/g1/eden_1h.png > Since the jumps are betweend 0 and the last max eden usage (of about > 3.5gb) I assume that it discovers the same garbage, it cleaned up the > last time, and collects it again. I am sure the application is not > making more garbage than the time before. Have you ever heared of > problems like this? Here's a quick description of how the Eden and the other spaces in G1 work. Hopefully, this will help you understand this behavior a bit better. When new objects are allocated by the application the are placed in the Eden which is a set of regions. When the Eden is full we initiate a collection. During that collection we physically move all the surviving objects from the Eden regions to another set of regions called the Survivors. At the end of a collection the Eden regions have no more live objects (we copied them somewhere else) so we can reclaim them (which is why the Eden is empty after a GC). After a GC new objects are allocated into Eden regions (either new ones, or ones which were reclaimed before; it doesn't matter which) which make the Eden grow again. And when it's full it's again collected, etc. Does this explain better the behavior you see? > After I have written the last email, I have seen that it has calm itself > after a few hours. But it is nevertheless very curious and produces a > lot of unnecessary pauses. They are not really unnecessary. Each pause reclaims a lot of short-lived objects. Tony > Flo > >> Tony >> >>> I >>> assume that it runs during a collection in the old garbage and collects >>> it again. Is this possible? Or is there an overflow since eden space >>> uses more than 3.5 gb? >>> >>> Thanks and regards, >>> Flo >>> >>> Some useful information: >>> $ java -version >>> java version "1.6.0_29" >>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11) >>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) >>> >>> Startup Parameters: >>> -Xms20g -Xmx20g >>> -verbose:gc \ >>> -XX:+UnlockExperimentalVMOptions \ >>> -XX:+UseG1GC \ >>> -XX:+PrintGCDetails \ >>> -XX:+PrintGCDateStamps \ >>> -XX:+UseLargePages \ >>> -XX:+PrintFlagsFinal \ >>> -XX:-TraceClassUnloading \ >>> >>> $ cat /proc/meminfo | grep Huge >>> HugePages_Total: 11264 >>> HugePages_Free: 1015 >>> HugePages_Rsvd: 32 >>> Hugepagesize: 2048 kB >>> >>> A few screen-shots of the jconsole memory-view: >>> http://java4.info/g1/1h.png >>> http://java4.info/g1/all.png >>> http://java4.info/g1/eden_1h.png >>> http://java4.info/g1/eden_all.png >>> http://java4.info/g1/oldgen_all.png >>> >>> The sysout end syserr logfile with the gc logging and PrintFinalFlags: >>> http://java4.info/g1/out_err.log.gz >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From java at java4.info Mon Dec 5 19:19:00 2011 From: java at java4.info (Florian Binder) Date: Mon, 05 Dec 2011 20:19:00 +0100 Subject: G1 discovers same garbage again? In-Reply-To: <4EDCFD9D.5040005@oracle.com> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> Message-ID: <4EDD1924.2030803@java4.info> Hi Tony, inline. Am 05.12.2011 18:21, schrieb Tony Printezis: > Florian, > > inline. > > On 11/30/2011 03:35 AM, Florian Binder wrote: >>>> The application calculates the whole time with 10 threads some ratios >>>> (high cpu load). This is done without producing any garbage. About two >>>> times a minute a request is sent which produce a littlebit garbage. >>>> Since we are working with realtime data we are interested in very >>>> short >>>> stop-the-world pauses. Therefore we have used the CMS gc in the past >>>> until we have got problems with fragmentation now. >>> Since you don't produce much garbage how come you have fragmentation? >>> Do you keep the results for all the requests you serve? >> This data is hold one day and every night it is droped and >> reinitialized. >> We have a lot of different server with big memory and have had problems >> with fragmentation on few of them. > > I assume you know when the data will be dropped and reinitialized, > right? Can you do a Full GC (with System.gc()) after you re-initialize > the heap. This typically helps a lot with CMS. Yes, this is exactly what we are trying at this time ;-) Either this Full-GC pauses are very long (60-300 seconds) they are much shorter than after a CMS-failure (when they take sometimes more than 4000 seconds ;-)) and we can define when they occure. Maybe this will be our solution. It depends on the result of my g1-experience ;-) > >> This was the cause I am experiencing >> with g1 in general. I am not sure if we had fragmentation on this one. > > G1 should not have fragmentation issues at the small / medium size > object level. It might only if you allocate a lot of very large arrays > (0.5MB+). Ah ok, this is good to know. So if we have a lot of 10 MB byte arrays g1-might have problems with them? May it helpt to increase the G1HeapRegionSize to 20MB? Or is this to large and it would be better to break them down into smaller arrays (0.5mb)? > >> Today I tried the g1 with another server which surely have had a problem >> with fragmented heap, but this one did not start wit g1. I got several >> different exceptions (NoClassDefFound, NullPointerException or even a >> jvm-crash ;-)). But I think I will write you another email especially >> for this, because it is started with a lot of special parameters (e.g. >> -Xms39G -Xmx39G -XX:+UseCompressedOops -XX:ObjectAlignmentInBytes=16 >> -XX:+UseLargePages). > > Does it work without compressed oops? I wonder whether we somewhere > don't deal with the 16-byte alignment correctly. I will have more experience on this in the next days. I will tell you if I know something new. Maybe it is the combination with UseLargePages. > >>>> Therefore I am trying the g1. >>>> >>>> This seemed to work very well at first. The stw-pauses were, except >>>> the >>>> cleanup pause, >>> Out of curiosity: how long are the cleanup pauses? >> I think they were about 150ms. This is acceptable for me, but in >> proportion to the garbage-collection of 30ms it is very long and >> therefore I was wondering. > > Well, it's not acceptable to me. ;-) That is what I wanted to hear ^^ > >>>> The second cause for my email is the crazy behaviour after a few >>>> hours: >>>> After the startup of the server it uses about 13.5 gb old-gen >>>> memory and >>>> generates very slowly eden-garbage. Since the new allocated memory is >>>> mostly garbage the (young) garbage collections are very fast and g1 >>>> decides to grow up the eden space. This works 4 times until eden space >>>> has more than about 3.5 gb memory. After this the gc is making much >>>> more >>>> collections and while the collections it discovers new garbage >>>> (probably >>>> the old one again). >>> I'm not quite sure what you mean by "it discovers new garbage". For >>> young GCs, G1 (and our other GCs) will reclaim any young objects that >>> will discover to be dead (more accurately: that it will not discover >>> to be live). >>> >>>> Eden memory usage jumps between 0 and 3.5gb even >>>> though I am sure the java-application is not making more than before. >>> Well, that's not good. :-) Can you try to explicitly set the young gen >>> size with -Xmn3g say, to see what happens? >> With "it discovers new garbage" I mean that during the garbage >> collection the eden space usage jumps up to 3gb. Then it cleans up the >> whole garbage (eden usage is 0) and a few seconds later the eden usage >> jumps again up. You can see this in the 1h eden-space snapshot: >> http://java4.info/g1/eden_1h.png >> Since the jumps are betweend 0 and the last max eden usage (of about >> 3.5gb) I assume that it discovers the same garbage, it cleaned up the >> last time, and collects it again. I am sure the application is not >> making more garbage than the time before. Have you ever heared of >> problems like this? > > Here's a quick description of how the Eden and the other spaces in G1 > work. Hopefully, this will help you understand this behavior a bit > better. > > When new objects are allocated by the application the are placed in > the Eden which is a set of regions. When the Eden is full we initiate > a collection. During that collection we physically move all the > surviving objects from the Eden regions to another set of regions > called the Survivors. At the end of a collection the Eden regions have > no more live objects (we copied them somewhere else) so we can reclaim > them (which is why the Eden is empty after a GC). After a GC new > objects are allocated into Eden regions (either new ones, or ones > which were reclaimed before; it doesn't matter which) which make the > Eden grow again. And when it's full it's again collected, etc. So, after a (young) gc the eden space should increase only by the new allocated objects? Or is it possible that new non empty regions are used for the eden space, too? As you can see at http://java4.info/g1/eden_all.png from 13:20 until 18:00 the eden space is constantly growing (with a few gcs) just by the new objects (allocated by me). But after 18:00 There are frequent jumps which are much more than I would ever allocate. So what is causing them? First of all I thought g1 is taking some old-gen-regions to the gc because it has enough time to do this, but then I saw that in this cause "(partial)" will be append in the out-log: http://java4.info/g1/out_err.log.gz Furthermore this should not increase the total-heap-space: http://java4.info/g1/all.png Or is it possible that within a young gc only a few of the young regions are collected and reclaimed? Thanks, Flo > > Does this explain better the behavior you see? > >> After I have written the last email, I have seen that it has calm itself >> after a few hours. But it is nevertheless very curious and produces a >> lot of unnecessary pauses. > > They are not really unnecessary. Each pause reclaims a lot of > short-lived objects. > > Tony > >> Flo >> >>> Tony >>> >>>> I >>>> assume that it runs during a collection in the old garbage and >>>> collects >>>> it again. Is this possible? Or is there an overflow since eden space >>>> uses more than 3.5 gb? >>>> >>>> Thanks and regards, >>>> Flo >>>> >>>> Some useful information: >>>> $ java -version >>>> java version "1.6.0_29" >>>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11) >>>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) >>>> >>>> Startup Parameters: >>>> -Xms20g -Xmx20g >>>> -verbose:gc \ >>>> -XX:+UnlockExperimentalVMOptions \ >>>> -XX:+UseG1GC \ >>>> -XX:+PrintGCDetails \ >>>> -XX:+PrintGCDateStamps \ >>>> -XX:+UseLargePages \ >>>> -XX:+PrintFlagsFinal \ >>>> -XX:-TraceClassUnloading \ >>>> >>>> $ cat /proc/meminfo | grep Huge >>>> HugePages_Total: 11264 >>>> HugePages_Free: 1015 >>>> HugePages_Rsvd: 32 >>>> Hugepagesize: 2048 kB >>>> >>>> A few screen-shots of the jconsole memory-view: >>>> http://java4.info/g1/1h.png >>>> http://java4.info/g1/all.png >>>> http://java4.info/g1/eden_1h.png >>>> http://java4.info/g1/eden_all.png >>>> http://java4.info/g1/oldgen_all.png >>>> >>>> The sysout end syserr logfile with the gc logging and PrintFinalFlags: >>>> http://java4.info/g1/out_err.log.gz >>>> _______________________________________________ >>>> hotspot-gc-use mailing list >>>> hotspot-gc-use at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Mon Dec 5 20:53:50 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 05 Dec 2011 15:53:50 -0500 Subject: CRR (XS): 7118202: G1: eden size unnecessarily drops to the minimum Message-ID: <4EDD2F5E.6070306@oracle.com> Hi all, I'd like a couple of code reviews for this very small change: http://cr.openjdk.java.net/~tonyp/7118202/webrev.0/ It turns out that _max_rs_lengths gets smaller than _recorded_rs_lengths and rs_length_diff ends up huge which causes RSet lengths to be massively overpredicted. We'll leave this small fix in until we work out why the problem happens (or most likely until we revamp the whole prediction code as we're planning to). Thanks, again, to Thoms Schatzl for tracking this down. Tony From tony.printezis at oracle.com Mon Dec 5 21:09:38 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Mon, 05 Dec 2011 21:09:38 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 10 new changesets Message-ID: <20111205210959.CB1844758F@hg.openjdk.java.net> Changeset: 242b4e0e6f73 Author: phh Date: 2011-11-29 09:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/242b4e0e6f73 7116189: Export JVM_SetNativeThreadName from Hotspot Summary: Added JVM_SetNativeThreadName to linker mapfiles on Solaris and Linux. Reviewed-by: dcubed, dholmes Contributed-by: michael.x.mcmahon at oracle.com ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers Changeset: 763f01599ff4 Author: phh Date: 2011-11-29 17:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/763f01599ff4 7116481: Commercial features in Hotspot must be gated by a switch Summary: Add -XX:+UnlockCommercialVMOptions to gate use of commercial feature switches in the same way as -XX:UnlockDiagnosticVMOptions gates use of diagnostic feature switches. Reviewed-by: jwilhelm, kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 358eca91be48 Author: phh Date: 2011-11-30 12:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/358eca91be48 7116730: Revert 7116481: Commercial features in Hotspot must be gated by a switch Summary: Revert 7116481 to current hsx/hotspot-main Reviewed-by: kamg ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 81a08cd7f6a1 Author: coleenp Date: 2011-12-01 13:42 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81a08cd7f6a1 Merge Changeset: 1bbf5b6fb7b0 Author: tonyp Date: 2011-12-02 08:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1bbf5b6fb7b0 Merge ! src/share/vm/runtime/globals.hpp Changeset: d1f29d4e0bc6 Author: katleman Date: 2011-12-01 10:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d1f29d4e0bc6 Added tag jdk8-b15 for changeset fde2a39ed7f3 ! .hgtags Changeset: 6de8c9ba5907 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6de8c9ba5907 Merge Changeset: aed8bf036ce2 Author: jcoomes Date: 2011-12-02 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/aed8bf036ce2 Added tag hs23-b07 for changeset 6de8c9ba5907 ! .hgtags Changeset: cf4dd13bbcd3 Author: jcoomes Date: 2011-12-02 21:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cf4dd13bbcd3 7117536: new hotspot build - hs23-b08 Reviewed-by: johnc ! make/hotspot_version Changeset: e37aedaedccd Author: tonyp Date: 2011-12-05 12:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e37aedaedccd Merge From bengt.rutisson at oracle.com Mon Dec 5 21:35:35 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 05 Dec 2011 22:35:35 +0100 Subject: CRR (XS): 7118202: G1: eden size unnecessarily drops to the minimum In-Reply-To: <4EDD2F5E.6070306@oracle.com> References: <4EDD2F5E.6070306@oracle.com> Message-ID: <4EDD3927.70007@oracle.com> Tony, I am a bit uncomfortable with this change since we don't know exactly what is going on. But I think I would prefer this fix instead: 1557 if (_max_rs_lengths > _recorded_rs_lengths) { 1558 size_t rs_length_diff = _max_rs_lengths - _recorded_rs_lengths; 1559 _rs_length_diff_seq->add((double) rs_length_diff); 1560 } Seems more in line with the original code. I'd also like to understand if this statement (a little bit further down in the same method) is necessary: 1605 _rs_lengths_seq->add((double) _max_rs_lengths); Bengt On 2011-12-05 21:53, Tony Printezis wrote: > Hi all, > > I'd like a couple of code reviews for this very small change: > > http://cr.openjdk.java.net/~tonyp/7118202/webrev.0/ > > It turns out that _max_rs_lengths gets smaller than > _recorded_rs_lengths and rs_length_diff ends up huge which causes RSet > lengths to be massively overpredicted. > > We'll leave this small fix in until we work out why the problem > happens (or most likely until we revamp the whole prediction code as > we're planning to). > > Thanks, again, to Thoms Schatzl for tracking this down. > > Tony > From john.cuthbertson at oracle.com Mon Dec 5 23:10:59 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 05 Dec 2011 15:10:59 -0800 Subject: CRR (XS): 7118202: G1: eden size unnecessarily drops to the minimum In-Reply-To: <4EDD2F5E.6070306@oracle.com> References: <4EDD2F5E.6070306@oracle.com> Message-ID: <4EDD4F83.5060307@oracle.com> Hi Tony, This looks good to me. Thomas' diagnosis of the cause seems very plausible. JohnC On 12/05/11 12:53, Tony Printezis wrote: > Hi all, > > I'd like a couple of code reviews for this very small change: > > http://cr.openjdk.java.net/~tonyp/7118202/webrev.0/ > > It turns out that _max_rs_lengths gets smaller than > _recorded_rs_lengths and rs_length_diff ends up huge which causes RSet > lengths to be massively overpredicted. > > We'll leave this small fix in until we work out why the problem > happens (or most likely until we revamp the whole prediction code as > we're planning to). > > Thanks, again, to Thoms Schatzl for tracking this down. > > Tony > From stefan.karlsson at oracle.com Tue Dec 6 12:21:26 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 06 Dec 2011 12:21:26 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7112034: Parallel CMS fails to properly mark reference objects Message-ID: <20111206122129.263F147596@hg.openjdk.java.net> Changeset: f1391adc6681 Author: stefank Date: 2011-11-28 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f1391adc6681 7112034: Parallel CMS fails to properly mark reference objects Summary: Enabled reference processing when work stealing during concurrent marking Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp From stefan.karlsson at oracle.com Tue Dec 6 14:23:02 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Tue, 06 Dec 2011 14:23:02 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Message-ID: <20111206142304.B949447597@hg.openjdk.java.net> Changeset: f4414323345f Author: stefank Date: 2011-11-28 14:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f4414323345f 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM Summary: Changed the conditional to see if the precompiled header has been specified. Also, removed the unused PrecompiledOption. Reviewed-by: dholmes, brutisso ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/top.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/gcc.make From java at java4.info Tue Dec 6 20:23:41 2011 From: java at java4.info (Florian Binder) Date: Tue, 06 Dec 2011 21:23:41 +0100 Subject: VM-crash after starting with -XX:+UseLargePages -XX:+UseG1GC -XX:G1HeapRegionSize=16M Message-ID: <4EDE79CD.4080507@java4.info> Hi all, I was looking for a short test to reproduce the vm-crash when using ObjectAlignment=16 but found an other combination of options which result in a vm-crash ;-) I have attached the java-source to this email. Please let me know, if I should report this on an other way. Flo The startup command is: $ java -Xmx1g -Xms1g -XX:+UseLargePages -XX:+UseG1GC -XX:G1HeapRegionSize=16M Test # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002b368c17cfa0, pid=15290, tid=1097242944 # # JRE version: 6.0_29-b11 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 ) # Problematic frame: # V [libjvm.so+0x3b6fa0] CMTask::drain_local_queue(bool)+0xb0 # # An error report file with more information is saved as: # /home/fbr/g1test/hs_err_pid15290.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abgebrochen -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.java Type: text/x-java Size: 280 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.cuthbertson at oracle.com Wed Dec 7 17:59:08 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 07 Dec 2011 09:59:08 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Message-ID: <4EDFA96C.9020007@oracle.com> Hi Everyone, Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. Summary: I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. Thanks, JohnC From nhann at chalmers.se Wed Dec 7 22:20:08 2011 From: nhann at chalmers.se (Dang Nhan Nguyen) Date: Wed, 7 Dec 2011 22:20:08 +0000 Subject: Strange GC behaviour, Message-ID: Hi guys, I am benchmarking CMS collector and found it strange that there are many objects left in remark phase. When I check the issue again by only running foreground CMS (I changed the source code a bit to force CMS running in foreground), so there is no promotion during collecting (so no objects marked during Preclean and Abortable Preclean phase). Even in this case, I found that there are still many objects left in remark phase (in lusearch and tomcat in Dacapo benchmark, they are 10 times and 1/3 of number of objects marked in concmarking phase, while in suflow, they are just about 100 objects/refs). Most (maybe ALL) of these objects marked in remark phase were processed by refProcessingWork(). In turn, this refProcessingWork() run in single thread mode. The performance was reduced a lot because of this. My questions are: 1. What kinds of references were processed by refProcessingWork()? weak and soft ref? what are exactly they are? 2. While I only run CMS in stop-the-world, why are there still many objects left to be processed by remark, in particular here is refProcessingWork()? Why aren't these references/objects processed in concurrent marking phase? Best, -Nhan Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Thu Dec 8 01:44:02 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 7 Dec 2011 17:44:02 -0800 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: Hi Nhan -- Make sure you have the recent fix to Reference object processing when doing MT/Parallel marking with CMS; i don't have the CR handy, but the fix was pushed by Stefan not long ago. (The workaround was to disable parallel concurrent marking via -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that, depending on yr platform, might compromise yr benchmarking results.) More inline below:- On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen wrote: > Hi guys, > > I am benchmarking CMS collector and found it strange that there are many > objects left in remark phase. > > When I check the issue again by only running foreground CMS (I changed > the source code a bit to force CMS running in foreground), so there is no > promotion during collecting (so no objects marked during Preclean and > Abortable Preclean phase). Even in this case, I found that there are still > many objects left in remark phase (in lusearch and tomcat in Dacapo > benchmark, they are 10 times and 1/3 of number of objects marked in > concmarking phase, while in suflow, they are just about 100 objects/refs). > Most (maybe ALL) of these objects marked in remark phase were processed by > refProcessingWork(). In turn, this refProcessingWork() run in single thread > mode. The performance was reduced a lot because of this. > -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. > > My questions are: > 1. What kinds of references were processed by refProcessingWork()? weak > and soft ref? what are exactly they are? > all objects of type java.lang.ref.Reference (includes WeakReferencem=, SoftReference, FinalReference, PhantomReference). > 2. While I only run CMS in stop-the-world, why are there still many > objects left to be processed by remark, in particular here is > refProcessingWork()? Why aren't these references/objects processed in > concurrent marking phase? > I am not sure I understand the question. What do you mean by "run CMS in stop-the-world"? Note that Reference objects are processed by all kinds of collectors, young gen (minor) or whole heap (major), stop-world or concurrent. The volume of those objects may vary a bit between them based on the heap size, NewRatio etc. hope that helped. -- ramki > Best, > -Nhan Nguyen > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu Dec 8 03:41:26 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 07 Dec 2011 19:41:26 -0800 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: <4EE031E6.5000408@oracle.com> CR is 7112034 On 12/7/2011 5:44 PM, Srinivas Ramakrishna wrote: > Hi Nhan -- > > Make sure you have the recent fix to Reference object processing when doing > MT/Parallel marking with CMS; i don't have the CR handy, but the fix was > pushed by > Stefan not long ago. (The workaround was to disable parallel concurrent > marking via > -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that, > depending on yr platform, might compromise yr benchmarking results.) > > More inline below:- > > On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen wrote: > >> Hi guys, >> >> I am benchmarking CMS collector and found it strange that there are many >> objects left in remark phase. >> >> When I check the issue again by only running foreground CMS (I changed >> the source code a bit to force CMS running in foreground), so there is no >> promotion during collecting (so no objects marked during Preclean and >> Abortable Preclean phase). Even in this case, I found that there are still >> many objects left in remark phase (in lusearch and tomcat in Dacapo >> benchmark, they are 10 times and 1/3 of number of objects marked in >> concmarking phase, while in suflow, they are just about 100 objects/refs). >> Most (maybe ALL) of these objects marked in remark phase were processed by >> refProcessingWork(). In turn, this refProcessingWork() run in single thread >> mode. The performance was reduced a lot because of this. >> > -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. > > >> My questions are: >> 1. What kinds of references were processed by refProcessingWork()? weak >> and soft ref? what are exactly they are? >> > all objects of type java.lang.ref.Reference (includes WeakReferencem=, > SoftReference, FinalReference, PhantomReference). > > >> 2. While I only run CMS in stop-the-world, why are there still many >> objects left to be processed by remark, in particular here is >> refProcessingWork()? Why aren't these references/objects processed in >> concurrent marking phase? >> > I am not sure I understand the question. What do you mean by "run CMS in > stop-the-world"? Note that Reference objects are processed > by all kinds of collectors, young gen (minor) or whole heap (major), > stop-world or concurrent. The volume of those objects may > vary a bit between them based on the heap size, NewRatio etc. > > hope that helped. > -- ramki > > >> Best, >> -Nhan Nguyen >> From david.holmes at oracle.com Thu Dec 8 05:48:57 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Dec 2011 15:48:57 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EDFA96C.9020007@oracle.com> References: <4EDFA96C.9020007@oracle.com> Message-ID: <4EE04FC9.30605@oracle.com> Hi John, On 8/12/2011 3:59 AM, John Cuthbertson wrote: > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where we expect > monotonicity with calls os::javaTimeNanos(), converting the result to > milliseconds. os::javaTimeNanos(), at least on some configurations, does > guarantee monotonicity and so is a better alternative. javaTimeNanos is "guaranteed" monotonic if the underlying platform provides a monotonic timesource. I think this comment: ! // os::javaTimeMillis() does not guarantee monotonicity. might be better expressed as: // need to use a monotonic time source or perhaps // need a monotonic time in ms but os::javaTimeMillis() does not guarantee monotonicity > The changes in > the os_<*> files are to make use of the named conversion constants I > added/moved to globalDefinitions.hpp - we seemed to have multiple names > for the same two constants. Yeah that little cleanup has been on the to-do list for quite a while - thanks. genCollectedHeap.cpp: This comment block can be shortened from: ! // XXX Since javaTimeNanos() mostly guarantees monotonically ! // increasing return values, depending upon the underlying ! // os-dependent implementation, we still need to guard against ! // getting back a time later than now. This should be fixed ! // by basing the implementation on something like gethrtime() ! // which does guarantee monotonicity. ! // Note that cond_wait() is susceptible to a similar problem, ! // because its interface is based on absolute time in the form ! // of the system time's notion of UCT. See also 4506635 for yet ! // another problem of similar nature. XXX to just // javaTimeNanos() is guaranteed to be monotonic non-decreasing // provided the underlying platform provides such a time source // (and it is bug free). So we still have to guard against getting // back a time later than 'now'. javaTimeNanos _is_ based on gethrtime (on Solaris which is the only place it exists) or on CLOCK_MONOTONIC on Linux (if present). It is as monotonic as the platform provides. The ref to cond_wait is just completely out of place. David ----- > Testing: GC test suite on solaris and Linux, NSK tests on solaris, and > jprt. > > Thanks, > > JohnC From nhann at chalmers.se Thu Dec 8 10:41:56 2011 From: nhann at chalmers.se (Dang Nhan Nguyen) Date: Thu, 8 Dec 2011 10:41:56 +0000 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: Hi, Thank you for your update. I apply CR is 7112034 and also try with -XX:+ParallelRefProcEnabled: - While applying CR is 7112034, CMS still leaves about the same number of objects/ref marked for the remark phase comparing to before applying the CR. Which means the CR make no (or little) change to the number of references processed during the concurrent marking phase. How can this be explained? - When I use -XX:+ParallelRefProcEnabled, performance is worse than not using this option. So, when I enable this, how many threads were used for this reference processing (in a ratio of ParallelGCThreads and ConcGCThreads)? >From further information, in one application, 100k-200k references were left to the remark phase, and in another they are 1.5m references. Best, -Nhan From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] Sent: Thursday, December 08, 2011 2:44 AM To: Dang Nhan Nguyen Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: Strange GC behaviour, Hi Nhan -- Make sure you have the recent fix to Reference object processing when doing MT/Parallel marking with CMS; i don't have the CR handy, but the fix was pushed by Stefan not long ago. (The workaround was to disable parallel concurrent marking via -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that, depending on yr platform, might compromise yr benchmarking results.) More inline below:- On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen > wrote: Hi guys, I am benchmarking CMS collector and found it strange that there are many objects left in remark phase. When I check the issue again by only running foreground CMS (I changed the source code a bit to force CMS running in foreground), so there is no promotion during collecting (so no objects marked during Preclean and Abortable Preclean phase). Even in this case, I found that there are still many objects left in remark phase (in lusearch and tomcat in Dacapo benchmark, they are 10 times and 1/3 of number of objects marked in concmarking phase, while in suflow, they are just about 100 objects/refs). Most (maybe ALL) of these objects marked in remark phase were processed by refProcessingWork(). In turn, this refProcessingWork() run in single thread mode. The performance was reduced a lot because of this. -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. My questions are: 1. What kinds of references were processed by refProcessingWork()? weak and soft ref? what are exactly they are? all objects of type java.lang.ref.Reference (includes WeakReferencem=, SoftReference, FinalReference, PhantomReference). 2. While I only run CMS in stop-the-world, why are there still many objects left to be processed by remark, in particular here is refProcessingWork()? Why aren't these references/objects processed in concurrent marking phase? I am not sure I understand the question. What do you mean by "run CMS in stop-the-world"? Note that Reference objects are processed by all kinds of collectors, young gen (minor) or whole heap (major), stop-world or concurrent. The volume of those objects may vary a bit between them based on the heap size, NewRatio etc. hope that helped. -- ramki Best, -Nhan Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Thu Dec 8 16:14:38 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 8 Dec 2011 08:14:38 -0800 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: On Thu, Dec 8, 2011 at 2:41 AM, Dang Nhan Nguyen wrote: > Hi,**** > > ** ** > > Thank you for your update.**** > > I apply CR is 7112034 and also try with -XX:+ParallelRefProcEnabled:**** > > ** ** > > **- **While applying CR is 7112034, CMS still leaves about the same > number of objects/ref marked for the remark phase comparing to before > applying the CR. Which means the CR make no (or little) change to the > number of references processed during the concurrent marking phase. How > can this be explained? > Actually, prior to the fix for 7112034, there would be potentially fewer Reference objects identified for later processing (a step known as discovery). Following 7112034, there would be potentially more, as some objects not discovered before the fix would be discovered now. > **** > > **- **When I use -XX:+ParallelRefProcEnabled, performance is worse > than not using this option. So, when I enable this, how many threads were > used for this reference processing (in a ratio of ParallelGCThreads and > ConcGCThreads)? > This is the strange part, and to me does not make sense. How id you determine that (1) there were lots of Reference objects (2) that a lot of time was spent in Reference processing during remark? If you run with -XX:+PrintGCDetails -XX:+PrintReferenceGC for both the cases (with and withouyt -XX:+ParallelRefProcEnabled), we would know what the relative numbers/times looked like and perhaps get closer to what the issue might be here. > **** > > ** ** > > From further information, in one application, 100k-200k references were > left to the remark phase, and in another they are 1.5m references. > May be this is the natural behaviour of your application? One thing we have found to help is if we mak good use of the survivor spaces, then sometimes these probles will go away because Reference objects get processed as they become eligible for processing in the young generation (therefore during minor GC's) and thus do not impose a large monolithic overhead during the less frequent major collections. -- ramki > **** > > ** ** > > Best,**** > > -Nhan**** > > ** ** > > *From:* Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] > *Sent:* Thursday, December 08, 2011 2:44 AM > *To:* Dang Nhan Nguyen > *Cc:* hotspot-gc-dev at openjdk.java.net > *Subject:* Re: Strange GC behaviour,**** > > ** ** > > Hi Nhan -- > > Make sure you have the recent fix to Reference object processing when doing > MT/Parallel marking with CMS; i don't have the CR handy, but the fix was > pushed by > Stefan not long ago. (The workaround was to disable parallel concurrent > marking via > -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of > that, > depending on yr platform, might compromise yr benchmarking results.) > > More inline below:-**** > > On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen > wrote:**** > > Hi guys, **** > > ** ** > > I am benchmarking CMS collector and found it strange that there are many > objects left in remark phase.**** > > ** ** > > When I check the issue again by only running foreground CMS (I changed the > source code a bit to force CMS running in foreground), so there is no > promotion during collecting (so no objects marked during Preclean and > Abortable Preclean phase). Even in this case, I found that there are still > many objects left in remark phase (in lusearch and tomcat in Dacapo > benchmark, they are 10 times and 1/3 of number of objects marked in > concmarking phase, while in suflow, they are just about 100 objects/refs). > Most (maybe ALL) of these objects marked in remark phase were processed by > refProcessingWork(). In turn, this refProcessingWork() run in single thread > mode. The performance was reduced a lot because of this.**** > > > -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. > **** > > ** ** > > My questions are:**** > > 1. What kinds of references were processed by refProcessingWork()? weak > and soft ref? what are exactly they are?**** > > > all objects of type java.lang.ref.Reference (includes WeakReferencem=, > SoftReference, FinalReference, PhantomReference). > **** > > 2. While I only run CMS in stop-the-world, why are there still many > objects left to be processed by remark, in particular here is > refProcessingWork()? Why aren't these references/objects processed in > concurrent marking phase?**** > > > I am not sure I understand the question. What do you mean by "run CMS in > stop-the-world"? Note that Reference objects are processed > by all kinds of collectors, young gen (minor) or whole heap (major), > stop-world or concurrent. The volume of those objects may > vary a bit between them based on the heap size, NewRatio etc. > > hope that helped. > -- ramki**** > > ** ** > > Best,**** > > -Nhan Nguyen**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Thu Dec 8 17:44:06 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Thu, 08 Dec 2011 17:44:06 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7118202: G1: eden size unnecessarily drops to a minimum Message-ID: <20111208174412.6D2F04763F@hg.openjdk.java.net> Changeset: d23d2b18183e Author: tonyp Date: 2011-12-07 12:54 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d23d2b18183e 7118202: G1: eden size unnecessarily drops to a minimum Summary: An integer underflow can cause the RSet lengths to be massively overpredicted which forces the eden size to the minimum. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp From nhann at chalmers.se Thu Dec 8 18:20:17 2011 From: nhann at chalmers.se (Dang Nhan Nguyen) Date: Thu, 8 Dec 2011 18:20:17 +0000 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: Hi, >Actually, prior to the fix for 7112034, there would be potentially fewer Reference objects identified for later >processing (a step known as discovery). >Following 7112034, there would be potentially more, as some objects not discovered before the fix would be >discovered now. Agree! >This is the strange part, and to me does not make sense. How id you determine that (1) there were lots of >Reference objects (2) that a lot >of time was spent in Reference processing during remark? If you run with -XX:+PrintGCDetails ->XX:+PrintReferenceGC for both the >cases (with and withouyt -XX:+ParallelRefProcEnabled), we would know what the relative numbers/times looked >like and perhaps >get closer to what the issue might be here. Attached cms_lusearch.txt is output of PrintGCDetails which I skipped some ParNew GC part to reduce file size. The other is my record of number of objects marked in CMS phases. Since I run CMS in stop-the-world fashion (I change code a bit to do so), no object is promoted. cms_lusearch.log records live objects marked in that phase, I recorded it by increasing the counter everytime an object is marked successfully. I ran with below command line (don't worry about -XX:CMSInitiatingOccupancyFraction=100 -XX:+UseCMSInitiatingOccupancyOnly. I used it as part of my trick to cause CMS running in foreground): JAVA_HOME=../ build/linux-amd64/j2sdk-image LD_LIBRARY_PATH=../build/hotspot_product_prof/linux_amd64_compiler2/product ../ build/hotspot_product_prof/linux_amd64_compiler2/product/gamma -Xms100M -Xmx100M -XX:+PrintGCDetails -XX:+PrintReferenceGC -XX:CMSInitiatingOccupancyFraction=100 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8 -XX:NewRatio=10 -jar dacapo-9.12-bach.jar -s large -n 10 -t 8 lusearch I recorded high number of objects marked in remark phase. As you can see in the two files, the total number of references reported is around 2-3000 refs during remark. But the number of objects marked during remarked is much more than that: 600k objects (for lusearch application in Dacapo benchmark). Does this scenario normal? -Nhan From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] Sent: Thursday, December 08, 2011 5:15 PM To: Dang Nhan Nguyen Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: Strange GC behaviour, On Thu, Dec 8, 2011 at 2:41 AM, Dang Nhan Nguyen > wrote: Hi, Thank you for your update. I apply CR is 7112034 and also try with -XX:+ParallelRefProcEnabled: - While applying CR is 7112034, CMS still leaves about the same number of objects/ref marked for the remark phase comparing to before applying the CR. Which means the CR make no (or little) change to the number of references processed during the concurrent marking phase. How can this be explained? Actually, prior to the fix for 7112034, there would be potentially fewer Reference objects identified for later processing (a step known as discovery). Following 7112034, there would be potentially more, as some objects not discovered before the fix would be discovered now. - When I use -XX:+ParallelRefProcEnabled, performance is worse than not using this option. So, when I enable this, how many threads were used for this reference processing (in a ratio of ParallelGCThreads and ConcGCThreads)? This is the strange part, and to me does not make sense. How id you determine that (1) there were lots of Reference objects (2) that a lot of time was spent in Reference processing during remark? If you run with -XX:+PrintGCDetails -XX:+PrintReferenceGC for both the cases (with and withouyt -XX:+ParallelRefProcEnabled), we would know what the relative numbers/times looked like and perhaps get closer to what the issue might be here. >From further information, in one application, 100k-200k references were left to the remark phase, and in another they are 1.5m references. May be this is the natural behaviour of your application? One thing we have found to help is if we mak good use of the survivor spaces, then sometimes these probles will go away because Reference objects get processed as they become eligible for processing in the young generation (therefore during minor GC's) and thus do not impose a large monolithic overhead during the less frequent major collections. -- ramki Best, -Nhan From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] Sent: Thursday, December 08, 2011 2:44 AM To: Dang Nhan Nguyen Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: Strange GC behaviour, Hi Nhan -- Make sure you have the recent fix to Reference object processing when doing MT/Parallel marking with CMS; i don't have the CR handy, but the fix was pushed by Stefan not long ago. (The workaround was to disable parallel concurrent marking via -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that, depending on yr platform, might compromise yr benchmarking results.) More inline below:- On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen > wrote: Hi guys, I am benchmarking CMS collector and found it strange that there are many objects left in remark phase. When I check the issue again by only running foreground CMS (I changed the source code a bit to force CMS running in foreground), so there is no promotion during collecting (so no objects marked during Preclean and Abortable Preclean phase). Even in this case, I found that there are still many objects left in remark phase (in lusearch and tomcat in Dacapo benchmark, they are 10 times and 1/3 of number of objects marked in concmarking phase, while in suflow, they are just about 100 objects/refs). Most (maybe ALL) of these objects marked in remark phase were processed by refProcessingWork(). In turn, this refProcessingWork() run in single thread mode. The performance was reduced a lot because of this. -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. My questions are: 1. What kinds of references were processed by refProcessingWork()? weak and soft ref? what are exactly they are? all objects of type java.lang.ref.Reference (includes WeakReferencem=, SoftReference, FinalReference, PhantomReference). 2. While I only run CMS in stop-the-world, why are there still many objects left to be processed by remark, in particular here is refProcessingWork()? Why aren't these references/objects processed in concurrent marking phase? I am not sure I understand the question. What do you mean by "run CMS in stop-the-world"? Note that Reference objects are processed by all kinds of collectors, young gen (minor) or whole heap (major), stop-world or concurrent. The volume of those objects may vary a bit between them based on the heap size, NewRatio etc. hope that helped. -- ramki Best, -Nhan Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cms_lusearch.log Type: application/octet-stream Size: 1219 bytes Desc: cms_lusearch.log URL: -------------- next part -------------- Warning: name cms_lusearch_100M_8.1.er is in use; changed to cms_lusearch_100M_8.4.er WARNING: Linux-64-bit, 8 CPUs, Ubuntu_11.10 system "dark" is not supported by the Performance tools. WARNING: Data collection may fail: system is not properly configured or is unsupported. Creating experiment database ./lusearch/cms_lusearch_100M_8.4.er ... Using scaled threading model. 8 processors detected, 8 threads used to drive the workload, in a possible range of [1,128] ===== DaCapo 9.12 lusearch starting warmup 1 ===== [GC Using java runtime at: ../openjdkjvm/openjdk-mer/build/linux-amd64/j2sdk-image/jre [ParNew[SoftReference, 0 refs, 0.0000170 secs][WeakReference, 16 refs, 0.0000090 secs][FinalReference, 203 refs, 0.0002140 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001660 secs]: 7486K->895K(8384K), 0.0093490 secs] 7486K->2330K(101504K), 0.0093900 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] <<<<<<<<<<<<<<<<<<< Many similar ParNew GCs >>>>>>>>>>>>>>>>>>>> [GC [ParNew[SoftReference, 0 refs, 0.0000170 secs][WeakReference, 8 refs, 0.0000090 secs][FinalReference, 8 refs, 0.0000100 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001730 secs]: 7979K->504K(8384K), 0.0012370 secs] 92503K->85096K(101504K), 0.0012720 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000280 secs][WeakReference, 6 refs, 0.0000090 secs][FinalReference, 15 refs, 0.0000080 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001720 secs]: 7992K->512K(8384K), 0.0010670 secs] 92584K->85151K(101504K), 0.0011050 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000180 secs][WeakReference, 6 refs, 0.0000070 secs][FinalReference, 15 refs, 0.0000070 secs][PhantomReference, 0 refs, 0.0000070 secs][JNI Weak Reference, 0.0001730 secs]: 7995K->425K(8384K), 0.0023690 secs] 92634K->85066K(101504K), 0.0024060 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000160 secs][WeakReference, 2 refs, 0.0000070 secs][FinalReference, 5 refs, 0.0000070 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001750 secs]: 7910K->356K(8384K), 0.0023160 secs][CMSForeground collection takes control 2 (concurrent mode failure)[YG occupancy: 356 K (8384 K)][weak refs processing[SoftReference, 0 refs, 0.0000070 secs][WeakReference, 227 refs, 0.0000250 secs][FinalReference, 3085 refs, 0.0305350 secs][PhantomReference, 0 refs, 0.0000040 secs][JNI Weak Reference, 0.0001280 secs], 0.0307560 secs][Foreground_GCs: 1] : 84869K->28067K(93120K), 0.0762010 secs] 92551K->28424K(101504K), [CMS Perm : 5635K->5635K(21248K)], 0.0785770 secs] [Times: user=0.10 sys=0.00, real=0.08 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000210 secs][WeakReference, 0 refs, 0.0000070 secs][FinalReference, 0 refs, 0.0000070 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001730 secs]: 7844K->120K(8384K), 0.0014750 secs] 35912K->28298K(101504K), 0.0015100 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] <<<<<<<<<<<<<<<<<<< Many similar ParNew GCs >>>>>>>>>>>>>>>>>>>> [GC [ParNew[SoftReference, 0 refs, 0.0000160 secs][WeakReference, 2 refs, 0.0000080 secs][FinalReference, 1 refs, 0.0000060 secs][PhantomReference, 0 refs, 0.0000070 secs][JNI Weak Reference, 0.0001710 secs]: 7694K->211K(8384K), 0.0010980 secs] 92418K->84946K(101504K), 0.0011350 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000130 secs][WeakReference, 0 refs, 0.0000100 secs][FinalReference, 0 refs, 0.0000110 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001720 secs]: 7698K->102K(8384K), 0.0010090 secs][CMSForeground collection takes control 2 (concurrent mode failure)[YG occupancy: 102 K (8384 K)][weak refs processing[SoftReference, 0 refs, 0.0000060 secs][WeakReference, 58 refs, 0.0000120 secs][FinalReference, 2124 refs, 0.0291600 secs][PhantomReference, 0 refs, 0.0000030 secs][JNI Weak Reference, 0.0001290 secs], 0.0293700 secs][Foreground_GCs: 2] : 84842K->20152K(93120K), 0.0992390 secs] 92433K->20254K(101504K), [CMS Perm : 5653K->5653K(21248K)], 0.1003030 secs] [Times: user=0.12 sys=0.00, real=0.10 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000080 secs][WeakReference, 0 refs, 0.0000030 secs][FinalReference, 0 refs, 0.0000030 secs][PhantomReference, 0 refs, 0.0000030 secs][JNI Weak Reference, 0.0000970 secs]: 7590K->64K(8384K), 0.0008310 secs] 27742K->20218K(101504K), 0.0008570 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000110 secs][WeakReference, 0 refs, 0.0000050 secs][FinalReference, 0 refs, 0.0000030 secs][PhantomReference, 0 refs, 0.0000030 secs][JNI Weak Reference, 0.0000950 secs]: 7552K->47K(8384K), 0.0008380 secs] 27706K->20203K(101504K), 0.0008630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000100 secs][WeakReference, 0 refs, 0.0000050 secs][FinalReference, 0 refs, 0.0000030 secs][PhantomReference, 0 refs, 0.0000030 secs][JNI Weak Reference, 0.0000940 secs]: 7523K->58K(8384K), 0.0007570 secs] 27680K->20216K(101504K), 0.0007820 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000090 secs][WeakReference, 0 refs, 0.0000030 secs][FinalReference, 0 refs, 0.0000030 secs][PhantomReference, 0 refs, 0.0000030 secs][JNI Weak Reference, 0.0001880 secs]: 7546K->56K(8384K), 0.0007010 secs] 27704K->20217K(101504K), 0.0007250 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] <<<<<<<<<<<<<<<<<<< Many similar ParNew GCs >>>>>>>>>>>>>>>>>>>> [GC [ParNew[SoftReference, 0 refs, 0.0000160 secs][WeakReference, 0 refs, 0.0000070 secs][FinalReference, 0 refs, 0.0000060 secs][PhantomReference, 0 refs, 0.0000070 secs][JNI Weak Reference, 0.0001730 secs]: 7496K->36K(8384K), 0.0010970 secs] 58709K->51250K(101504K), 0.0011290 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000170 secs][WeakReference, 0 refs, 0.0000060 secs][FinalReference, 0 refs, 0.0000060 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001730 secs]: 7500K->36K(8384K), 0.0011540 secs] 58714K->51252K(101504K), 0.0011900 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000140 secs][WeakReference, 0 refs, 0.0000060 secs][FinalReference, 0 refs, 0.0000070 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001740 secs]: 7522K->26K(8384K), 0.0007900 secs] 58739K->51253K(101504K), 0.0008250 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000160 secs][WeakReference, 0 refs, 0.0000070 secs][FinalReference, 0 refs, 0.0000060 secs][PhantomReference, 0 refs, 0.0000060 secs][JNI Weak Reference, 0.0001740 secs]: 7500K->18K(8384K), 0.0009330 secs] 58727K->51253K(101504K), 0.0009660 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [ParNew[SoftReference, 0 refs, 0.0000170 secs][WeakReference, 0 refs, 0.0000090 secs][FinalReference, 0 refs, 0.0000080 secs][PhantomReference, 0 refs, 0.0000070 secs][JNI Weak Reference, 0.0001700 secs]: 7488K->24K(8384K), 0.0009420 secs] 58724K->51261K(101504K), 0.0009750 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 128 query batches completed ===== DaCapo 9.12 lusearch PASSED in 5272 msec ===== Heap par new generation total 8384K, used 4463K [0x00000000f4a00000, 0x00000000f5310000, 0x00000000f5310000) eden space 7488K, 59% used [0x00000000f4a00000, 0x00000000f4e55d50, 0x00000000f5150000) from space 896K, 2% used [0x00000000f5150000, 0x00000000f5156010, 0x00000000f5230000) to space 896K, 0% used [0x00000000f5230000, 0x00000000f5230000, 0x00000000f5310000) concurrent mark-sweep generation total 93120K, used 51237K [0x00000000f5310000, 0x00000000fae00000, 0x00000000fae00000) concurrent-mark-sweep perm gen total 21248K, used 5668K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000) From nhann at chalmers.se Thu Dec 8 20:02:15 2011 From: nhann at chalmers.se (Dang Nhan Nguyen) Date: Thu, 8 Dec 2011 20:02:15 +0000 Subject: Strange GC behaviour, In-Reply-To: References: Message-ID: I just found out that all the references marked during remark phase are FinalReferences. It's even more strange! -Nhan From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Dang Nhan Nguyen Sent: Thursday, December 08, 2011 7:20 PM To: Srinivas Ramakrishna Cc: hotspot-gc-dev at openjdk.java.net Subject: RE: Strange GC behaviour, Hi, >Actually, prior to the fix for 7112034, there would be potentially fewer Reference objects identified for later >processing (a step known as discovery). >Following 7112034, there would be potentially more, as some objects not discovered before the fix would be >discovered now. Agree! >This is the strange part, and to me does not make sense. How id you determine that (1) there were lots of >Reference objects (2) that a lot >of time was spent in Reference processing during remark? If you run with -XX:+PrintGCDetails ->XX:+PrintReferenceGC for both the >cases (with and withouyt -XX:+ParallelRefProcEnabled), we would know what the relative numbers/times looked >like and perhaps >get closer to what the issue might be here. Attached cms_lusearch.txt is output of PrintGCDetails which I skipped some ParNew GC part to reduce file size. The other is my record of number of objects marked in CMS phases. Since I run CMS in stop-the-world fashion (I change code a bit to do so), no object is promoted. cms_lusearch.log records live objects marked in that phase, I recorded it by increasing the counter everytime an object is marked successfully. I ran with below command line (don't worry about -XX:CMSInitiatingOccupancyFraction=100 -XX:+UseCMSInitiatingOccupancyOnly. I used it as part of my trick to cause CMS running in foreground): JAVA_HOME=../ build/linux-amd64/j2sdk-image LD_LIBRARY_PATH=../build/hotspot_product_prof/linux_amd64_compiler2/product ../ build/hotspot_product_prof/linux_amd64_compiler2/product/gamma -Xms100M -Xmx100M -XX:+PrintGCDetails -XX:+PrintReferenceGC -XX:CMSInitiatingOccupancyFraction=100 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=8 -XX:NewRatio=10 -jar dacapo-9.12-bach.jar -s large -n 10 -t 8 lusearch I recorded high number of objects marked in remark phase. As you can see in the two files, the total number of references reported is around 2-3000 refs during remark. But the number of objects marked during remarked is much more than that: 600k objects (for lusearch application in Dacapo benchmark). Does this scenario normal? -Nhan From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] Sent: Thursday, December 08, 2011 5:15 PM To: Dang Nhan Nguyen Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: Strange GC behaviour, On Thu, Dec 8, 2011 at 2:41 AM, Dang Nhan Nguyen > wrote: Hi, Thank you for your update. I apply CR is 7112034 and also try with -XX:+ParallelRefProcEnabled: - While applying CR is 7112034, CMS still leaves about the same number of objects/ref marked for the remark phase comparing to before applying the CR. Which means the CR make no (or little) change to the number of references processed during the concurrent marking phase. How can this be explained? Actually, prior to the fix for 7112034, there would be potentially fewer Reference objects identified for later processing (a step known as discovery). Following 7112034, there would be potentially more, as some objects not discovered before the fix would be discovered now. - When I use -XX:+ParallelRefProcEnabled, performance is worse than not using this option. So, when I enable this, how many threads were used for this reference processing (in a ratio of ParallelGCThreads and ConcGCThreads)? This is the strange part, and to me does not make sense. How id you determine that (1) there were lots of Reference objects (2) that a lot of time was spent in Reference processing during remark? If you run with -XX:+PrintGCDetails -XX:+PrintReferenceGC for both the cases (with and withouyt -XX:+ParallelRefProcEnabled), we would know what the relative numbers/times looked like and perhaps get closer to what the issue might be here. >From further information, in one application, 100k-200k references were left to the remark phase, and in another they are 1.5m references. May be this is the natural behaviour of your application? One thing we have found to help is if we mak good use of the survivor spaces, then sometimes these probles will go away because Reference objects get processed as they become eligible for processing in the young generation (therefore during minor GC's) and thus do not impose a large monolithic overhead during the less frequent major collections. -- ramki Best, -Nhan From: Srinivas Ramakrishna [mailto:ysr1729 at gmail.com] Sent: Thursday, December 08, 2011 2:44 AM To: Dang Nhan Nguyen Cc: hotspot-gc-dev at openjdk.java.net Subject: Re: Strange GC behaviour, Hi Nhan -- Make sure you have the recent fix to Reference object processing when doing MT/Parallel marking with CMS; i don't have the CR handy, but the fix was pushed by Stefan not long ago. (The workaround was to disable parallel concurrent marking via -XX:-CMSConcurrentMTEnabled -- but of course the performance impact of that, depending on yr platform, might compromise yr benchmarking results.) More inline below:- On Wed, Dec 7, 2011 at 2:20 PM, Dang Nhan Nguyen > wrote: Hi guys, I am benchmarking CMS collector and found it strange that there are many objects left in remark phase. When I check the issue again by only running foreground CMS (I changed the source code a bit to force CMS running in foreground), so there is no promotion during collecting (so no objects marked during Preclean and Abortable Preclean phase). Even in this case, I found that there are still many objects left in remark phase (in lusearch and tomcat in Dacapo benchmark, they are 10 times and 1/3 of number of objects marked in concmarking phase, while in suflow, they are just about 100 objects/refs). Most (maybe ALL) of these objects marked in remark phase were processed by refProcessingWork(). In turn, this refProcessingWork() run in single thread mode. The performance was reduced a lot because of this. -XX:+ParallelRefProcEnabled uses multiple threads to do that phase. My questions are: 1. What kinds of references were processed by refProcessingWork()? weak and soft ref? what are exactly they are? all objects of type java.lang.ref.Reference (includes WeakReferencem=, SoftReference, FinalReference, PhantomReference). 2. While I only run CMS in stop-the-world, why are there still many objects left to be processed by remark, in particular here is refProcessingWork()? Why aren't these references/objects processed in concurrent marking phase? I am not sure I understand the question. What do you mean by "run CMS in stop-the-world"? Note that Reference objects are processed by all kinds of collectors, young gen (minor) or whole heap (major), stop-world or concurrent. The volume of those objects may vary a bit between them based on the heap size, NewRatio etc. hope that helped. -- ramki Best, -Nhan Nguyen -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Thu Dec 8 20:28:42 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 08 Dec 2011 12:28:42 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE04FC9.30605@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE04FC9.30605@oracle.com> Message-ID: <4EE11DFA.1090304@oracle.com> Hi David, Thanks for the code review comments - I'll change the comments to what you suggest and send out a new webrev. JohnC On 12/07/11 21:48, David Holmes wrote: > Hi John, > > On 8/12/2011 3:59 AM, John Cuthbertson wrote: >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect >> monotonicity with calls os::javaTimeNanos(), converting the result to >> milliseconds. os::javaTimeNanos(), at least on some configurations, does >> guarantee monotonicity and so is a better alternative. > > javaTimeNanos is "guaranteed" monotonic if the underlying platform > provides a monotonic timesource. > > I think this comment: > > ! // os::javaTimeMillis() does not guarantee monotonicity. > > might be better expressed as: > > // need to use a monotonic time source > > or perhaps > > // need a monotonic time in ms but os::javaTimeMillis() does not > guarantee monotonicity > >> The changes in >> the os_<*> files are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have multiple names >> for the same two constants. > > Yeah that little cleanup has been on the to-do list for quite a while > - thanks. > > genCollectedHeap.cpp: > > This comment block can be shortened from: > > ! // XXX Since javaTimeNanos() mostly guarantees monotonically > ! // increasing return values, depending upon the underlying > ! // os-dependent implementation, we still need to guard against > ! // getting back a time later than now. This should be fixed > ! // by basing the implementation on something like gethrtime() > ! // which does guarantee monotonicity. > ! // Note that cond_wait() is susceptible to a similar problem, > ! // because its interface is based on absolute time in the form > ! // of the system time's notion of UCT. See also 4506635 for yet > ! // another problem of similar nature. XXX > > to just > > // javaTimeNanos() is guaranteed to be monotonic non-decreasing > // provided the underlying platform provides such a time source > // (and it is bug free). So we still have to guard against getting > // back a time later than 'now'. > > javaTimeNanos _is_ based on gethrtime (on Solaris which is the only > place it exists) or on CLOCK_MONOTONIC on Linux (if present). It is as > monotonic as the platform provides. The ref to cond_wait is just > completely out of place. > > David > ----- > >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and >> jprt. >> >> Thanks, >> >> JohnC From tony.printezis at oracle.com Thu Dec 8 22:04:22 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 08 Dec 2011 17:04:22 -0500 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" Message-ID: <4EE13466.6030603@oracle.com> Hi all, Could I have a couple of volunteers to look at this change? http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ We decided that the terms "fully-young" and "partially-young" GCs were awkward so we are renaming them to "young" and "mixed". This change not only changes the external G1 output that uses these terms (i.e., GC log and GC ergonomic decision log) but also renames all the occurrences of those terms in the code itself (fields, methods, comments, etc.). Initially, I was not going to do the latter but it turned out that the changes were not too many. So it's good to make the code consistent with our current terminology. These are the most common fields / methods that I renamed: _full_young_gcs -> _gcs_are_young full_young_gcs() -> gcs_are_young() set_full_young_gcs() -> set_gcs_are_young() _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs _last_full_young_gc -> _last_young_gc _last_young_gc_full -> _last_gc_was_young The changeset also includes some very minor code cleanup (mainly introduction of curly brackets in if-else statements). Tony From john.cuthbertson at oracle.com Fri Dec 9 02:26:37 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 08 Dec 2011 18:26:37 -0800 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: <4EE13466.6030603@oracle.com> References: <4EE13466.6030603@oracle.com> Message-ID: <4EE171DD.3060007@oracle.com> Hi Tony, This looks good to me. And thanks for changing the terms within the code - it looks a lot nicer. JohnC On 12/08/11 14:04, Tony Printezis wrote: > Hi all, > > Could I have a couple of volunteers to look at this change? > > http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ > > We decided that the terms "fully-young" and "partially-young" GCs were > awkward so we are renaming them to "young" and "mixed". This change > not only changes the external G1 output that uses these terms (i.e., > GC log and GC ergonomic decision log) but also renames all the > occurrences of those terms in the code itself (fields, methods, > comments, etc.). Initially, I was not going to do the latter but it > turned out that the changes were not too many. So it's good to make > the code consistent with our current terminology. > > These are the most common fields / methods that I renamed: > > _full_young_gcs -> _gcs_are_young > full_young_gcs() -> gcs_are_young() > set_full_young_gcs() -> set_gcs_are_young() > _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs > _last_full_young_gc -> _last_young_gc > _last_young_gc_full -> _last_gc_was_young > > The changeset also includes some very minor code cleanup (mainly > introduction of curly brackets in if-else statements). > > Tony > From tony.printezis at oracle.com Fri Dec 9 16:11:48 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 09 Dec 2011 11:11:48 -0500 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: <4EE171DD.3060007@oracle.com> References: <4EE13466.6030603@oracle.com> <4EE171DD.3060007@oracle.com> Message-ID: <4EE23344.8040908@oracle.com> John, Thanks for the prompt code review! Tony On 12/08/2011 09:26 PM, John Cuthbertson wrote: > Hi Tony, > > This looks good to me. And thanks for changing the terms within the > code - it looks a lot nicer. > > JohnC > > On 12/08/11 14:04, Tony Printezis wrote: >> Hi all, >> >> Could I have a couple of volunteers to look at this change? >> >> http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ >> >> We decided that the terms "fully-young" and "partially-young" GCs >> were awkward so we are renaming them to "young" and "mixed". This >> change not only changes the external G1 output that uses these terms >> (i.e., GC log and GC ergonomic decision log) but also renames all the >> occurrences of those terms in the code itself (fields, methods, >> comments, etc.). Initially, I was not going to do the latter but it >> turned out that the changes were not too many. So it's good to make >> the code consistent with our current terminology. >> >> These are the most common fields / methods that I renamed: >> >> _full_young_gcs -> _gcs_are_young >> full_young_gcs() -> gcs_are_young() >> set_full_young_gcs() -> set_gcs_are_young() >> _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs >> _last_full_young_gc -> _last_young_gc >> _last_young_gc_full -> _last_gc_was_young >> >> The changeset also includes some very minor code cleanup (mainly >> introduction of curly brackets in if-else statements). >> >> Tony >> > From jon.masamitsu at oracle.com Fri Dec 9 17:14:25 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 09 Dec 2011 09:14:25 -0800 Subject: Request for review (s) - 7119584 Message-ID: <4EE241F1.7090300@oracle.com> 7119584: UseParallelGC barrier task can be overwritten. Just a few changed lines. The comments around the changes give an explanation in context so are a better explanation than I can summarize here. http://cr.openjdk.java.net/~jmasa/7119584/webrev.00/ Thanks. From vitalyd at gmail.com Fri Dec 9 17:48:55 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 9 Dec 2011 12:48:55 -0500 Subject: Request for review (s) - 7119584 In-Reply-To: <4EE241F1.7090300@oracle.com> References: <4EE241F1.7090300@oracle.com> Message-ID: Hi Jon, Are you sure your comment for the OrderAccess::storestore() matches this barrier? Your comment mentions that you want global visibility but does this need immediate visibility or you just want order for when it does become visible? StoreStore is just the latter, but maybe that's what you meant. Regards, Vitaly On Dec 9, 2011 12:15 PM, "Jon Masamitsu" wrote: > 7119584: UseParallelGC barrier task can be overwritten. > > Just a few changed lines. The comments around the changes > give an explanation in context so are a better explanation than > I can summarize here. > > http://cr.openjdk.java.net/~**jmasa/7119584/webrev.00/ > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Fri Dec 9 19:18:22 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 09 Dec 2011 11:18:22 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse Message-ID: <4EE25EFE.9090902@oracle.com> Hi Everyone, Can I have a couple of volunteers to review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ Summary: As part of the code review comments for 7112743 (G1: Reduce overhead of marking closure during evacuation pauses) it was suggested that instead of recalculating the starting heap region for each worker thread, we reuse the values calculated during RSet scanning. These changes address that review comment. In these changes I maintain a cache that is used and updated by G1CollectedHeap::start_cset_region_for_worker(). The first time this routine is called by a worker thread during an evacuation pause (currently during RSet scanning) the cached value for the worker gets set; when the routine is called subsequently the region that was cached for the worker is returned. I employ a simple stamp mechanism based upon the number of GCs that ensures the validity of the regions in the cache and makes clearing the cache unnecessary. Testing: GC Test suite with a small marking threshold (10%) with and without verification; the configuration of SPECjbb used to test 7117423; Kitchensink. Thanks, JohnC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Dec 9 19:28:32 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 09 Dec 2011 19:28:32 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 20 new changesets Message-ID: <20111209192913.315D647651@hg.openjdk.java.net> Changeset: cd00eaeebef6 Author: phh Date: 2011-12-05 12:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cd00eaeebef6 7117389: Add a framework for vendor-specific command line switch extensions to Hotspot Summary: Add a file, globals_ext.hpp, containing a null interface, to be replaced by a vendor in altsrc as needed. Reviewed-by: coleenp, kamg, dholmes, johnc, jrose ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp + src/share/vm/runtime/globals_ext.hpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 8657ec177a14 Author: dcubed Date: 2011-12-05 14:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8657ec177a14 7117748: SA_APPLE_BOOT_JAVA and ALWAYS_PASS_TEST_GAMMA settings should not be required on MacOS X Summary: Replace SA_APPLE_BOOT_JAVA with logic that checks the boot JDK for the location of JDI classes. ALWAYS_PASS_TEST_GAMMA is true by default on Darwin. Reviewed-by: kvn, swingler ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/sa.make Changeset: 41cce03b29a8 Author: dcubed Date: 2011-12-06 05:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/41cce03b29a8 Merge Changeset: 03865c41c4f3 Author: vladidan Date: 2011-12-06 16:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/03865c41c4f3 Merge ! src/share/vm/runtime/globals.hpp Changeset: 55d777c0860a Author: dcubed Date: 2011-12-07 07:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/55d777c0860a 7118648: disable compressed oops by default on MacOS X until 7118647 is fixed Summary: UseCompressedOops is false by default on MacOS X; can still be set manually Reviewed-by: jmelvin, kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: e8fdaf4a66cb Author: kvn Date: 2011-11-10 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e8fdaf4a66cb 7110586: C2 generates incorrect results Summary: Exact limit of empty loop calculated incorrectly. Reviewed-by: iveresov, never ! src/share/vm/opto/loopnode.cpp + test/compiler/7110586/Test7110586.java Changeset: 8c57262447d3 Author: kvn Date: 2011-11-14 18:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/8c57262447d3 7105605: Use EA info to optimize pointers compare Summary: optimize pointers compare using EA information. Reviewed-by: never, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 6729bbc1fcd6 Author: twisti Date: 2011-11-16 01:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6729bbc1fcd6 7003454: order constants in constant table by number of references in code Reviewed-by: kvn, never, bdelsart ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/matcher.hpp Changeset: 1bd45abaa507 Author: kvn Date: 2011-11-16 09:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1bd45abaa507 6890673: Eliminate allocations immediately after EA Summary: Try to eliminate allocations and related locks immediately after escape analysis. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: 973293defacd Author: iveresov Date: 2011-11-16 19:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/973293defacd 7112085: assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks Summary: Move the inlinee invoke notification callback into inlinee preamble Reviewed-by: kvn, never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/runtime/simpleThresholdPolicy.cpp ! src/share/vm/runtime/simpleThresholdPolicy.hpp ! test/compiler/6792161/Test6792161.java Changeset: a04a201f0f5a Author: twisti Date: 2011-11-17 04:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a04a201f0f5a 7108383: JSR 292: JRuby bench_define_method_methods.rb: assert(slow_jvms != NULL) failed: miss path must not Reviewed-by: kvn, never ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: 59bc0d4d9ea3 Author: never Date: 2011-11-18 10:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/59bc0d4d9ea3 7110489: C1: 64-bit tiered with ForceUnreachable: assert(reachable(src)) failed: Address should be reachable Reviewed-by: kvn, iveresov, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 7793051af7d6 Author: twisti Date: 2011-11-21 00:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7793051af7d6 7110058: change default for ScavengeRootsInCode to 2 Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp Changeset: f03a3c8bd5e5 Author: roland Date: 2011-09-14 09:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f03a3c8bd5e5 7077312: Provide a CALL effect for instruct declaration in the ad file Summary: abstracted way to declare that the MachNode has the effect of a call (kills caller save registers, preserves callee save registers) Reviewed-by: twisti, never ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/machnode.hpp ! src/share/vm/opto/node.hpp Changeset: db2e64ca2d5a Author: roland Date: 2011-11-22 09:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/db2e64ca2d5a 7090968: Allow adlc register class to depend on runtime conditions Summary: allow reg_class definition as a function. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/matcher.hpp Changeset: cc81b9c09bbb Author: kvn Date: 2011-11-28 15:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/cc81b9c09bbb 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: 97825a4f7369 Author: iveresov Date: 2011-11-30 17:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/97825a4f7369 7116795: Tiered: enable by default for server Summary: Enable tiered compilation on server VM by default Reviewed-by: kvn, never ! make/jprt.properties ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: f745b2be3737 Author: kvn Date: 2011-12-02 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/f745b2be3737 7117282: assert(base == NULL || t_adr->isa_rawptr() || !phase->type(base) Summary: Delay memory node transformation until the memory is processed. Reviewed-by: iveresov, never ! src/share/vm/opto/memnode.cpp Changeset: 81f7362f7bed Author: kvn Date: 2011-12-08 10:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/81f7362f7bed Merge ! make/jprt.properties ! src/share/vm/runtime/globals.hpp Changeset: e9b91fd07263 Author: jmasa Date: 2011-12-09 06:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e9b91fd07263 Merge From john.cuthbertson at oracle.com Fri Dec 9 19:30:37 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 09 Dec 2011 11:30:37 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EDFA96C.9020007@oracle.com> References: <4EDFA96C.9020007@oracle.com> Message-ID: <4EE261DD.9020806@oracle.com> Hi Everyone, I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ Thanks, JohnC On 12/7/2011 9:59 AM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where we expect > monotonicity with calls os::javaTimeNanos(), converting the result to > milliseconds. os::javaTimeNanos(), at least on some configurations, > does guarantee monotonicity and so is a better alternative. The > changes in the os_<*> files are to make use of the named conversion > constants I added/moved to globalDefinitions.hpp - we seemed to have > multiple names for the same two constants. > > Testing: GC test suite on solaris and Linux, NSK tests on solaris, and > jprt. > > Thanks, > > JohnC From tony.printezis at oracle.com Fri Dec 9 19:32:51 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 09 Dec 2011 14:32:51 -0500 Subject: G1 discovers same garbage again? In-Reply-To: <4EDD1924.2030803@java4.info> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> Message-ID: <4EE26263.3040307@oracle.com> Florian, Inline. On 12/05/2011 02:19 PM, Florian Binder wrote: >> I assume you know when the data will be dropped and reinitialized, >> right? Can you do a Full GC (with System.gc()) after you re-initialize >> the heap. This typically helps a lot with CMS. > Yes, this is exactly what we are trying at this time ;-) > Either this Full-GC pauses are very long (60-300 seconds) they are much > shorter than after a CMS-failure (when they take sometimes more than > 4000 seconds ;-)) and we can define when they occure. Maybe this will be > our solution. It depends on the result of my g1-experience ;-) OK. :-) We'd better make it really good. :-) >>> This was the cause I am experiencing >>> with g1 in general. I am not sure if we had fragmentation on this one. >> G1 should not have fragmentation issues at the small / medium size >> object level. It might only if you allocate a lot of very large arrays >> (0.5MB+). > Ah ok, this is good to know. So if we have a lot of 10 MB byte arrays > g1-might have problems with them? Let me be a bit clearer: if you just allocate such large objects once, then it won't be a problem. If you allocate them and drop them at a rapid rate it might be a problem > May it helpt to increase the > G1HeapRegionSize to 20MB? Or is this to large and it would be better to > break them down into smaller arrays (0.5mb)? First, the heap region size should be a power of 2 (so if you try to set it to 20MB, G1 will actually use 32MB). Also, the heap region size is automatically calculated for a particular heap size. If you enable -XX:+PrintHeapAtGC it should tell you how large it is for your particular app: garbage-first heap total 6144K, used 3185K [0x6e800000, 0x6ee00000, 0xae800000) region size 1024K, 2 young (2048K), 1 survivors (1024K) Generally, avoiding to allocate objects that are larger than the heap region size is good practice as it will eliminate fragmentation issues. However, please also remember that each object has a header too! So if you allocate, say, a byte array of exactly 1MB entries, the object's size is going to be 1MB + the array header size (12 bytes in the 32-bit JVM). So you want to size arrays a bit smaller than the region size (not too small though, as you'll probably waste the rest of the region). >> >> Here's a quick description of how the Eden and the other spaces in G1 >> work. Hopefully, this will help you understand this behavior a bit >> better. >> >> When new objects are allocated by the application the are placed in >> the Eden which is a set of regions. When the Eden is full we initiate >> a collection. During that collection we physically move all the >> surviving objects from the Eden regions to another set of regions >> called the Survivors. At the end of a collection the Eden regions have >> no more live objects (we copied them somewhere else) so we can reclaim >> them (which is why the Eden is empty after a GC). After a GC new >> objects are allocated into Eden regions (either new ones, or ones >> which were reclaimed before; it doesn't matter which) which make the >> Eden grow again. And when it's full it's again collected, etc. > So, after a (young) gc the eden space should increase only by the new > allocated objects? Yes. > Or is it possible that new non empty regions are used > for the eden space, too? Any free region can be used for the eden. Either once that were reclaimed before or new ones. > As you can see at http://java4.info/g1/eden_all.png > from 13:20 until 18:00 the eden space is constantly growing (with a few > gcs) Did you point me to the right graph? The timeline seems to be 18:06 - 18:35. > just by the new objects (allocated by me). But after 18:00 There > are frequent jumps which are much more than I would ever allocate. So > what is causing them? > > First of all I thought g1 is taking some old-gen-regions to the gc > because it has enough time to do this, We generally only do that for a few GCs after each marking phase when we recalculate the liveness information in the old regions and we know which ones are best to collect. > but then I saw that in this cause > "(partial)" will be append in the out-log: > http://java4.info/g1/out_err.log.gz > Furthermore this should not increase the total-heap-space: > http://java4.info/g1/all.png > > Or is it possible that within a young gc only a few of the young regions > are collected and reclaimed? Nope. We definitely collect all the young regions at every young GC. Tony > Thanks, > Flo > >> Does this explain better the behavior you see? >> >>> After I have written the last email, I have seen that it has calm itself >>> after a few hours. But it is nevertheless very curious and produces a >>> lot of unnecessary pauses. >> They are not really unnecessary. Each pause reclaims a lot of >> short-lived objects. >> >> Tony >> >>> Flo >>> >>>> Tony >>>> >>>>> I >>>>> assume that it runs during a collection in the old garbage and >>>>> collects >>>>> it again. Is this possible? Or is there an overflow since eden space >>>>> uses more than 3.5 gb? >>>>> >>>>> Thanks and regards, >>>>> Flo >>>>> >>>>> Some useful information: >>>>> $ java -version >>>>> java version "1.6.0_29" >>>>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode) >>>>> >>>>> Startup Parameters: >>>>> -Xms20g -Xmx20g >>>>> -verbose:gc \ >>>>> -XX:+UnlockExperimentalVMOptions \ >>>>> -XX:+UseG1GC \ >>>>> -XX:+PrintGCDetails \ >>>>> -XX:+PrintGCDateStamps \ >>>>> -XX:+UseLargePages \ >>>>> -XX:+PrintFlagsFinal \ >>>>> -XX:-TraceClassUnloading \ >>>>> >>>>> $ cat /proc/meminfo | grep Huge >>>>> HugePages_Total: 11264 >>>>> HugePages_Free: 1015 >>>>> HugePages_Rsvd: 32 >>>>> Hugepagesize: 2048 kB >>>>> >>>>> A few screen-shots of the jconsole memory-view: >>>>> http://java4.info/g1/1h.png >>>>> http://java4.info/g1/all.png >>>>> http://java4.info/g1/eden_1h.png >>>>> http://java4.info/g1/eden_all.png >>>>> http://java4.info/g1/oldgen_all.png >>>>> >>>>> The sysout end syserr logfile with the gc logging and PrintFinalFlags: >>>>> http://java4.info/g1/out_err.log.gz >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at oracle.com Fri Dec 9 20:49:35 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 09 Dec 2011 12:49:35 -0800 Subject: Request for review (s) - 7119584 In-Reply-To: References: <4EE241F1.7090300@oracle.com> Message-ID: <4EE2745F.2060005@oracle.com> Vitaly, This is what happens. 1) create the barrier task 2) enqueue the barrier task to a list of tasks 3) make the tasks visible to the GC workers by added them to queue from which workers take tasks At 3) a GC worker can take and execute the barrier task. I want all the fields in the barrier task to be in main memory and thus visible to the GC worker task when it starts to execute the barrier task. So by the time 3) happens (tasks are visible in the queue for the GC workers to take) the stores at 1) to be visible so that when the GC worker reads the barrier task, it is getting all the right values. I think that's what the storestore does for me. Do I need something stronger? And thank you for thinking about this for me. Jon On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: > Hi Jon, > > Are you sure your comment for the OrderAccess::storestore() matches this > barrier? Your comment mentions that you want global visibility but does > this need immediate visibility or you just want order for when it does > become visible? StoreStore is just the latter, but maybe that's what you > meant. > > Regards, > > Vitaly > On Dec 9, 2011 12:15 PM, "Jon Masamitsu" wrote: > >> 7119584: UseParallelGC barrier task can be overwritten. >> >> Just a few changed lines. The comments around the changes >> give an explanation in context so are a better explanation than >> I can summarize here. >> >> http://cr.openjdk.java.net/~**jmasa/7119584/webrev.00/ >> >> Thanks. >> From vitalyd at gmail.com Fri Dec 9 21:01:44 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 9 Dec 2011 16:01:44 -0500 Subject: Request for review (s) - 7119584 In-Reply-To: <4EE2745F.2060005@oracle.com> References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> Message-ID: Ok sounds like storestore is sufficient given your explanation - you don't care whether the task is immediately visible to gc threads after it's enqueued, you just want to make sure that once it is visible (might be delayed due to store bufferring) that all fields are consistent. I'm obviously not on the hotspot dev team (just a curious bystander :)) but perhaps you can change the code comment to indicate that you want ordered writes but not necessarily immediately global visibility. Thanks for the explanation, Vitaly On Dec 9, 2011 3:49 PM, "Jon Masamitsu" wrote: > Vitaly, > > This is what happens. > > 1) create the barrier task > 2) enqueue the barrier task to a list of tasks > 3) make the tasks visible to the GC workers by added them to > queue from which workers take tasks > > At 3) a GC worker can take and execute the barrier task. > I want all the fields in the barrier task to be in main memory > and thus visible to the GC worker task when it starts to > execute the barrier task. So by the time 3) happens > (tasks are visible in the queue for the GC workers to > take) the stores at 1) to be visible so that when the GC > worker reads the barrier task, it is getting all the right > values. > > I think that's what the storestore does for me. Do I > need something stronger? And thank you for thinking > about this for me. > > Jon > > On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: > >> Hi Jon, >> >> Are you sure your comment for the OrderAccess::storestore() matches this >> barrier? Your comment mentions that you want global visibility but does >> this need immediate visibility or you just want order for when it does >> become visible? StoreStore is just the latter, but maybe that's what you >> meant. >> >> Regards, >> >> Vitaly >> On Dec 9, 2011 12:15 PM, "Jon Masamitsu"> >> wrote: >> >> 7119584: UseParallelGC barrier task can be overwritten. >>> >>> Just a few changed lines. The comments around the changes >>> give an explanation in context so are a better explanation than >>> I can summarize here. >>> >>> http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/ >>> >>> > >>> >>> Thanks. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Fri Dec 9 21:19:14 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 09 Dec 2011 13:19:14 -0800 Subject: Request for review (s) - 7119584 In-Reply-To: References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> Message-ID: <4EE27B52.1040401@oracle.com> On 12/9/2011 1:01 PM, Vitaly Davidovich wrote: > Ok sounds like storestore is sufficient given your explanation - you don't > care whether the task is immediately visible to gc threads after it's > enqueued, you just want to make sure that once it is visible (might be > delayed due to store bufferring) that all fields are consistent. Yes, that's correct. > I'm obviously not on the hotspot dev team (just a curious bystander :)) but > perhaps you can change the code comment to indicate that you want ordered > writes but not necessarily immediately global visibility. Will do. Thanks again. Jon > Thanks for the explanation, > > Vitaly > On Dec 9, 2011 3:49 PM, "Jon Masamitsu" wrote: > >> Vitaly, >> >> This is what happens. >> >> 1) create the barrier task >> 2) enqueue the barrier task to a list of tasks >> 3) make the tasks visible to the GC workers by added them to >> queue from which workers take tasks >> >> At 3) a GC worker can take and execute the barrier task. >> I want all the fields in the barrier task to be in main memory >> and thus visible to the GC worker task when it starts to >> execute the barrier task. So by the time 3) happens >> (tasks are visible in the queue for the GC workers to >> take) the stores at 1) to be visible so that when the GC >> worker reads the barrier task, it is getting all the right >> values. >> >> I think that's what the storestore does for me. Do I >> need something stronger? And thank you for thinking >> about this for me. >> >> Jon >> >> On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: >> >>> Hi Jon, >>> >>> Are you sure your comment for the OrderAccess::storestore() matches this >>> barrier? Your comment mentions that you want global visibility but does >>> this need immediate visibility or you just want order for when it does >>> become visible? StoreStore is just the latter, but maybe that's what you >>> meant. >>> >>> Regards, >>> >>> Vitaly >>> On Dec 9, 2011 12:15 PM, "Jon Masamitsu"> >>> wrote: >>> >>> 7119584: UseParallelGC barrier task can be overwritten. >>>> Just a few changed lines. The comments around the changes >>>> give an explanation in context so are a better explanation than >>>> I can summarize here. >>>> >>>> http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/ >>>> >>>> Thanks. >>>> >>>> From ysr1729 at gmail.com Sat Dec 10 00:34:09 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 9 Dec 2011 16:34:09 -0800 Subject: G1 discovers same garbage again? In-Reply-To: <4EE26263.3040307@oracle.com> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> Message-ID: A couple of things caught my eye.... On 12/05/2011 02:19 PM, Florian Binder wrote: > >> I assume you know when the data will be dropped and reinitialized, > >> right? Can you do a Full GC (with System.gc()) after you re-initialize > >> the heap. This typically helps a lot with CMS. > > Yes, this is exactly what we are trying at this time ;-) > > Either this Full-GC pauses are very long (60-300 seconds) they are much > > shorter than after a CMS-failure (when they take sometimes more than > > 4000 seconds ;-)) and we can define when they occure. > A full GC that takes an hour is definitely a bug. Have you logged that bug? Or at least share the GC log? What's the version of the JDK that this behaviour was seen with? ... > > Furthermore this should not increase the total-heap-space: > > http://java4.info/g1/all.png > Remember that jconsole asynchronously samples the heap, whose size is read "with possible glitches". Rather, you should probably rely on the GC log in order to assess the heap size after each GC event, rather than the asynchronous samples from jconsole. I myself have not had the chance to look at yr GC logs to see what that indicated wrt the size of Eden and of the Heap. -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From java at java4.info Sat Dec 10 02:08:13 2011 From: java at java4.info (Florian Binder) Date: Sat, 10 Dec 2011 03:08:13 +0100 Subject: G1 discovers same garbage again? In-Reply-To: References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> Message-ID: <4EE2BF0D.1050005@java4.info> In the gc log it seems that there is always running the same garbage collection. For example: $ zcat out_err.log.gz | grep 20480M | tail 2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M), 0.1370060 secs] [ 16394M->12914M(20480M)] [ 16394M->12914M(20480M)] 2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M), 0.1387230 secs] [ 16394M->12914M(20480M)] [ 16394M->12914M(20480M)] [ 16394M->12914M(20480M)] 2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M), 0.1344170 secs] [ 16394M->12914M(20480M)] [ 16394M->12914M(20480M)] Therefore I assume this might be a bug ;-) You can download the whole log at: http://java4.info/g1/out_err.log.gz I don't think that we still have the logs of that very long gc, but I will have a look for it at monday. Furthermore I do not think that we have logged there much details of the gc. But I know that this happend on a very special server, which contains more the 30gb of references (yes, just references to other objects). If we run it with CompressedOops we reduce the memory useage to nearly 50%. Flo Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna: > > > A couple of things caught my eye.... > > On 12/05/2011 02:19 PM, Florian Binder wrote: > >> I assume you know when the data will be dropped and reinitialized, > >> right? Can you do a Full GC (with System.gc()) after you > re-initialize > >> the heap. This typically helps a lot with CMS. > > Yes, this is exactly what we are trying at this time ;-) > > Either this Full-GC pauses are very long (60-300 seconds) they > are much > > shorter than after a CMS-failure (when they take sometimes more than > > 4000 seconds ;-)) and we can define when they occure. > > > A full GC that takes an hour is definitely a bug. Have you logged that > bug? > Or at least share the GC log? What's the version of the JDK that this > behaviour > was seen with? > > ... > > > Furthermore this should not increase the total-heap-space: > > http://java4.info/g1/all.png > > > Remember that jconsole asynchronously samples the heap, whose size is > read "with possible glitches". Rather, you should probably rely on the > GC log in order to assess > the heap size after each GC event, rather than the asynchronous > samples from > jconsole. I myself have not had the chance to look at yr GC logs to see > what that indicated wrt the size of Eden and of the Heap. > > -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From igor.veresov at oracle.com Sat Dec 10 04:43:00 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 9 Dec 2011 20:43:00 -0800 Subject: Request for review (s) - 7119584 In-Reply-To: <4EE27B52.1040401@oracle.com> References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> <4EE27B52.1040401@oracle.com> Message-ID: <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> Jon, Since you are describing a dependency between stores and subsequent loads from other threads, shouldn't it be a "storeload" barrier? igor On Friday, December 9, 2011 at 1:19 PM, Jon Masamitsu wrote: > > > On 12/9/2011 1:01 PM, Vitaly Davidovich wrote: > > Ok sounds like storestore is sufficient given your explanation - you don't > > care whether the task is immediately visible to gc threads after it's > > enqueued, you just want to make sure that once it is visible (might be > > delayed due to store bufferring) that all fields are consistent. > > > Yes, that's correct. > > > I'm obviously not on the hotspot dev team (just a curious bystander :)) but > > perhaps you can change the code comment to indicate that you want ordered > > writes but not necessarily immediately global visibility. > > > > Will do. Thanks again. > > Jon > > Thanks for the explanation, > > > > Vitaly > > On Dec 9, 2011 3:49 PM, "Jon Masamitsu" wrote: > > > > > Vitaly, > > > > > > This is what happens. > > > > > > 1) create the barrier task > > > 2) enqueue the barrier task to a list of tasks > > > 3) make the tasks visible to the GC workers by added them to > > > queue from which workers take tasks > > > > > > At 3) a GC worker can take and execute the barrier task. > > > I want all the fields in the barrier task to be in main memory > > > and thus visible to the GC worker task when it starts to > > > execute the barrier task. So by the time 3) happens > > > (tasks are visible in the queue for the GC workers to > > > take) the stores at 1) to be visible so that when the GC > > > worker reads the barrier task, it is getting all the right > > > values. > > > > > > I think that's what the storestore does for me. Do I > > > need something stronger? And thank you for thinking > > > about this for me. > > > > > > Jon > > > > > > On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: > > > > > > > Hi Jon, > > > > > > > > Are you sure your comment for the OrderAccess::storestore() matches this > > > > barrier? Your comment mentions that you want global visibility but does > > > > this need immediate visibility or you just want order for when it does > > > > become visible? StoreStore is just the latter, but maybe that's what you > > > > meant. > > > > > > > > Regards, > > > > > > > > Vitaly > > > > On Dec 9, 2011 12:15 PM, "Jon Masamitsu"> > > > > wrote: > > > > > > > > 7119584: UseParallelGC barrier task can be overwritten. > > > > > Just a few changed lines. The comments around the changes > > > > > give an explanation in context so are a better explanation than > > > > > I can summarize here. > > > > > > > > > > http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/ > > > > > > > > > > Thanks. > > > > > > > > > > From vitalyd at gmail.com Sat Dec 10 04:58:03 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 9 Dec 2011 23:58:03 -0500 Subject: Request for review (s) - 7119584 In-Reply-To: <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> <4EE27B52.1040401@oracle.com> <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> Message-ID: StoreLoad is only needed to prevent a load moving ahead of a prior write in the *writing* thread - from Jon's description he only needs to ensure that the gc thread reads a consistent(fully initialized) object from the other thread (i.e. object was fully initialized before it's written to the queue rather than being written to the queue but having initializing writes happen after that). On Dec 9, 2011 11:43 PM, "Igor Veresov" wrote: > Jon, > > Since you are describing a dependency between stores and subsequent loads > from other threads, shouldn't it be a "storeload" barrier? > > igor > > > On Friday, December 9, 2011 at 1:19 PM, Jon Masamitsu wrote: > > > > > > > On 12/9/2011 1:01 PM, Vitaly Davidovich wrote: > > > Ok sounds like storestore is sufficient given your explanation - you > don't > > > care whether the task is immediately visible to gc threads after it's > > > enqueued, you just want to make sure that once it is visible (might be > > > delayed due to store bufferring) that all fields are consistent. > > > > > > Yes, that's correct. > > > > > I'm obviously not on the hotspot dev team (just a curious bystander > :)) but > > > perhaps you can change the code comment to indicate that you want > ordered > > > writes but not necessarily immediately global visibility. > > > > > > > > Will do. Thanks again. > > > > Jon > > > Thanks for the explanation, > > > > > > Vitaly > > > On Dec 9, 2011 3:49 PM, "Jon Masamitsu" jon.masamitsu at oracle.com)> wrote: > > > > > > > Vitaly, > > > > > > > > This is what happens. > > > > > > > > 1) create the barrier task > > > > 2) enqueue the barrier task to a list of tasks > > > > 3) make the tasks visible to the GC workers by added them to > > > > queue from which workers take tasks > > > > > > > > At 3) a GC worker can take and execute the barrier task. > > > > I want all the fields in the barrier task to be in main memory > > > > and thus visible to the GC worker task when it starts to > > > > execute the barrier task. So by the time 3) happens > > > > (tasks are visible in the queue for the GC workers to > > > > take) the stores at 1) to be visible so that when the GC > > > > worker reads the barrier task, it is getting all the right > > > > values. > > > > > > > > I think that's what the storestore does for me. Do I > > > > need something stronger? And thank you for thinking > > > > about this for me. > > > > > > > > Jon > > > > > > > > On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: > > > > > > > > > Hi Jon, > > > > > > > > > > Are you sure your comment for the OrderAccess::storestore() > matches this > > > > > barrier? Your comment mentions that you want global visibility but > does > > > > > this need immediate visibility or you just want order for when it > does > > > > > become visible? StoreStore is just the latter, but maybe that's > what you > > > > > meant. > > > > > > > > > > Regards, > > > > > > > > > > Vitaly > > > > > On Dec 9, 2011 12:15 PM, "Jon Masamitsu" oracle.com> > > > > > wrote: > > > > > > > > > > 7119584: UseParallelGC barrier task can be overwritten. > > > > > > Just a few changed lines. The comments around the changes > > > > > > give an explanation in context so are a better explanation than > > > > > > I can summarize here. > > > > > > > > > > > > http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/< > http://cr.openjdk.java.net/~**jmasa/7119584/webrev.00/> > > > > > > http://cr.openjdk.java.net/~jmasa/7119584/webrev.00/> > > > > > > Thanks. > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Sat Dec 10 05:30:48 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 09 Dec 2011 21:30:48 -0800 Subject: Request for review (s) - 7119584 In-Reply-To: <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> <4EE27B52.1040401@oracle.com> <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> Message-ID: <4EE2EE88.4090800@oracle.com> Igor, I'm glad to describe this again. The GC task manager creates the barrier task X. The GC worker is waiting to take tasks off a queue L. As soon as the task manager writes X to L, the worker can take X and start executing it. So I want the store of X to L to happen after the initializing stores to X have happened. That way the worker won't see X on L before it is safe to start executing X. Sound right? Jon On 12/9/2011 8:43 PM, Igor Veresov wrote: > Jon, > > Since you are describing a dependency between stores and subsequent loads from other threads, shouldn't it be a "storeload" barrier? > > igor > > > On Friday, December 9, 2011 at 1:19 PM, Jon Masamitsu wrote: > >> >> On 12/9/2011 1:01 PM, Vitaly Davidovich wrote: >>> Ok sounds like storestore is sufficient given your explanation - you don't >>> care whether the task is immediately visible to gc threads after it's >>> enqueued, you just want to make sure that once it is visible (might be >>> delayed due to store bufferring) that all fields are consistent. >> >> Yes, that's correct. >> >>> I'm obviously not on the hotspot dev team (just a curious bystander :)) but >>> perhaps you can change the code comment to indicate that you want ordered >>> writes but not necessarily immediately global visibility. >> >> >> Will do. Thanks again. >> >> Jon >>> Thanks for the explanation, >>> >>> Vitaly >>> On Dec 9, 2011 3:49 PM, "Jon Masamitsu" wrote: >>> >>>> Vitaly, >>>> >>>> This is what happens. >>>> >>>> 1) create the barrier task >>>> 2) enqueue the barrier task to a list of tasks >>>> 3) make the tasks visible to the GC workers by added them to >>>> queue from which workers take tasks >>>> >>>> At 3) a GC worker can take and execute the barrier task. >>>> I want all the fields in the barrier task to be in main memory >>>> and thus visible to the GC worker task when it starts to >>>> execute the barrier task. So by the time 3) happens >>>> (tasks are visible in the queue for the GC workers to >>>> take) the stores at 1) to be visible so that when the GC >>>> worker reads the barrier task, it is getting all the right >>>> values. >>>> >>>> I think that's what the storestore does for me. Do I >>>> need something stronger? And thank you for thinking >>>> about this for me. >>>> >>>> Jon >>>> >>>> On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: >>>> >>>>> Hi Jon, >>>>> >>>>> Are you sure your comment for the OrderAccess::storestore() matches this >>>>> barrier? Your comment mentions that you want global visibility but does >>>>> this need immediate visibility or you just want order for when it does >>>>> become visible? StoreStore is just the latter, but maybe that's what you >>>>> meant. >>>>> >>>>> Regards, >>>>> >>>>> Vitaly >>>>> On Dec 9, 2011 12:15 PM, "Jon Masamitsu"> >>>>> wrote: >>>>> >>>>> 7119584: UseParallelGC barrier task can be overwritten. >>>>>> Just a few changed lines. The comments around the changes >>>>>> give an explanation in context so are a better explanation than >>>>>> I can summarize here. >>>>>> >>>>>> http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/ >>>>>> >>>>>> Thanks. > > From igor.veresov at oracle.com Sat Dec 10 05:58:46 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 9 Dec 2011 21:58:46 -0800 Subject: Request for review (s) - 7119584 In-Reply-To: <4EE2EE88.4090800@oracle.com> References: <4EE241F1.7090300@oracle.com> <4EE2745F.2060005@oracle.com> <4EE27B52.1040401@oracle.com> <9A3B4B4AC60E483E9C26F0CBD9BCE6DA@oracle.com> <4EE2EE88.4090800@oracle.com> Message-ID: <6104D76DD3824E0E9E712B5B0A469682@oracle.com> Yes, this sounds right. Looks good. Thanks! igor On Friday, December 9, 2011 at 9:30 PM, Jon Masamitsu wrote: > Igor, > > I'm glad to describe this again. > > The GC task manager creates the barrier task X. The GC worker > is waiting to take tasks off a queue L. As soon as the task manager > writes X to L, the worker can take X and start executing it. So I want > the store of X to L to happen after the initializing stores to X > have happened. That way the worker won't see X on L before > it is safe to start executing X. Sound right? > > Jon > > On 12/9/2011 8:43 PM, Igor Veresov wrote: > > Jon, > > > > Since you are describing a dependency between stores and subsequent loads from other threads, shouldn't it be a "storeload" barrier? > > > > igor > > > > > > On Friday, December 9, 2011 at 1:19 PM, Jon Masamitsu wrote: > > > > > > > > On 12/9/2011 1:01 PM, Vitaly Davidovich wrote: > > > > Ok sounds like storestore is sufficient given your explanation - you don't > > > > care whether the task is immediately visible to gc threads after it's > > > > enqueued, you just want to make sure that once it is visible (might be > > > > delayed due to store bufferring) that all fields are consistent. > > > > > > > > > > > > Yes, that's correct. > > > > > > > I'm obviously not on the hotspot dev team (just a curious bystander :)) but > > > > perhaps you can change the code comment to indicate that you want ordered > > > > writes but not necessarily immediately global visibility. > > > > > > > > > > > > > > > Will do. Thanks again. > > > > > > Jon > > > > Thanks for the explanation, > > > > > > > > Vitaly > > > > On Dec 9, 2011 3:49 PM, "Jon Masamitsu" wrote: > > > > > > > > > Vitaly, > > > > > > > > > > This is what happens. > > > > > > > > > > 1) create the barrier task > > > > > 2) enqueue the barrier task to a list of tasks > > > > > 3) make the tasks visible to the GC workers by added them to > > > > > queue from which workers take tasks > > > > > > > > > > At 3) a GC worker can take and execute the barrier task. > > > > > I want all the fields in the barrier task to be in main memory > > > > > and thus visible to the GC worker task when it starts to > > > > > execute the barrier task. So by the time 3) happens > > > > > (tasks are visible in the queue for the GC workers to > > > > > take) the stores at 1) to be visible so that when the GC > > > > > worker reads the barrier task, it is getting all the right > > > > > values. > > > > > > > > > > I think that's what the storestore does for me. Do I > > > > > need something stronger? And thank you for thinking > > > > > about this for me. > > > > > > > > > > Jon > > > > > > > > > > On 12/9/2011 9:48 AM, Vitaly Davidovich wrote: > > > > > > > > > > > Hi Jon, > > > > > > > > > > > > Are you sure your comment for the OrderAccess::storestore() matches this > > > > > > barrier? Your comment mentions that you want global visibility but does > > > > > > this need immediate visibility or you just want order for when it does > > > > > > become visible? StoreStore is just the latter, but maybe that's what you > > > > > > meant. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Vitaly > > > > > > On Dec 9, 2011 12:15 PM, "Jon Masamitsu"> > > > > > > wrote: > > > > > > > > > > > > 7119584: UseParallelGC barrier task can be overwritten. > > > > > > > Just a few changed lines. The comments around the changes > > > > > > > give an explanation in context so are a better explanation than > > > > > > > I can summarize here. > > > > > > > > > > > > > > http://cr.openjdk.java.net/~****jmasa/7119584/webrev.00/ > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > From kirk at kodewerk.com Sat Dec 10 07:55:53 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Sat, 10 Dec 2011 08:55:53 +0100 Subject: RFR (XXXS): 7068215: G1: Print reference processing time during remark In-Reply-To: <4E2DD3AA.2000807@oracle.com> References: <4E27538B.1060203@oracle.com> <4E275A43.1040604@oracle.com> <4E275CCE.20501@oracle.com> <4E2760A6.60204@oracle.com> <4E2DB146.3040703@oracle.com> <4E2DD31B.40400@oracle.com> <4E2DD3AA.2000807@oracle.com> Message-ID: <400B5B84-36E0-4771-A63C-1D68B72E5BBA@kodewerk.com> I vote for making the output more sensible... I don't care how you break it... I'll pay the short term penalty if it makes things better in the long run.... On Jul 25, 2011, at 10:35 PM, Tony Printezis wrote: > John, > > FWIW: AFAIK there are no other GC pauses that generate -start / -end output. Currently, all the output generated during a pause is included in the [GC ... ] line for the pause. Not 100% sure what the best approach here is. Stay consistent with previous output or make the output more sensible? > > Tony > > John Cuthbertson wrote: >> Hi All, >> >> The main reason was that I wanted to use the TraceTime class (as other GCs and other parts of G1s). As Ramki, pointed out, however, this also ends up including the time for cleaning up the symbol and string tables unless an inner scope is used. Igor also makes a good point in that with his proposed format all you need to is grep for "[GC X-end" to get the times of the event(s) X that you are interested in. >> >> With that in mind a new webrev for Igor's format is at http://cr.openjdk.java.net/~johnc/7068215/webrev.1/ >> >> With these changes, the output looks like: >> >> PrintGC: >> 9.404: [GC concurrent-mark-start] >> 9.470: [GC concurrent-mark-end, 0.0666473 sec] >> 9.471: [GC remark-start] >> 9.480: [GC remark-end, 0.0089202 secs] >> 9.480: [GC concurrent-count-start] >> 9.489: [GC concurrent-count-end, 0.0090631] >> 9.489: [GC cleanup-start] >> 9.490: [GC cleanup-end 29M->26M(64M), 0.0011680 secs] >> 9.491: [GC concurrent-cleanup-start] >> 9.491: [GC concurrent-cleanup-end, 0.0001412] >> >> Remark and cleanup now have start and end markers; the heap size transition for the cleanup is on the end marker. >> >> PrintGC + PrintGCDetails: >> 8.133: [GC remark-start] >> 8.148: [GC remark-end, 0.0151136 secs] >> [Times: user=0.04 sys=0.00, real=0.02 secs] >> 8.148: [GC concurrent-count-start] >> 8.156: [GC concurrent-count-end, 0.0076754] >> 8.198: [GC cleanup-start] >> 8.199: [GC cleanup-end 33M->31M(64M), 0.0009878 secs] >> [Times: user=0.01 sys=0.00, real=0.00 secs] >> 8.199: [GC concurrent-cleanup-start] >> 8.199: [GC concurrent-cleanup-end, 0.0001300] >> >> The only addition here is the printing of the CPU times for remark and cleanup (as it was before). >> >> PrintGC + PrintReferenceGC: >> 8.070: [GC concurrent-mark-start] >> 8.117: [GC concurrent-mark-end, 0.0460792 sec] >> 8.219: [GC remark-start] >> 8.229: [GC ref-processing-start] >> 8.230: [GC ref-processing-end, 0.0019488 secs] >> 8.235: [GC remark-end, 0.0158816 secs] >> 8.235: [GC concurrent-count-start] >> 8.257: [GC concurrent-count-end, 0.0220724] >> 8.306: [GC cleanup-start] >> 8.307: [GC cleanup-end 28M->25M(64M), 0.0007636 secs] >> 8.307: [GC concurrent-cleanup-start] >> 8.319: [GC concurrent-cleanup-end, 0.0120578] >> >> With the addition of PrintReferenceGC we get the start and end markers of the ref-processing phase. >> >> PrintGC + PrintGCDetails + PrintReferenceGC; >> >> 8.008: [GC remark-start] >> 8.014: [GC ref-processing-start] >> 8.014: [SoftReference, 0 refs, 0.0000186 secs] >> 8.014: [WeakReference, 383 refs, 0.0002477 secs] >> 8.014: [FinalReference, 783 refs, 0.0012285 secs] >> 8.016: [PhantomReference, 156 refs, 0.0001268 secs] >> 8.016: [JNI Weak Reference, 86 refs, 0.0000083 secs] >> 8.016: [GC ref-processing-end, 0.0022400 secs] >> 8.021: [GC remark-end, 0.0132204 secs] >> [Times: user=0.03 sys=0.00, real=0.01 secs] >> 8.021: [GC concurrent-count-start] >> 8.030: [GC concurrent-count-end, 0.0088910] >> 8.030: [GC cleanup-start] >> 8.031: [GC cleanup-end 29M->26M(64M), 0.0008376 secs] >> [Times: user=0.00 sys=0.00, real=0.00 secs] >> 8.031: [GC concurrent-cleanup-start] >> 8.031: [GC concurrent-cleanup-end, 0.0001300] >> >> The output of the other collectors are unchanged. >> >> Thanks, >> >> JohnC >> >> On 07/25/11 11:09, Tony Printezis wrote: >>> Igor, >>> >>> (I'm just back from vacation, not sure whether you guys discussed this further...) >>> >>> I'd guess that John took the approach he did because this is what the other GCs also do (and also because ref processing is part of the remark work too). The output below does miss the latter point I think. >>> >>> Tony >>> >>> Igor Veresov wrote: >>>> Shouldn't be the log structured more like? >>>> #ts: [GC remark-start] >>>> #ts: [GC ref-processing-start] >>>> #ts: [GC *References, #t sec] >>>> #ts: [GC ref-processing-end, #t sec] >>>> #ts: [GC remark-end, #t sec] >>>> >>>> Otherwise the parser would have to support recursive expressions and I think it's also easier to parse for humans if it's linear. I'm not insisting though. >>>> >>>> igor >>>> >>>> On 7/20/11 3:55 PM, John Cuthbertson wrote: >>>>> Hi Ramki, >>>>> >>>>> Thanks for looking. The time does include the cleaning of the string and >>>>> symbol tables. I'll reduce the scope of the timer and change output. The >>>>> reason why I chose that output was in case PrintReferenceGC was on by >>>>> itself. So changing the output will change what flags are used to set >>>>> verbose to something like "(PrintGC || PrintGCDetails) && PrintReferenceGC. >>>>> >>>>> JohnC >>>>> >>>>> On 07/20/11 15:44, Y. S. Ramakrishna wrote: >>>>>> John -- isn't the new timer capturing more than just reference >>>>>> processing? It's including string table and symbol table >>>>>> walks as well. I'd much rather you dropped the redundant "GC remark" >>>>>> (after all it's already there in the outer print scope) >>>>>> and limited the timer to a scope that exactly captures >>>>>> reference processing and enqueueing (i.e. not the string >>>>>> and symbol table walks). That extra probably explains the >>>>>> missing ~9 ms time in your last display below? >>>>>> >>>>>> -- ramki >>>>>> >>>>>> On 07/20/11 15:15, John Cuthbertson wrote: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> Can I have a couple of volunteers review this small change? The >>>>>>> webrev can be found at: >>>>>>> http://cr.openjdk.java.net/~johnc/7068215/webrev.0/ >>>>>>> >>>>>>> Background: >>>>>>> During some recent performance runs of G1, some extremely long remark >>>>>>> pauses (espccially the first) were observed and the CPU times >>>>>>> indicated that the remarks were pretty serial. There is speculation >>>>>>> that these long remarks are caused be the reference process, which is >>>>>>> serial by default. This CR is to add a timer to the reference >>>>>>> processing to confirm our suspicions. With the new timer, the output >>>>>>> format of the remark has changed a little (new output is in *bold*): >>>>>>> >>>>>>> _PrintGC (only)_ >>>>>>> 13.061: [GC pause (young) (initial-mark) 19M->9983K(32M), 0.0108699 >>>>>>> secs] >>>>>>> 13.072: [GC concurrent-mark-start] >>>>>>> 13.120: [GC concurrent-mark-end, 0.0484379 sec] >>>>>>> 13.122: [GC remark, 0.0265762 secs] >>>>>>> 13.154: [GC concurrent-count-start] >>>>>>> 13.160: [GC concurrent-count-end, 0.0058944] >>>>>>> 13.160: [GC cleanup 10M->10M(32M), 0.0004928 secs] >>>>>>> >>>>>>> No difference from before. >>>>>>> >>>>>>> _PrintGC + PrintReferenceGC_ >>>>>>> 14.537: [GC pause (young) (initial-mark) 19M->10146K(32M), 0.0110351 >>>>>>> secs] >>>>>>> 14.548: [GC concurrent-mark-start] >>>>>>> 14.596: [GC concurrent-mark-end, 0.0474622 sec] >>>>>>> 14.596: [GC remark *14.596: [GC remark (ref processing), 0.0274587 >>>>>>> secs]*, 0.0277831 secs] >>>>>>> 14.624: [GC concurrent-count-start] >>>>>>> 14.630: [GC concurrent-count-end, 0.0059460] >>>>>>> 14.630: [GC cleanup 10M->10M(32M), 0.0004955 secs] >>>>>>> >>>>>>> _PrintGCDetails (only)_ >>>>>>> 21.336: [GC concurrent-mark-end, 0.0394013 sec] >>>>>>> 21.336: [GC remark *21.347: [GC remark (ref processing), 0.0262900 >>>>>>> secs]*, 0.0376863 secs] >>>>>>> [Times: user=0.07 sys=0.00, real=0.04 secs] >>>>>>> 21.374: [GC concurrent-count-start] >>>>>>> 21.380: [GC concurrent-count-end, 0.0059530] >>>>>>> 21.380: [GC cleanup 10M->10M(32M), 0.0004814 secs] >>>>>>> >>>>>>> The CPU times after the remark are for the remark pause as a whole. >>>>>>> Using the new output (either the delta between the timestamps or the >>>>>>> delta between the times) we can synthesize the amount of time it took >>>>>>> for the actual marking part of the remark pause. >>>>>>> >>>>>>> _PrintGCDetails + PrintReferenceGC_ >>>>>>> 12.450: [GC concurrent-mark-end, 0.0390687 sec] >>>>>>> 12.450: [GC remark *12.452: [GC remark (ref processing)*12.452: >>>>>>> [SoftReference, 0 refs, 0.0000226 secs]12.453: [WeakReference, 9 >>>>>>> refs, 0.0000216 secs]12.453: [FinalReference, 15279 refs, 0.0189796 >>>>>>> secs]12.472: [PhantomReference, 0 refs, 0.0000072 secs]12.472: [JNI >>>>>>> Weak Reference, 15 refs, 0.0000072 secs], *0.0272514 secs]*, >>>>>>> 0.0295062 secs] >>>>>>> [Times: user=0.04 sys=0.00, real=0.03 secs] >>>>>>> 12.480: [GC concurrent-count-start] >>>>>>> 12.486: [GC concurrent-count-end, 0.0059510] >>>>>>> 12.486: [GC cleanup 10M->10M(32M), 0.0005403 secs] >>>>>>> [Times: user=0.00 sys=0.00, real=0.00 secs] >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> JohnC >>>>> >>>> >> From kirk at kodewerk.com Sat Dec 10 07:59:15 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Sat, 10 Dec 2011 08:59:15 +0100 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE261DD.9020806@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: Hi John, The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. Regards, Kirk On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ > > Thanks, > > JohnC > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >> >> Thanks, >> >> JohnC From jon.masamitsu at oracle.com Sun Dec 11 06:00:03 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Sun, 11 Dec 2011 06:00:03 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7119584: UseParallelGC barrier task can be overwritten. Message-ID: <20111211060006.745524765D@hg.openjdk.java.net> Changeset: 6d7d0790074d Author: jmasa Date: 2011-12-09 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6d7d0790074d 7119584: UseParallelGC barrier task can be overwritten. Summary: Provoke a GC for a metadata allocation failure. Reviewed-by: johnc, iveresov ! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp From fancyerii at gmail.com Sun Dec 11 06:31:35 2011 From: fancyerii at gmail.com (Li Li) Date: Sun, 11 Dec 2011 14:31:35 +0800 Subject: how to know jvm is stopping the world? Message-ID: hi, In our application of full text searching with lucene and solr. we will give jvm about 25GB memory. we use CMS as old generation garbage collector. But the jvm sometimes can't do anything. So our clients complain that the connection is time out. we find the reason is the jvm is doing full gc and it will stop service for about 1-3 seconds. I know that this situation is inevitable when using CMS collector. but we have more than one searching machines, so if I know jvm is doing full gc(specially stop the world), I can send requests to other machines. But the question now is that jvm don't provide an api for that. I think it's not very difficult(for guys developing hotspot, but is in deed difficult for me ). So I want your help. The first question is where is the position of CMS full gc. from http://blogs.oracle.com/jonthecollector/entry/did_you_know there are many steps: 1. STW initial mark 2. Concurrent marking 3. Concurrent precleaning 4. STW remark 5. Concurrent sweeping 6. Concurrent reset there are 2 stop the world stages. I want to know the line number(or functions) of this stages. so I can tell java program that jvm now is doing full gc. The second is that how to communicate between jvm and java program? My expected thing is like : //java program if(System.isStopTheWolrd()){ //system is busy, tell the dispatch node that don't send request to me }else{ do service; } I have no experience in jvm developing. jvm is implemented in c and jni is the interface between them. is there any other method that jvm can achieve this? obviously, it can extend System class and add a static method named isStopTheWorld(). Could some one tell me how to do this in details? Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Sun Dec 11 09:32:35 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Sun, 11 Dec 2011 01:32:35 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE261DD.9020806@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: Hi John -- Looks fine. Two minor comments: (1) by defining an os::javaTimeNanosInMillis() you may be able to consolidate the divide by NANOS_IN_MILLISEC to one place instead of it appearing at each use. (2) you might consolidate the commentary about monotonicity into os::javaTimeNanosInMillis(), then at each client simly say "Protect against possible nonmonotonicity" That will reduce the number of repeated lines while still providing all of the commentary in all the relevant places. (By the way, you might want to check if there;s another CR with the same content which might be closed as a dup of this... just a very vague recollection.) reviewed. -- ramki (opendjk: ysr) On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson < john.cuthbertson at oracle.com> wrote: > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. A new > webrev can be found at: http://cr.openjdk.java.net/~** > johnc/7117303/webrev.1/ > > Thanks, > > JohnC > > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: > >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this CR? The >> webrev can be found at: http://cr.openjdk.java.net/~** >> johnc/7117303/webrev.0/ >> . >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where we expect >> monotonicity with calls os::javaTimeNanos(), converting the result to >> milliseconds. os::javaTimeNanos(), at least on some configurations, does >> guarantee monotonicity and so is a better alternative. The changes in the >> os_<*> files are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have multiple names for >> the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and >> jprt. >> >> Thanks, >> >> JohnC >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbordet at intalio.com Sun Dec 11 16:32:13 2011 From: sbordet at intalio.com (Simone Bordet) Date: Sun, 11 Dec 2011 17:32:13 +0100 Subject: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: Hi, On Sun, Dec 11, 2011 at 07:31, Li Li wrote: > hi, > ? ? In our application of full text searching with lucene and solr. we will > give jvm about 25GB memory. we use CMS as old generation garbage collector. > But the jvm sometimes can't do anything. So our clients complain that the > connection is time out. we find the reason is the jvm is doing full gc and > it will stop service for about 1-3 seconds. > ? ? I know that this situation is inevitable when using CMS collector. but > we have more than one searching machines, so if I know jvm is doing full > gc(specially stop the world), I can send requests to other machines. But the > question now is that jvm don't provide an api for that. I think that the hotspot-gc-use is a better mailing list for these kind of questions. Having said that, I think your approach is too naive. If you have a 10s STW, then you cannot "send request to other machines" because the world is - indeed - stopped. There is no use for providing the API that you suggest; you should instead tune your GC until you get rid of long STW pauses. Simon -- http://cometd.org http://intalio.com http://bordet.blogspot.com ---- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless.?? Victoria Livschitz From fancyerii at gmail.com Mon Dec 12 03:50:23 2011 From: fancyerii at gmail.com (Li Li) Date: Mon, 12 Dec 2011 11:50:23 +0800 Subject: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: That's two things. I am also trying to tune gc parameters to reduce pause time. but the pause is inevitable. So I think this feature is useful. That's why .net provide one. Recalling why we use CMS instead of Paralleling old gc. as for throughput, ParallelOldGC is better than CMS. But the pause time is worse. in many applications, pause means no service available and customers' complaint. if there is such an api, we can do this: we usually have load balance node which dispatch requests to nodes doing something interesting. before sending request to a node, dispatching node will ask whether jvm is busy(doing full gc, stw). if it is, then send requests to other nodes. Then we can use throughput optimized gc in these nodes with high throughput. The overall performance may be better than using CMS collector because there are many overheads in order to achieve small pause time. On Mon, Dec 12, 2011 at 12:32 AM, Simone Bordet wrote: > Hi, > > On Sun, Dec 11, 2011 at 07:31, Li Li wrote: > > hi, > > In our application of full text searching with lucene and solr. we > will > > give jvm about 25GB memory. we use CMS as old generation garbage > collector. > > But the jvm sometimes can't do anything. So our clients complain that the > > connection is time out. we find the reason is the jvm is doing full gc > and > > it will stop service for about 1-3 seconds. > > I know that this situation is inevitable when using CMS collector. > but > > we have more than one searching machines, so if I know jvm is doing full > > gc(specially stop the world), I can send requests to other machines. But > the > > question now is that jvm don't provide an api for that. > > I think that the hotspot-gc-use is a better mailing list for these > kind of questions. > Having said that, I think your approach is too naive. > If you have a 10s STW, then you cannot "send request to other > machines" because the world is - indeed - stopped. > There is no use for providing the API that you suggest; you should > instead tune your GC until you get rid of long STW pauses. > > Simon > -- > http://cometd.org > http://intalio.com > http://bordet.blogspot.com > ---- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fancyerii at gmail.com Mon Dec 12 03:55:10 2011 From: fancyerii at gmail.com (Li Li) Date: Mon, 12 Dec 2011 11:55:10 +0800 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Krystal Mok Date: Sun, Dec 11, 2011 at 5:53 PM Subject: Re: how to know jvm is stopping the world? To: Li Li HI, You're probably looking in the wrong direction. When the JVM "stops-the-world", it stops the world -- all Java threads (or "mutators") are suspended. There's no way for you to execute any Java code during that period. HotSpot VM uses a "safepoint" mechanism to stop-the-world. You can get safepoint stats with -XX:+PrintSafepointStatistics. There's an alternative that might help. Try GC notification with JMX [1]. Setup a notification threshold, and when the heap usage crosses the threshold, you'll get a notification. Put the load balancing logic in the callback. Even though this is different from "a notification of stop-the-world pause", it might work for you. There's a GC notification mechanism in .NET that might have been closer to what you wanted [2]. - Kris [1]: http://docs.oracle.com/javase/6/docs/api/java/lang/management/MemoryMXBean.html [2]: http://msdn.microsoft.com/en-us/library/cc713687.aspx On Sun, Dec 11, 2011 at 2:31 PM, Li Li wrote: > hi, > In our application of full text searching with lucene and solr. we > will give jvm about 25GB memory. we use CMS as old generation garbage > collector. But the jvm sometimes can't do anything. So our clients complain > that the connection is time out. we find the reason is the jvm is doing > full gc and it will stop service for about 1-3 seconds. > I know that this situation is inevitable when using CMS collector. but > we have more than one searching machines, so if I know jvm is doing full > gc(specially stop the world), I can send requests to other machines. But > the question now is that jvm don't provide an api for that. I think it's > not very difficult(for guys developing hotspot, but is in deed difficult > for me ). So I want your help. > The first question is where is the position of CMS full gc. > from http://blogs.oracle.com/jonthecollector/entry/did_you_know > there are many steps: > 1. STW initial mark > 2. Concurrent marking > 3. Concurrent precleaning > 4. STW remark > 5. Concurrent sweeping > 6. Concurrent reset > there are 2 stop the world stages. I want to know the line number(or > functions) of this stages. so I can tell java program that jvm now is doing > full gc. > The second is that how to communicate between jvm and java program? > My expected thing is like : > //java program > if(System.isStopTheWolrd()){ > //system is busy, tell the dispatch node that don't send > request to me > }else{ > do service; > } > I have no experience in jvm developing. jvm is implemented in c and > jni is the interface between them. is there any other method that jvm can > achieve this? obviously, it can extend System class and add a static method > named isStopTheWorld(). Could some one tell me how to do this in details? > Thank you very much. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon Dec 12 13:57:38 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2011 08:57:38 -0500 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: But suppose you had this feature and the VM tells you that it's not doing (or doesn't have any pending) full gc. Your load balancer then sends the request to that server - what happens if the processing of this request triggers a full gc? I just don't think there's a comprehensive solution here since you'd still run the risk of having a STW pause amidst request processing. As for jmx notifications on heap usage it's still just a guess in terms of what that actually means - the gc that follows may be concurrent (not STW) or there may not be a gc at all if the mem allocations aren't high enough. I agree with Krystal that it makes most sense in tuning the GC + checking your own code to make sure it plays well with the GC algorithm that you're using (I.e. CMS). On Dec 11, 2011 10:56 PM, "Li Li" wrote: > > ---------- Forwarded message ---------- > From: Krystal Mok > Date: Sun, Dec 11, 2011 at 5:53 PM > Subject: Re: how to know jvm is stopping the world? > To: Li Li > > > HI, > > You're probably looking in the wrong direction. When the JVM > "stops-the-world", it stops the world -- all Java threads (or "mutators") > are suspended. There's no way for you to execute any Java code during that > period. > HotSpot VM uses a "safepoint" mechanism to stop-the-world. You can get > safepoint stats with -XX:+PrintSafepointStatistics. > > There's an alternative that might help. Try GC notification with JMX [1]. > Setup a notification threshold, and when the heap usage crosses the > threshold, you'll get a notification. Put the load balancing logic in the > callback. Even though this is different from "a notification of > stop-the-world pause", it might work for you. > > There's a GC notification mechanism in .NET that might have been closer to > what you wanted [2]. > > - Kris > > [1]: > http://docs.oracle.com/javase/6/docs/api/java/lang/management/MemoryMXBean.html > [2]: http://msdn.microsoft.com/en-us/library/cc713687.aspx > > On Sun, Dec 11, 2011 at 2:31 PM, Li Li wrote: > >> hi, >> In our application of full text searching with lucene and solr. we >> will give jvm about 25GB memory. we use CMS as old generation garbage >> collector. But the jvm sometimes can't do anything. So our clients complain >> that the connection is time out. we find the reason is the jvm is doing >> full gc and it will stop service for about 1-3 seconds. >> I know that this situation is inevitable when using CMS collector. >> but we have more than one searching machines, so if I know jvm is doing >> full gc(specially stop the world), I can send requests to other machines. >> But the question now is that jvm don't provide an api for that. I think >> it's not very difficult(for guys developing hotspot, but is in deed >> difficult for me ). So I want your help. >> The first question is where is the position of CMS full gc. >> from http://blogs.oracle.com/jonthecollector/entry/did_you_know >> there are many steps: >> 1. STW initial mark >> 2. Concurrent marking >> 3. Concurrent precleaning >> 4. STW remark >> 5. Concurrent sweeping >> 6. Concurrent reset >> there are 2 stop the world stages. I want to know the line number(or >> functions) of this stages. so I can tell java program that jvm now is doing >> full gc. >> The second is that how to communicate between jvm and java program? >> My expected thing is like : >> //java program >> if(System.isStopTheWolrd()){ >> //system is busy, tell the dispatch node that don't send >> request to me >> }else{ >> do service; >> } >> I have no experience in jvm developing. jvm is implemented in c and >> jni is the interface between them. is there any other method that jvm can >> achieve this? obviously, it can extend System class and add a static method >> named isStopTheWorld(). Could some one tell me how to do this in details? >> Thank you very much. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon Dec 12 14:27:04 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2011 09:27:04 -0500 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE25EFE.9090902@oracle.com> References: <4EE25EFE.9090902@oracle.com> Message-ID: Hi John, Just curious - why did you make the timestamp a uint* instead of uint? Thanks, Vitaly On Dec 9, 2011 2:20 PM, "John Cuthbertson" wrote: > ** > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ > > Summary: > As part of the code review comments for 7112743 (G1: Reduce overhead of > marking closure during evacuation pauses) it was suggested that instead of > recalculating the starting heap region for each worker thread, we reuse the > values calculated during RSet scanning. These changes address that review > comment. In these changes I maintain a cache that is used and updated by > G1CollectedHeap::start_cset_region_for_worker(). The first time this > routine is called by a worker thread during an evacuation pause (currently > during RSet scanning) the cached value for the worker gets set; when the > routine is called subsequently the region that was cached for the worker is > returned. I employ a simple stamp mechanism based upon the number of GCs > that ensures the validity of the regions in the cache and makes clearing > the cache unnecessary. > > Testing: > GC Test suite with a small marking threshold (10%) with and without > verification; the configuration of SPECjbb used to test 7117423; > Kitchensink. > > Thanks, > > JohnC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Mon Dec 12 14:32:25 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 12 Dec 2011 09:32:25 -0500 Subject: G1 discovers same garbage again? In-Reply-To: References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> Message-ID: <4EE61079.9030807@oracle.com> Ramki., On 12/09/2011 07:34 PM, Srinivas Ramakrishna wrote: > > > A couple of things caught my eye.... > > On 12/05/2011 02:19 PM, Florian Binder wrote: > >> I assume you know when the data will be dropped and reinitialized, > >> right? Can you do a Full GC (with System.gc()) after you > re-initialize > >> the heap. This typically helps a lot with CMS. > > Yes, this is exactly what we are trying at this time ;-) > > Either this Full-GC pauses are very long (60-300 seconds) they > are much > > shorter than after a CMS-failure (when they take sometimes more than > > 4000 seconds ;-)) and we can define when they occure. > > > A full GC that takes an hour is definitely a bug. Good catch, I clearly didn't do the translation. :-) Could it be paging? Tony > Have you logged that bug? > Or at least share the GC log? What's the version of the JDK that this > behaviour > was seen with? > > ... > > > Furthermore this should not increase the total-heap-space: > > http://java4.info/g1/all.png > > > Remember that jconsole asynchronously samples the heap, whose size is > read "with possible glitches". Rather, you should probably rely on the > GC log in order to assess > the heap size after each GC event, rather than the asynchronous > samples from > jconsole. I myself have not had the chance to look at yr GC logs to see > what that indicated wrt the size of Eden and of the Heap. > > -- ramki > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From vitalyd at gmail.com Mon Dec 12 14:45:19 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2011 09:45:19 -0500 Subject: G1 discovers same garbage again? In-Reply-To: <4EE61079.9030807@oracle.com> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> <4EE61079.9030807@oracle.com> Message-ID: I wonder - did it actually complete after 4000 seconds? Maybe the process was restarted before it finished but it had been running for that long up to that point; if so maybe GC hit some bug and would never have terminated? I guess something for Florian to answer. On Dec 12, 2011 9:34 AM, "Tony Printezis" wrote: > Ramki., > > On 12/09/2011 07:34 PM, Srinivas Ramakrishna wrote: > > > > A couple of things caught my eye.... > > On 12/05/2011 02:19 PM, Florian Binder wrote: >> >> I assume you know when the data will be dropped and reinitialized, >> >> right? Can you do a Full GC (with System.gc()) after you re-initialize >> >> the heap. This typically helps a lot with CMS. >> > Yes, this is exactly what we are trying at this time ;-) >> > Either this Full-GC pauses are very long (60-300 seconds) they are much >> > shorter than after a CMS-failure (when they take sometimes more than >> > 4000 seconds ;-)) and we can define when they occure. >> > > A full GC that takes an hour is definitely a bug. > > > Good catch, I clearly didn't do the translation. :-) Could it be paging? > > Tony > > Have you logged that bug? > Or at least share the GC log? What's the version of the JDK that this > behaviour > was seen with? > > ... > >> > Furthermore this should not increase the total-heap-space: >> > http://java4.info/g1/all.png >> > > Remember that jconsole asynchronously samples the heap, whose size is > read "with possible glitches". Rather, you should probably rely on the GC > log in order to assess > the heap size after each GC event, rather than the asynchronous samples > from > jconsole. I myself have not had the chance to look at yr GC logs to see > what that indicated wrt the size of Eden and of the Heap. > > -- ramki > > > _______________________________________________ > hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Mon Dec 12 14:46:23 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Mon, 12 Dec 2011 09:46:23 -0500 Subject: G1 discovers same garbage again? In-Reply-To: <4EE2BF0D.1050005@java4.info> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> <4EE2BF0D.1050005@java4.info> Message-ID: <4EE613BF.20501@oracle.com> Florian, Not sure what you mean by "the same GC". It is because the space transition looks like: 16394M->12914M(20480M)? This is normal. Heap occupancy reaches 16394M, GC happens, heap occupancy goes down to 12914M. Next time it happens, the heap will have new objects. This is how GCs work. Tony On 12/09/2011 09:08 PM, Florian Binder wrote: > In the gc log it seems that there is always running the same garbage > collection. > For example: > $ zcat out_err.log.gz | grep 20480M | tail > 2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M), > 0.1370060 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > 2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M), > 0.1387230 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > 2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M), > 0.1344170 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > > Therefore I assume this might be a bug ;-) > You can download the whole log at: http://java4.info/g1/out_err.log.gz > > I don't think that we still have the logs of that very long gc, but I > will have a look for it at monday. > Furthermore I do not think that we have logged there much details of > the gc. But I know that this happend on a very special server, which > contains more the 30gb of references (yes, just references to other > objects). If we run it with CompressedOops we reduce the memory useage > to nearly 50%. > > Flo > > > > Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna: >> >> >> A couple of things caught my eye.... >> >> On 12/05/2011 02:19 PM, Florian Binder wrote: >> >> I assume you know when the data will be dropped and reinitialized, >> >> right? Can you do a Full GC (with System.gc()) after you >> re-initialize >> >> the heap. This typically helps a lot with CMS. >> > Yes, this is exactly what we are trying at this time ;-) >> > Either this Full-GC pauses are very long (60-300 seconds) they >> are much >> > shorter than after a CMS-failure (when they take sometimes more >> than >> > 4000 seconds ;-)) and we can define when they occure. >> >> >> A full GC that takes an hour is definitely a bug. Have you logged >> that bug? >> Or at least share the GC log? What's the version of the JDK that this >> behaviour >> was seen with? >> >> ... >> >> > Furthermore this should not increase the total-heap-space: >> > http://java4.info/g1/all.png >> >> >> Remember that jconsole asynchronously samples the heap, whose size is >> read "with possible glitches". Rather, you should probably rely on >> the GC log in order to assess >> the heap size after each GC event, rather than the asynchronous >> samples from >> jconsole. I myself have not had the chance to look at yr GC logs to see >> what that indicated wrt the size of Eden and of the Heap. >> >> -- ramki > > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Dec 12 15:06:28 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 12 Dec 2011 16:06:28 +0100 Subject: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: <4EE61874.2090203@oracle.com> On 12/11/2011 07:31 AM, Li Li wrote: > hi, > In our application of full text searching with lucene and solr. we > will give jvm about 25GB memory. we use CMS as old generation garbage > collector. But the jvm sometimes can't do anything. So our clients > complain that the connection is time out. we find the reason is the > jvm is doing full gc and it will stop service for about 1-3 seconds. > I know that this situation is inevitable when using CMS collector. > but we have more than one searching machines, so if I know jvm is > doing full gc(specially stop the world), I can send requests to other > machines. But the question now is that jvm don't provide an api for > that. I think it's not very difficult(for guys developing hotspot, but > is in deed difficult for me ). So I want your help. > The first question is where is the position of CMS full gc. > from http://blogs.oracle.com/jonthecollector/entry/did_you_know > there are many steps: > 1. STW initial mark > 2. Concurrent marking > 3. Concurrent precleaning > 4. STW remark > 5. Concurrent sweeping > 6. Concurrent reset > there are 2 stop the world stages. I want to know the line > number(or functions) of this stages. so I can tell java program that > jvm now is doing full gc. > The second is that how to communicate between jvm and java > program? My expected thing is like : > //java program > if(System.isStopTheWolrd()){ > //system is busy, tell the dispatch node that don't send > request to me > }else{ > do service; > } > I have no experience in jvm developing. jvm is implemented in c > and jni is the interface between them. is there any other method that > jvm can achieve this? obviously, it can extend System class and add a > static method named isStopTheWorld(). Could some one tell me how to do > this in details? Thank you very much. You could probably use JVMTI. See: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#GarbageCollectionStart StefanK From yumin.qi at oracle.com Mon Dec 12 16:13:53 2011 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Mon, 12 Dec 2011 08:13:53 -0800 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: <4EE62841.4070907@oracle.com> Your calling method (even there were such method, in fact there is no such function) will not be executed during STW, since all java threads stopped. The result is that after JVM resumes all java threads, your call will return true always. To know the jvm status, you have to use some agents like JVMTI. --Yumin On 12/11/2011 7:55 PM, Li Li wrote: > > ---------- Forwarded message ---------- > From: *Krystal Mok* > > Date: Sun, Dec 11, 2011 at 5:53 PM > Subject: Re: how to know jvm is stopping the world? > To: Li Li > > > > HI, > > You're probably looking in the wrong direction. When the JVM > "stops-the-world", it stops the world -- all Java threads (or > "mutators") are suspended. There's no way for you to execute any Java > code during that period. > HotSpot VM uses a "safepoint" mechanism to stop-the-world. You can get > safepoint stats with -XX:+PrintSafepointStatistics. > > There's an alternative that might help. Try GC notification with JMX > [1]. Setup a notification threshold, and when the heap usage crosses > the threshold, you'll get a notification. Put the load balancing logic > in the callback. Even though this is different from "a notification of > stop-the-world pause", it might work for you. > > There's a GC notification mechanism in .NET that might have been > closer to what you wanted [2]. > > - Kris > > [1]: > http://docs.oracle.com/javase/6/docs/api/java/lang/management/MemoryMXBean.html > [2]: http://msdn.microsoft.com/en-us/library/cc713687.aspx > > On Sun, Dec 11, 2011 at 2:31 PM, Li Li > wrote: > > hi, > In our application of full text searching with lucene and > solr. we will give jvm about 25GB memory. we use CMS as old > generation garbage collector. But the jvm sometimes can't do > anything. So our clients complain that the connection is time out. > we find the reason is the jvm is doing full gc and it will stop > service for about 1-3 seconds. > I know that this situation is inevitable when using CMS > collector. but we have more than one searching machines, so if I > know jvm is doing full gc(specially stop the world), I can send > requests to other machines. But the question now is that jvm don't > provide an api for that. I think it's not very difficult(for guys > developing hotspot, but is in deed difficult for me ). So I want > your help. > The first question is where is the position of CMS full gc. > from http://blogs.oracle.com/jonthecollector/entry/did_you_know > there are many steps: > 1. STW initial mark > 2. Concurrent marking > 3. Concurrent precleaning > 4. STW remark > 5. Concurrent sweeping > 6. Concurrent reset > there are 2 stop the world stages. I want to know the line > number(or functions) of this stages. so I can tell java program > that jvm now is doing full gc. > The second is that how to communicate between jvm and java > program? My expected thing is like : > //java program > if(System.isStopTheWolrd()){ > //system is busy, tell the dispatch node that don't > send request to me > }else{ > do service; > } > I have no experience in jvm developing. jvm is implemented in > c and jni is the interface between them. is there any other method > that jvm can achieve this? obviously, it can extend System class > and add a static method named isStopTheWorld(). Could some one > tell me how to do this in details? Thank you very much. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelbing at icubic.de Mon Dec 12 16:30:57 2011 From: rhelbing at icubic.de (Ralf Helbing) Date: Mon, 12 Dec 2011 17:30:57 +0100 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: <4EE62841.4070907@oracle.com> References: <4EE62841.4070907@oracle.com> Message-ID: <4EE62C41.1010209@icubic.de> Why don't you set up a timer that // Tells the dispatcher to leave me alone System.fullGC(); // Tells the dispatcher that I am back every now and then? cheeers, Ralf From john.cuthbertson at oracle.com Mon Dec 12 18:20:01 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 12 Dec 2011 10:20:01 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: References: <4EE25EFE.9090902@oracle.com> Message-ID: <4EE645D1.10909@oracle.com> Hi Vitaly, Thanks for looking at the code. The stamp is a pointer because it is actually an array of stamps - a separate stamp for each worker. Setting the stamp (for a given worker) at the same time as we cache the starting region means that we can determine if the starting region has been set (during the current pause) without having to clear the cache at the end of the pause. If the stamp for given worker has not been set during the current pause then we have to assume that the starting region entry for that worker is stale and re-calculate the starting region (setting the stamp and updating the cache). Does this answer your question? Let me know if you any others. Thanks, JohnC On 12/12/11 06:27, Vitaly Davidovich wrote: > > Hi John, > > Just curious - why did you make the timestamp a uint* instead of uint? > > Thanks, > > Vitaly > > On Dec 9, 2011 2:20 PM, "John Cuthbertson" > > wrote: > > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this > CR? The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ > > > Summary: > As part of the code review comments for 7112743 (G1: Reduce > overhead of marking closure during evacuation pauses) it was > suggested that instead of recalculating the starting heap region > for each worker thread, we reuse the values calculated during RSet > scanning. These changes address that review comment. In these > changes I maintain a cache that is used and updated by > G1CollectedHeap::start_cset_region_for_worker(). The first time > this routine is called by a worker thread during an evacuation > pause (currently during RSet scanning) the cached value for the > worker gets set; when the routine is called subsequently the > region that was cached for the worker is returned. I employ a > simple stamp mechanism based upon the number of GCs that ensures > the validity of the regions in the cache and makes clearing the > cache unnecessary. > > Testing: > GC Test suite with a small marking threshold (10%) with and > without verification; the configuration of SPECjbb used to test > 7117423; Kitchensink. > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Mon Dec 12 18:37:01 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2011 13:37:01 -0500 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE645D1.10909@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE645D1.10909@oracle.com> Message-ID: Hi John, Yes makes total sense - I completely missed the n_queues arg in the allocation (that's what I get for looking at this on my phone :)). Sorry for the noise. Thanks, Vitaly On Dec 12, 2011 1:20 PM, "John Cuthbertson" wrote: > ** > Hi Vitaly, > > Thanks for looking at the code. The stamp is a pointer because it is > actually an array of stamps - a separate stamp for each worker. Setting the > stamp (for a given worker) at the same time as we cache the starting region > means that we can determine if the starting region has been set (during the > current pause) without having to clear the cache at the end of the pause. > If the stamp for given worker has not been set during the current pause > then we have to assume that the starting region entry for that worker is > stale and re-calculate the starting region (setting the stamp and updating > the cache). > > Does this answer your question? > > Let me know if you any others. > > Thanks, > > JohnC > > On 12/12/11 06:27, Vitaly Davidovich wrote: > > Hi John, > > Just curious - why did you make the timestamp a uint* instead of uint? > > Thanks, > > Vitaly > On Dec 9, 2011 2:20 PM, "John Cuthbertson" > wrote: > > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ > > Summary: > As part of the code review comments for 7112743 (G1: Reduce overhead of > marking closure during evacuation pauses) it was suggested that instead of > recalculating the starting heap region for each worker thread, we reuse the > values calculated during RSet scanning. These changes address that review > comment. In these changes I maintain a cache that is used and updated by > G1CollectedHeap::start_cset_region_for_worker(). The first time this > routine is called by a worker thread during an evacuation pause (currently > during RSet scanning) the cached value for the worker gets set; when the > routine is called subsequently the region that was cached for the worker is > returned. I employ a simple stamp mechanism based upon the number of GCs > that ensures the validity of the regions in the cache and makes clearing > the cache unnecessary. > > Testing: > GC Test suite with a small marking threshold (10%) with and without > verification; the configuration of SPECjbb used to test 7117423; > Kitchensink. > > Thanks, > > JohnC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.fleischer at fu-berlin.de Thu Dec 8 20:18:14 2011 From: julian.fleischer at fu-berlin.de (Julian Fleischer) Date: Thu, 8 Dec 2011 21:18:14 +0100 Subject: Will G1GC be the default GC in JRE 7 eventually? Message-ID: <0796CC9D-E11A-42C5-866E-000292430BFF@fu-berlin.de> Hi, I?m wondering what the state of the Garbage First Garbage Collector is in current and upcoming JREs, as it is rather sparley documented and no official and up-to-date FAQ can be found. This is partly in response to the following Stackoverflow Question: http://stackoverflow.com/a/8427161/471478 Please, can you tell us what the state of G1GC is for current and future versions of the OpenJDK? Is it stable, meant to replace current GC? kind regards, Julian Fleischer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3633 bytes Desc: not available URL: From java at java4.info Mon Dec 12 19:08:17 2011 From: java at java4.info (Florian Binder) Date: Mon, 12 Dec 2011 20:08:17 +0100 Subject: G1 discovers same garbage again? In-Reply-To: <4EE613BF.20501@oracle.com> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> <4EE2BF0D.1050005@java4.info> <4EE613BF.20501@oracle.com> Message-ID: <4EE65121.9010004@java4.info> Tony, As you have seen at the jconsole-screenshot the app does make very few garbage. It is optimized to make no garbage. But suddenly there seems to be every 90 seconds about 4 gb of (new) garbage (even the load of the app does not change). Therefore I thought it might be the g1-collector. I will try to reproduce this senario an have a closure look on it. Flo Am 12.12.2011 15:46, schrieb Tony Printezis: > Florian, > > Not sure what you mean by "the same GC". It is because the space > transition looks like: 16394M->12914M(20480M)? This is normal. Heap > occupancy reaches 16394M, GC happens, heap occupancy goes down to > 12914M. Next time it happens, the heap will have new objects. This is > how GCs work. > > Tony > > On 12/09/2011 09:08 PM, Florian Binder wrote: >> In the gc log it seems that there is always running the same garbage >> collection. >> For example: >> $ zcat out_err.log.gz | grep 20480M | tail >> 2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M), >> 0.1370060 secs] >> [ 16394M->12914M(20480M)] >> [ 16394M->12914M(20480M)] >> 2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M), >> 0.1387230 secs] >> [ 16394M->12914M(20480M)] >> [ 16394M->12914M(20480M)] >> [ 16394M->12914M(20480M)] >> 2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M), >> 0.1344170 secs] >> [ 16394M->12914M(20480M)] >> [ 16394M->12914M(20480M)] >> >> Therefore I assume this might be a bug ;-) >> You can download the whole log at: http://java4.info/g1/out_err.log.gz >> >> I don't think that we still have the logs of that very long gc, but I >> will have a look for it at monday. >> Furthermore I do not think that we have logged there much details of >> the gc. But I know that this happend on a very special server, which >> contains more the 30gb of references (yes, just references to other >> objects). If we run it with CompressedOops we reduce the memory >> useage to nearly 50%. >> >> Flo >> >> >> >> Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna: >>> >>> >>> A couple of things caught my eye.... >>> >>> On 12/05/2011 02:19 PM, Florian Binder wrote: >>> >> I assume you know when the data will be dropped and >>> reinitialized, >>> >> right? Can you do a Full GC (with System.gc()) after you >>> re-initialize >>> >> the heap. This typically helps a lot with CMS. >>> > Yes, this is exactly what we are trying at this time ;-) >>> > Either this Full-GC pauses are very long (60-300 seconds) they >>> are much >>> > shorter than after a CMS-failure (when they take sometimes >>> more than >>> > 4000 seconds ;-)) and we can define when they occure. >>> >>> >>> A full GC that takes an hour is definitely a bug. Have you logged >>> that bug? >>> Or at least share the GC log? What's the version of the JDK that >>> this behaviour >>> was seen with? >>> >>> ... >>> >>> > Furthermore this should not increase the total-heap-space: >>> > http://java4.info/g1/all.png >>> >>> >>> Remember that jconsole asynchronously samples the heap, whose size is >>> read "with possible glitches". Rather, you should probably rely on >>> the GC log in order to assess >>> the heap size after each GC event, rather than the asynchronous >>> samples from >>> jconsole. I myself have not had the chance to look at yr GC logs to see >>> what that indicated wrt the size of Eden and of the Heap. >>> >>> -- ramki >> >> >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Mon Dec 12 19:40:54 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 12 Dec 2011 11:40:54 -0800 Subject: G1 discovers same garbage again? In-Reply-To: <4EE65121.9010004@java4.info> References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> <4EE2BF0D.1050005@java4.info> <4EE613BF.20501@oracle.com> <4EE65121.9010004@java4.info> Message-ID: As I said, instead of relying on jconsole's asynchronous heap size samples, look at the GC log to see if the inter-scavenge period suddenly falls (i.e. the application is presumably allocating at a much faster rate than is normal). If the GC log confirns that, then see if turning off TLAB resizing (and fixing it to a reasonable value) makes any difference. Your existing GC logs should be sufficient to answer the first part of the question above. best. -- ramki On Mon, Dec 12, 2011 at 11:08 AM, Florian Binder wrote: > Tony, > > As you have seen at the jconsole-screenshot the app does make very few > garbage. It is optimized to make no garbage. But suddenly there seems to be > every 90 seconds about 4 gb of (new) garbage (even the load of the app does > not change). Therefore I thought it might be the g1-collector. I will try > to reproduce this senario an have a closure look on it. > > Flo > > Am 12.12.2011 15:46, schrieb Tony Printezis: > > Florian, > > Not sure what you mean by "the same GC". It is because the space > transition looks like: 16394M->12914M(20480M)? This is normal. Heap > occupancy reaches 16394M, GC happens, heap occupancy goes down to 12914M. > Next time it happens, the heap will have new objects. This is how GCs work. > > Tony > > On 12/09/2011 09:08 PM, Florian Binder wrote: > > In the gc log it seems that there is always running the same garbage > collection. > For example: > $ zcat out_err.log.gz | grep 20480M | tail > 2011-11-28T19:13:19.482+0100: [GC cleanup 14515M->14515M(20480M), > 0.1370060 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > 2011-11-28T19:17:12.509+0100: [GC cleanup 15582M->15582M(20480M), > 0.1387230 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > 2011-11-28T19:21:06.089+0100: [GC cleanup 12978M->12978M(20480M), > 0.1344170 secs] > [ 16394M->12914M(20480M)] > [ 16394M->12914M(20480M)] > > Therefore I assume this might be a bug ;-) > You can download the whole log at: http://java4.info/g1/out_err.log.gz > > I don't think that we still have the logs of that very long gc, but I will > have a look for it at monday. > Furthermore I do not think that we have logged there much details of the > gc. But I know that this happend on a very special server, which contains > more the 30gb of references (yes, just references to other objects). If we > run it with CompressedOops we reduce the memory useage to nearly 50%. > > Flo > > > > Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna: > > > > A couple of things caught my eye.... > > On 12/05/2011 02:19 PM, Florian Binder wrote: >> >> I assume you know when the data will be dropped and reinitialized, >> >> right? Can you do a Full GC (with System.gc()) after you re-initialize >> >> the heap. This typically helps a lot with CMS. >> > Yes, this is exactly what we are trying at this time ;-) >> > Either this Full-GC pauses are very long (60-300 seconds) they are much >> > shorter than after a CMS-failure (when they take sometimes more than >> > 4000 seconds ;-)) and we can define when they occure. >> > > A full GC that takes an hour is definitely a bug. Have you logged that bug? > Or at least share the GC log? What's the version of the JDK that this > behaviour > was seen with? > > ... > >> > Furthermore this should not increase the total-heap-space: >> > http://java4.info/g1/all.png >> > > Remember that jconsole asynchronously samples the heap, whose size is > read "with possible glitches". Rather, you should probably rely on the GC > log in order to assess > the heap size after each GC event, rather than the asynchronous samples > from > jconsole. I myself have not had the chance to look at yr GC logs to see > what that indicated wrt the size of Eden and of the Heap. > > -- ramki > > > > > _______________________________________________ > hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Mon Dec 12 19:48:09 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 12 Dec 2011 11:48:09 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: <4EE65A79.3050809@oracle.com> Hi Kirk, Can you please try monaco.us.oracle.com? I believe the link is supplied by the webrev tool automatically when it sees the CR# in the mercurial queue patch. It could be that my path references an old version. Thanks, JohnC On 12/09/11 23:59, Charles K Pepperdine wrote: > Hi John, > > The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. > > Regards, > Kirk > > > On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: > > >> Hi Everyone, >> >> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >> >> Thanks, >> >> JohnC >> >> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>> >>> Summary: >>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>> >>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>> >>> Thanks, >>> >>> JohnC >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Mon Dec 12 20:06:50 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Mon, 12 Dec 2011 12:06:50 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> Message-ID: <4EE65EDA.80300@oracle.com> Hi Ramki, Thanks for looking at the code changes and for the suggestions. Extending the os API is a good idea. Not sure about the name though - how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp already has an internal monotonic version of javaTimeMillis() so there are alternatives to using javaTimeNanos() in the implementation. Thanks for the heads up about the other CR. I'll check. Thanks, JohnC On 12/11/11 01:32, Srinivas Ramakrishna wrote: > Hi John -- Looks fine. Two minor comments: > > (1) by defining an os::javaTimeNanosInMillis() you may be able to > consolidate the divide by NANOS_IN_MILLISEC to one place instead of it > appearing at each use. > (2) you might consolidate the commentary about monotonicity into > os::javaTimeNanosInMillis(), then at each client simly say "Protect > against possible nonmonotonicity" > > That will reduce the number of repeated lines while still providing > all of the commentary in all the relevant places. (By the way, you > might want to > check if there;s another CR with the same content which might be > closed as a dup of this... just a very vague recollection.) > > reviewed. > -- ramki (opendjk: ysr) > > On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson > > wrote: > > Hi Everyone, > > I have updated the comments based upon feedback from David Holmes. > A new webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ > > > Thanks, > > JohnC > > > On 12/7/2011 9:59 AM, John Cuthbertson wrote: > > Hi Everyone, > > Can I have a couple of volunteers review the changes for this > CR? The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7117303/webrev.0/ > . > > Summary: > I replaced the calls to os::javaTimeMillis() in the GC where > we expect monotonicity with calls os::javaTimeNanos(), > converting the result to milliseconds. os::javaTimeNanos(), at > least on some configurations, does guarantee monotonicity and > so is a better alternative. The changes in the os_<*> files > are to make use of the named conversion constants I > added/moved to globalDefinitions.hpp - we seemed to have > multiple names for the same two constants. > > Testing: GC test suite on solaris and Linux, NSK tests on > solaris, and jprt. > > Thanks, > > JohnC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonimenen at gmail.com Mon Dec 12 21:00:41 2011 From: tonimenen at gmail.com (Toni Menendez Lopez) Date: Mon, 12 Dec 2011 22:00:41 +0100 Subject: OpenJDK vs SunJDK Message-ID: Hello all, I want to ask all of you on question ! I am normally working with SunJDK for my application (Java(TM) SE Runtime Environment (build 1.6.0_15-b03)) , but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)). I have executed the same performance test in SunJDK and OpenJDK and I have experienced that OpenJDK has worst performance that SunJDK. Any of you have got some similar experience ? My O.S is RHEL5.4 Best regards, Toni. _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From kirk at kodewerk.com Mon Dec 12 21:36:13 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Mon, 12 Dec 2011 22:36:13 +0100 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE65A79.3050809@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65A79.3050809@oracle.com> Message-ID: <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> Hi John, Thanks, that one fails also. Regards, Kirk On Dec 12, 2011, at 8:48 PM, John Cuthbertson wrote: > Hi Kirk, > > Can you please try monaco.us.oracle.com? I believe the link is supplied by the webrev tool automatically when it sees the CR# in the mercurial queue patch. It could be that my path references an old version. > > Thanks, > > JohnC > > On 12/09/11 23:59, Charles K Pepperdine wrote: >> >> Hi John, >> >> The link http://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. >> >> Regards, >> Kirk >> >> >> On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: >> >> >>> Hi Everyone, >>> >>> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >>> >>> Thanks, >>> >>> JohnC >>> >>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>> >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>>> >>>> Summary: >>>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>>> >>>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From java at java4.info Mon Dec 12 21:55:14 2011 From: java at java4.info (Florian Binder) Date: Mon, 12 Dec 2011 22:55:14 +0100 Subject: G1 discovers same garbage again? In-Reply-To: References: <4ED3DE79.5050801@java4.info> <4ED51672.6030105@oracle.com> <4ED5EAE1.2020102@java4.info> <4EDCFD9D.5040005@oracle.com> <4EDD1924.2030803@java4.info> <4EE26263.3040307@oracle.com> <4EE2BF0D.1050005@java4.info> <4EE613BF.20501@oracle.com> <4EE65121.9010004@java4.info> Message-ID: <4EE67842.303@java4.info> Hi Ramki, thanks for your answere. I have compared the gc-log with the jconsole chart and for every jump of the eden space to zero there is a (young) gc-entry in the log. So the jconsole chart is right and the scavenger period suddenly falls (even I am almost sure the application does not allocate more objects than before). Thank you for the hint with the TLAB size. I will trying this now. Flo Am 12.12.2011 20:40, schrieb Srinivas Ramakrishna: > > As I said, instead of relying on jconsole's asynchronous heap size > samples, look at the GC log to see > if the inter-scavenge period suddenly falls (i.e. the application is > presumably allocating at a much faster rate > than is normal). If the GC log confirns that, then see if turning off > TLAB resizing (and fixing it to a reasonable > value) makes any difference. > > Your existing GC logs should be sufficient to answer the first part of > the question above. > > best. > -- ramki > > On Mon, Dec 12, 2011 at 11:08 AM, Florian Binder > wrote: > > Tony, > > As you have seen at the jconsole-screenshot the app does make very > few garbage. It is optimized to make no garbage. But suddenly > there seems to be every 90 seconds about 4 gb of (new) garbage > (even the load of the app does not change). Therefore I thought it > might be the g1-collector. I will try to reproduce this senario an > have a closure look on it. > > Flo > > Am 12.12.2011 15:46, schrieb Tony Printezis: >> Florian, >> >> Not sure what you mean by "the same GC". It is because the space >> transition looks like: 16394M->12914M(20480M)? This is normal. >> Heap occupancy reaches 16394M, GC happens, heap occupancy goes >> down to 12914M. Next time it happens, the heap will have new >> objects. This is how GCs work. >> >> Tony >> >> On 12/09/2011 09:08 PM, Florian Binder wrote: >>> In the gc log it seems that there is always running the same >>> garbage collection. >>> For example: >>> $ zcat out_err.log.gz | grep 20480M | tail >>> 2011-11-28T19:13:19.482+0100: [GC cleanup >>> 14515M->14515M(20480M), 0.1370060 secs] >>> [ 16394M->12914M(20480M)] >>> [ 16394M->12914M(20480M)] >>> 2011-11-28T19:17:12.509+0100: [GC cleanup >>> 15582M->15582M(20480M), 0.1387230 secs] >>> [ 16394M->12914M(20480M)] >>> [ 16394M->12914M(20480M)] >>> [ 16394M->12914M(20480M)] >>> 2011-11-28T19:21:06.089+0100: [GC cleanup >>> 12978M->12978M(20480M), 0.1344170 secs] >>> [ 16394M->12914M(20480M)] >>> [ 16394M->12914M(20480M)] >>> >>> Therefore I assume this might be a bug ;-) >>> You can download the whole log at: >>> http://java4.info/g1/out_err.log.gz >>> >>> I don't think that we still have the logs of that very long gc, >>> but I will have a look for it at monday. >>> Furthermore I do not think that we have logged there much >>> details of the gc. But I know that this happend on a very >>> special server, which contains more the 30gb of references (yes, >>> just references to other objects). If we run it with >>> CompressedOops we reduce the memory useage to nearly 50%. >>> >>> Flo >>> >>> >>> >>> Am 10.12.2011 01:34, schrieb Srinivas Ramakrishna: >>>> >>>> >>>> A couple of things caught my eye.... >>>> >>>> On 12/05/2011 02:19 PM, Florian Binder wrote: >>>> >> I assume you know when the data will be dropped and >>>> reinitialized, >>>> >> right? Can you do a Full GC (with System.gc()) after you >>>> re-initialize >>>> >> the heap. This typically helps a lot with CMS. >>>> > Yes, this is exactly what we are trying at this time ;-) >>>> > Either this Full-GC pauses are very long (60-300 seconds) >>>> they are much >>>> > shorter than after a CMS-failure (when they take >>>> sometimes more than >>>> > 4000 seconds ;-)) and we can define when they occure. >>>> >>>> >>>> A full GC that takes an hour is definitely a bug. Have you >>>> logged that bug? >>>> Or at least share the GC log? What's the version of the JDK >>>> that this behaviour >>>> was seen with? >>>> >>>> ... >>>> >>>> > Furthermore this should not increase the total-heap-space: >>>> > http://java4.info/g1/all.png >>>> >>>> >>>> Remember that jconsole asynchronously samples the heap, whose >>>> size is >>>> read "with possible glitches". Rather, you should probably rely >>>> on the GC log in order to assess >>>> the heap size after each GC event, rather than the asynchronous >>>> samples from >>>> jconsole. I myself have not had the chance to look at yr GC >>>> logs to see >>>> what that indicated wrt the size of Eden and of the Heap. >>>> >>>> -- ramki >>> >>> >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.pampuch at oracle.com Tue Dec 13 00:48:36 2011 From: john.pampuch at oracle.com (John Pampuch) Date: Mon, 12 Dec 2011 16:48:36 -0800 Subject: Will G1GC be the default GC in JRE 7 eventually? In-Reply-To: <0796CC9D-E11A-42C5-866E-000292430BFF@fu-berlin.de> References: <0796CC9D-E11A-42C5-866E-000292430BFF@fu-berlin.de> Message-ID: <4EE6A0E4.5070300@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 13 03:08:16 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 13:08:16 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65A79.3050809@oracle.com> <6CA74534-43E3-484E-A5E3-E1E7E50F8756@kodewerk.com> Message-ID: <4EE6C1A0.8070201@oracle.com> John, monaco is Oracle internal, you need to link to bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117303 Cheers, David On 13/12/2011 7:36 AM, Charles K Pepperdine wrote: > Hi John, > > Thanks, that one fails also. > > Regards, > Kirk > > On Dec 12, 2011, at 8:48 PM, John Cuthbertson wrote: > >> Hi Kirk, >> >> Can you please try monaco.us.oracle.com ? >> I believe the link is supplied by the webrev tool automatically when >> it sees the CR# in the mercurial queue patch. It could be that my path >> references an old version. >> >> Thanks, >> >> JohnC >> >> On 12/09/11 23:59, Charles K Pepperdine wrote: >>> Hi John, >>> >>> The linkhttp://monaco.sfbay.sun.com/detail.jsp?cr=7117303 is unreachable. >>> >>> Regards, >>> Kirk >>> >>> >>> On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote: >>> >>> >>>> Hi Everyone, >>>> >>>> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>>> >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.0/. >>>>> >>>>> Summary: >>>>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*> files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants. >>>>> >>>>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>>> >>> >>> >> > From fancyerii at gmail.com Tue Dec 13 03:29:48 2011 From: fancyerii at gmail.com (Li Li) Date: Tue, 13 Dec 2011 11:29:48 +0800 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: <4EE62C41.1010209@icubic.de> References: <4EE62841.4070907@oracle.com> <4EE62C41.1010209@icubic.de> Message-ID: is there a method called System.fullGC()? I know there is a System.gc() which is a hint that JVM should perform gc but JVM can ignore this. On Tue, Dec 13, 2011 at 12:30 AM, Ralf Helbing wrote: > Why don't you set up a timer that > > // Tells the dispatcher to leave me alone > System.fullGC(); > // Tells the dispatcher that I am back > > every now and then? > > cheeers, > Ralf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fancyerii at gmail.com Tue Dec 13 03:38:33 2011 From: fancyerii at gmail.com (Li Li) Date: Tue, 13 Dec 2011 11:38:33 +0800 Subject: Fwd: how to know jvm is stopping the world? In-Reply-To: References: Message-ID: yes, this is not a perfect solution, but it can alleviate this painful thing. e.g. our application receives 10 request per second, it means every 100 ms a request. and the stop the world is 500ms if we don't monitor the status of jvm, when jvm stop the world, 5 requests are not processed. but if we send request before consulting the jvm, then only one request are blocked. of course there are extreme situation that the 5 requests comes at the same time and jvm tells them I am not stop the world, but when requests come, it stops the world. but comparing with these two solutions. asking then sending is a better one. On Mon, Dec 12, 2011 at 9:57 PM, Vitaly Davidovich wrote: > But suppose you had this feature and the VM tells you that it's not doing > (or doesn't have any pending) full gc. Your load balancer then sends the > request to that server - what happens if the processing of this request > triggers a full gc? I just don't think there's a comprehensive solution > here since you'd still run the risk of having a STW pause amidst request > processing. > > As for jmx notifications on heap usage it's still just a guess in terms of > what that actually means - the gc that follows may be concurrent (not STW) > or there may not be a gc at all if the mem allocations aren't high enough. > > I agree with Krystal that it makes most sense in tuning the GC + checking > your own code to make sure it plays well with the GC algorithm that you're > using (I.e. CMS). > On Dec 11, 2011 10:56 PM, "Li Li" wrote: > >> >> ---------- Forwarded message ---------- >> From: Krystal Mok >> Date: Sun, Dec 11, 2011 at 5:53 PM >> Subject: Re: how to know jvm is stopping the world? >> To: Li Li >> >> >> HI, >> >> You're probably looking in the wrong direction. When the JVM >> "stops-the-world", it stops the world -- all Java threads (or "mutators") >> are suspended. There's no way for you to execute any Java code during that >> period. >> HotSpot VM uses a "safepoint" mechanism to stop-the-world. You can get >> safepoint stats with -XX:+PrintSafepointStatistics. >> >> There's an alternative that might help. Try GC notification with JMX [1]. >> Setup a notification threshold, and when the heap usage crosses the >> threshold, you'll get a notification. Put the load balancing logic in the >> callback. Even though this is different from "a notification of >> stop-the-world pause", it might work for you. >> >> There's a GC notification mechanism in .NET that might have been closer >> to what you wanted [2]. >> >> - Kris >> >> [1]: >> http://docs.oracle.com/javase/6/docs/api/java/lang/management/MemoryMXBean.html >> [2]: http://msdn.microsoft.com/en-us/library/cc713687.aspx >> >> On Sun, Dec 11, 2011 at 2:31 PM, Li Li wrote: >> >>> hi, >>> In our application of full text searching with lucene and solr. we >>> will give jvm about 25GB memory. we use CMS as old generation garbage >>> collector. But the jvm sometimes can't do anything. So our clients complain >>> that the connection is time out. we find the reason is the jvm is doing >>> full gc and it will stop service for about 1-3 seconds. >>> I know that this situation is inevitable when using CMS collector. >>> but we have more than one searching machines, so if I know jvm is doing >>> full gc(specially stop the world), I can send requests to other machines. >>> But the question now is that jvm don't provide an api for that. I think >>> it's not very difficult(for guys developing hotspot, but is in deed >>> difficult for me ). So I want your help. >>> The first question is where is the position of CMS full gc. >>> from http://blogs.oracle.com/jonthecollector/entry/did_you_know >>> there are many steps: >>> 1. STW initial mark >>> 2. Concurrent marking >>> 3. Concurrent precleaning >>> 4. STW remark >>> 5. Concurrent sweeping >>> 6. Concurrent reset >>> there are 2 stop the world stages. I want to know the line number(or >>> functions) of this stages. so I can tell java program that jvm now is doing >>> full gc. >>> The second is that how to communicate between jvm and java program? >>> My expected thing is like : >>> //java program >>> if(System.isStopTheWolrd()){ >>> //system is busy, tell the dispatch node that don't send >>> request to me >>> }else{ >>> do service; >>> } >>> I have no experience in jvm developing. jvm is implemented in c and >>> jni is the interface between them. is there any other method that jvm can >>> achieve this? obviously, it can extend System class and add a static method >>> named isStopTheWorld(). Could some one tell me how to do this in details? >>> Thank you very much. >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fancyerii at gmail.com Tue Dec 13 03:40:40 2011 From: fancyerii at gmail.com (Li Li) Date: Tue, 13 Dec 2011 11:40:40 +0800 Subject: how to know jvm is stopping the world? In-Reply-To: <4EE61874.2090203@oracle.com> References: <4EE61874.2090203@oracle.com> Message-ID: That's what I want. btw, this feature is only available in sun jdk7? does it exist in openjdk7? On Mon, Dec 12, 2011 at 11:06 PM, Stefan Karlsson < stefan.karlsson at oracle.com> wrote: > On 12/11/2011 07:31 AM, Li Li wrote: > >> hi, >> In our application of full text searching with lucene and solr. we >> will give jvm about 25GB memory. we use CMS as old generation garbage >> collector. But the jvm sometimes can't do anything. So our clients complain >> that the connection is time out. we find the reason is the jvm is doing >> full gc and it will stop service for about 1-3 seconds. >> I know that this situation is inevitable when using CMS collector. but >> we have more than one searching machines, so if I know jvm is doing full >> gc(specially stop the world), I can send requests to other machines. But >> the question now is that jvm don't provide an api for that. I think it's >> not very difficult(for guys developing hotspot, but is in deed difficult >> for me ). So I want your help. >> The first question is where is the position of CMS full gc. >> from http://blogs.oracle.com/**jonthecollector/entry/did_you_**know >> there are many steps: >> 1. STW initial mark >> 2. Concurrent marking >> 3. Concurrent precleaning >> 4. STW remark >> 5. Concurrent sweeping >> 6. Concurrent reset >> there are 2 stop the world stages. I want to know the line number(or >> functions) of this stages. so I can tell java program that jvm now is doing >> full gc. >> The second is that how to communicate between jvm and java program? >> My expected thing is like : >> //java program >> if(System.isStopTheWolrd()){ >> //system is busy, tell the dispatch node that don't send >> request to me >> }else{ >> do service; >> } >> I have no experience in jvm developing. jvm is implemented in c and >> jni is the interface between them. is there any other method that jvm can >> achieve this? obviously, it can extend System class and add a static method >> named isStopTheWorld(). Could some one tell me how to do this in details? >> Thank you very much. >> > > You could probably use JVMTI. See: http://docs.oracle.com/javase/** > 7/docs/platform/jvmti/jvmti.**html#GarbageCollectionStart > > StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rednaxelafx at gmail.com Tue Dec 13 03:51:43 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 13 Dec 2011 11:51:43 +0800 Subject: how to know jvm is stopping the world? In-Reply-To: References: <4EE61874.2090203@oracle.com> Message-ID: The GC start/end events in JVMTI are available since a long time ago. You can use it in JDK 6 right now. [1] And in OpenJDK 7, too. The problem (for you) is this interface does not allow you to execute any Java code in the event callback. You'll need make some non-Java interface in your dispatcher so that this notification can ultimately propagate from the JVM in full GC to your dispatcher. - Kris [1]: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionStart On Tue, Dec 13, 2011 at 11:40 AM, Li Li wrote: > That's what I want. > btw, this feature is only available in sun jdk7? > does it exist in openjdk7? > > > On Mon, Dec 12, 2011 at 11:06 PM, Stefan Karlsson < > stefan.karlsson at oracle.com> wrote: > >> On 12/11/2011 07:31 AM, Li Li wrote: >> >>> hi, >>> In our application of full text searching with lucene and solr. we >>> will give jvm about 25GB memory. we use CMS as old generation garbage >>> collector. But the jvm sometimes can't do anything. So our clients complain >>> that the connection is time out. we find the reason is the jvm is doing >>> full gc and it will stop service for about 1-3 seconds. >>> I know that this situation is inevitable when using CMS collector. >>> but we have more than one searching machines, so if I know jvm is doing >>> full gc(specially stop the world), I can send requests to other machines. >>> But the question now is that jvm don't provide an api for that. I think >>> it's not very difficult(for guys developing hotspot, but is in deed >>> difficult for me ). So I want your help. >>> The first question is where is the position of CMS full gc. >>> from http://blogs.oracle.com/**jonthecollector/entry/did_you_**know >>> there are many steps: >>> 1. STW initial mark >>> 2. Concurrent marking >>> 3. Concurrent precleaning >>> 4. STW remark >>> 5. Concurrent sweeping >>> 6. Concurrent reset >>> there are 2 stop the world stages. I want to know the line number(or >>> functions) of this stages. so I can tell java program that jvm now is doing >>> full gc. >>> The second is that how to communicate between jvm and java program? >>> My expected thing is like : >>> //java program >>> if(System.isStopTheWolrd()){ >>> //system is busy, tell the dispatch node that don't send >>> request to me >>> }else{ >>> do service; >>> } >>> I have no experience in jvm developing. jvm is implemented in c and >>> jni is the interface between them. is there any other method that jvm can >>> achieve this? obviously, it can extend System class and add a static method >>> named isStopTheWorld(). Could some one tell me how to do this in details? >>> Thank you very much. >>> >> >> You could probably use JVMTI. See: http://docs.oracle.com/javase/** >> 7/docs/platform/jvmti/jvmti.**html#GarbageCollectionStart >> >> StefanK >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 13 05:28:44 2011 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2011 15:28:44 +1000 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE65EDA.80300@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> Message-ID: <4EE6E28C.6080501@oracle.com> On 13/12/2011 6:06 AM, John Cuthbertson wrote: > Thanks for looking at the code changes and for the suggestions. > > Extending the os API is a good idea. Not sure about the name though - > how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp > already has an internal monotonic version of javaTimeMillis() so there > are alternatives to using javaTimeNanos() in the implementation. I'm somewhat opposed to extending the API simply because there are already too many time functions. What about a TO_MILLIS macro? #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC jlong start = TO_MILLIS(javaTimeNanos()); BTW the "java" in javaTimeMillis and javaTimeNanos identifies these methods as being part of the Java API (System.currentTimeMillis and System.nanoTime respectively) - so javaMonotonicTimeMillis would not be appropriate. John: you have a recurrent typo in the comments: monton instead of monoton (and I mistyped it myself writing that!) > Thanks for the heads up about the other CR. I'll check. See 4741166. It wanted to make javaTimeMillis monotonic, which it can not be. Pretty much all internal uses of javaTimeMillis (those not part of implementing System.currentTimeMillis()) should really be using a monotonic time source. David ----- > Thanks, > > JohnC > > On 12/11/11 01:32, Srinivas Ramakrishna wrote: >> Hi John -- Looks fine. Two minor comments: >> >> (1) by defining an os::javaTimeNanosInMillis() you may be able to >> consolidate the divide by NANOS_IN_MILLISEC to one place instead of it >> appearing at each use. >> (2) you might consolidate the commentary about monotonicity into >> os::javaTimeNanosInMillis(), then at each client simly say "Protect >> against possible nonmonotonicity" >> >> That will reduce the number of repeated lines while still providing >> all of the commentary in all the relevant places. (By the way, you >> might want to >> check if there;s another CR with the same content which might be >> closed as a dup of this... just a very vague recollection.) >> >> reviewed. >> -- ramki (opendjk: ysr) >> >> On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson >> > wrote: >> >> Hi Everyone, >> >> I have updated the comments based upon feedback from David Holmes. >> A new webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.1/ >> >> >> Thanks, >> >> JohnC >> >> >> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >> >> Hi Everyone, >> >> Can I have a couple of volunteers review the changes for this >> CR? The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7117303/webrev.0/ >> . >> >> Summary: >> I replaced the calls to os::javaTimeMillis() in the GC where >> we expect monotonicity with calls os::javaTimeNanos(), >> converting the result to milliseconds. os::javaTimeNanos(), at >> least on some configurations, does guarantee monotonicity and >> so is a better alternative. The changes in the os_<*> files >> are to make use of the named conversion constants I >> added/moved to globalDefinitions.hpp - we seemed to have >> multiple names for the same two constants. >> >> Testing: GC test suite on solaris and Linux, NSK tests on >> solaris, and jprt. >> >> Thanks, >> >> JohnC >> >> > From ysr1729 at gmail.com Tue Dec 13 06:40:24 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 12 Dec 2011 22:40:24 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE6E28C.6080501@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> <4EE6E28C.6080501@oracle.com> Message-ID: Hi David -- On Mon, Dec 12, 2011 at 9:28 PM, David Holmes wrote: > On 13/12/2011 6:06 AM, John Cuthbertson wrote: > >> Thanks for looking at the code changes and for the suggestions. >> >> Extending the os API is a good idea. Not sure about the name though - >> how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp >> already has an internal monotonic version of javaTimeMillis() so there >> are alternatives to using javaTimeNanos() in the implementation. >> > > I'm somewhat opposed to extending the API simply because there are already > too many time functions. What about a TO_MILLIS macro? > > #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC > > jlong start = TO_MILLIS(javaTimeNanos()); > While the macro reduces the # characters, that was not the intent of my suggestion... > > BTW the "java" in javaTimeMillis and javaTimeNanos identifies these > methods as being part of the Java API (System.currentTimeMillis and > System.nanoTime respectively) - so javaMonotonicTimeMillis would not be > appropriate. > Then, how about os::monotonicTimeMillis() defined as an inline method in os:: ? One of the reasons for wanting the consolidation into one place was also so that the commentary would be in one place, including the part about monotonicity only if and when the underlying platform guarantees it, which isn't true today on all the supported platforms. Anyway, do whatever makes sense wrt proper naming and reducing duplication, clutter or confusion as the case may be... thanks. -- ramki > > John: you have a recurrent typo in the comments: monton instead of monoton > (and I mistyped it myself writing that!) > > > Thanks for the heads up about the other CR. I'll check. >> > > See 4741166. It wanted to make javaTimeMillis monotonic, which it can not > be. Pretty much all internal uses of javaTimeMillis (those not part of > implementing System.currentTimeMillis()) should really be using a monotonic > time source. > > David > ----- > > Thanks, >> >> JohnC >> >> On 12/11/11 01:32, Srinivas Ramakrishna wrote: >> >>> Hi John -- Looks fine. Two minor comments: >>> >>> (1) by defining an os::javaTimeNanosInMillis() you may be able to >>> consolidate the divide by NANOS_IN_MILLISEC to one place instead of it >>> appearing at each use. >>> (2) you might consolidate the commentary about monotonicity into >>> os::javaTimeNanosInMillis(), then at each client simly say "Protect >>> against possible nonmonotonicity" >>> >>> That will reduce the number of repeated lines while still providing >>> all of the commentary in all the relevant places. (By the way, you >>> might want to >>> check if there;s another CR with the same content which might be >>> closed as a dup of this... just a very vague recollection.) >>> >>> reviewed. >>> -- ramki (opendjk: ysr) >>> >>> On Fri, Dec 9, 2011 at 11:30 AM, John Cuthbertson >>> >> >>> wrote: >>> >>> Hi Everyone, >>> >>> I have updated the comments based upon feedback from David Holmes. >>> A new webrev can be found at: >>> http://cr.openjdk.java.net/~**johnc/7117303/webrev.1/ >>> >>> > >>> >>> >>> Thanks, >>> >>> JohnC >>> >>> >>> On 12/7/2011 9:59 AM, John Cuthbertson wrote: >>> >>> Hi Everyone, >>> >>> Can I have a couple of volunteers review the changes for this >>> CR? The webrev can be found at: >>> http://cr.openjdk.java.net/~**johnc/7117303/webrev.0/ >>> >>> >. >>> >>> >>> Summary: >>> I replaced the calls to os::javaTimeMillis() in the GC where >>> we expect monotonicity with calls os::javaTimeNanos(), >>> converting the result to milliseconds. os::javaTimeNanos(), at >>> least on some configurations, does guarantee monotonicity and >>> so is a better alternative. The changes in the os_<*> files >>> are to make use of the named conversion constants I >>> added/moved to globalDefinitions.hpp - we seemed to have >>> multiple names for the same two constants. >>> >>> Testing: GC test suite on solaris and Linux, NSK tests on >>> solaris, and jprt. >>> >>> Thanks, >>> >>> JohnC >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fancyerii at gmail.com Tue Dec 13 07:10:50 2011 From: fancyerii at gmail.com (Li Li) Date: Tue, 13 Dec 2011 15:10:50 +0800 Subject: how to know jvm is stopping the world? In-Reply-To: References: <4EE61874.2090203@oracle.com> Message-ID: thanks. is there any resources about writing tools communicating with JVM using JVMTI? On Tue, Dec 13, 2011 at 11:51 AM, Krystal Mok wrote: > The GC start/end events in JVMTI are available since a long time ago. You > can use it in JDK 6 right now. [1] And in OpenJDK 7, too. > > The problem (for you) is this interface does not allow you to execute any > Java code in the event callback. You'll need make some non-Java interface > in your dispatcher so that this notification can ultimately propagate from > the JVM in full GC to your dispatcher. > > - Kris > > [1]: > http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionStart > > On Tue, Dec 13, 2011 at 11:40 AM, Li Li wrote: > >> That's what I want. >> btw, this feature is only available in sun jdk7? >> does it exist in openjdk7? >> >> >> On Mon, Dec 12, 2011 at 11:06 PM, Stefan Karlsson < >> stefan.karlsson at oracle.com> wrote: >> >>> On 12/11/2011 07:31 AM, Li Li wrote: >>> >>>> hi, >>>> In our application of full text searching with lucene and solr. we >>>> will give jvm about 25GB memory. we use CMS as old generation garbage >>>> collector. But the jvm sometimes can't do anything. So our clients complain >>>> that the connection is time out. we find the reason is the jvm is doing >>>> full gc and it will stop service for about 1-3 seconds. >>>> I know that this situation is inevitable when using CMS collector. >>>> but we have more than one searching machines, so if I know jvm is doing >>>> full gc(specially stop the world), I can send requests to other machines. >>>> But the question now is that jvm don't provide an api for that. I think >>>> it's not very difficult(for guys developing hotspot, but is in deed >>>> difficult for me ). So I want your help. >>>> The first question is where is the position of CMS full gc. >>>> from http://blogs.oracle.com/**jonthecollector/entry/did_you_**know >>>> there are many steps: >>>> 1. STW initial mark >>>> 2. Concurrent marking >>>> 3. Concurrent precleaning >>>> 4. STW remark >>>> 5. Concurrent sweeping >>>> 6. Concurrent reset >>>> there are 2 stop the world stages. I want to know the line number(or >>>> functions) of this stages. so I can tell java program that jvm now is doing >>>> full gc. >>>> The second is that how to communicate between jvm and java program? >>>> My expected thing is like : >>>> //java program >>>> if(System.isStopTheWolrd()){ >>>> //system is busy, tell the dispatch node that don't send >>>> request to me >>>> }else{ >>>> do service; >>>> } >>>> I have no experience in jvm developing. jvm is implemented in c and >>>> jni is the interface between them. is there any other method that jvm can >>>> achieve this? obviously, it can extend System class and add a static method >>>> named isStopTheWorld(). Could some one tell me how to do this in details? >>>> Thank you very much. >>>> >>> >>> You could probably use JVMTI. See: http://docs.oracle.com/javase/** >>> 7/docs/platform/jvmti/jvmti.**html#GarbageCollectionStart >>> >>> StefanK >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Tue Dec 13 12:38:45 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 13 Dec 2011 13:38:45 +0100 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE25EFE.9090902@oracle.com> References: <4EE25EFE.9090902@oracle.com> Message-ID: <4EE74755.5050408@oracle.com> Hi John, First a high level question: I think your changes are correct, but this got a bit more complex than I thought it would be when I suggested it in the review of 7112743. Is the extra complexity worth the benefits of only having to do the iterations once instead of twice? I don't have a clear answer to this myself, I just wanted to bring the question up. Clearly it is more efficient, but it is 3x as much code to do the same thing. One detail for my understanding: why do we need separate time stamps for each worker? Do all worker not participate in RSet scanning before they go on to do complete_marking_in_collection_set() ? Bengt On 2011-12-09 20:18, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ > > Summary: > As part of the code review comments for 7112743 (G1: Reduce overhead > of marking closure during evacuation pauses) it was suggested that > instead of recalculating the starting heap region for each worker > thread, we reuse the values calculated during RSet scanning. These > changes address that review comment. In these changes I maintain a > cache that is used and updated by > G1CollectedHeap::start_cset_region_for_worker(). The first time this > routine is called by a worker thread during an evacuation pause > (currently during RSet scanning) the cached value for the worker gets > set; when the routine is called subsequently the region that was > cached for the worker is returned. I employ a simple stamp mechanism > based upon the number of GCs that ensures the validity of the regions > in the cache and makes clearing the cache unnecessary. > > Testing: > GC Test suite with a small marking threshold (10%) with and without > verification; the configuration of SPECjbb used to test 7117423; > Kitchensink. > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Tue Dec 13 16:00:47 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 13 Dec 2011 11:00:47 -0500 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE74755.5050408@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> Message-ID: <4EE776AF.3090308@oracle.com> Bengt Rutisson wrote: > > Hi John, > > First a high level question: I think your changes are correct, but > this got a bit more complex than I thought it would be when I > suggested it in the review of 7112743. Is the extra complexity worth > the benefits of only having to do the iterations once instead of twice? (Small correction: once instead of three times). The thought had also crossed my mind. Maybe on some machines with not great single-threaded performance it will be worth it. > I don't have a clear answer to this myself, I just wanted to bring the > question up. Clearly it is more efficient, but it is 3x as much code > to do the same thing. > > One detail for my understanding: why do we need separate time stamps > for each worker? Each worker independently needs to know whether its starting region is valid or not. If John didn't have a timestamp per worker, he'd need to reset the table at the start or end of each GC. Tony > Do all worker not participate in RSet scanning before they go on to do > complete_marking_in_collection_set() ? > > Bengt > > > On 2011-12-09 20:18, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the changes for this CR? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ >> >> Summary: >> As part of the code review comments for 7112743 (G1: Reduce overhead >> of marking closure during evacuation pauses) it was suggested that >> instead of recalculating the starting heap region for each worker >> thread, we reuse the values calculated during RSet scanning. These >> changes address that review comment. In these changes I maintain a >> cache that is used and updated by >> G1CollectedHeap::start_cset_region_for_worker(). The first time this >> routine is called by a worker thread during an evacuation pause >> (currently during RSet scanning) the cached value for the worker gets >> set; when the routine is called subsequently the region that was >> cached for the worker is returned. I employ a simple stamp mechanism >> based upon the number of GCs that ensures the validity of the regions >> in the cache and makes clearing the cache unnecessary. >> >> Testing: >> GC Test suite with a small marking threshold (10%) with and without >> verification; the configuration of SPECjbb used to test 7117423; >> Kitchensink. >> >> Thanks, >> >> JohnC >> > From kirk at kodewerk.com Tue Dec 13 17:45:07 2011 From: kirk at kodewerk.com (Charles K Pepperdine) Date: Tue, 13 Dec 2011 18:45:07 +0100 Subject: how to know jvm is stopping the world? In-Reply-To: References: <4EE61874.2090203@oracle.com> Message-ID: Hi, Sorry but this thread looks like a train wreak about to happen with everyone shouting.. FASTER... FASTER..... FASTER!!!! :-) First a call to System.gc() will *always* result in a Full GC being executed. The call to System.gc() is synchronized which means that is multiple threads call it, the will be blocked waiting for the previous call complete. Second, hooking things up to the JVMPI can result in a much slower runtime, it can alter/prevent future optimizations. IMHO, what is really needed here is an understanding of *why* your applications transactional rates are so slow and *why* you're having difficulties with GC. IME, many of the problems you describe are more easily addressable with memory tuning. This goes beyond just a technical tuning of the JVM. It will involve analyzing how your application uses (and in this case abuses) memory. Try object creation statistics via NetBeans memory profiler.. or if you like to spend money to get the same information, get a copy of YourKit (a great tool that does do a wee bit more than NB profiler). Worst you could do it force a heap dump (jmap) on your production machine and do a census of what's in it. Finally, technical tuning requires that you look at GC logs. I collect GC logs as a hobby so if you happen to produce one from your production system (negligible performance penalty to turn on gc logging) send it along and I'm happy to take a look let you know what I see. Kind regards, Kirk Pepperdine On Dec 13, 2011, at 8:10 AM, Li Li wrote: > thanks. > is there any resources about writing tools communicating with JVM using JVMTI? > > On Tue, Dec 13, 2011 at 11:51 AM, Krystal Mok wrote: > The GC start/end events in JVMTI are available since a long time ago. You can use it in JDK 6 right now. [1] And in OpenJDK 7, too. > > The problem (for you) is this interface does not allow you to execute any Java code in the event callback. You'll need make some non-Java interface in your dispatcher so that this notification can ultimately propagate from the JVM in full GC to your dispatcher. > > - Kris > > [1]: http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionStart > > On Tue, Dec 13, 2011 at 11:40 AM, Li Li wrote: > That's what I want. > btw, this feature is only available in sun jdk7? > does it exist in openjdk7? > > > On Mon, Dec 12, 2011 at 11:06 PM, Stefan Karlsson wrote: > On 12/11/2011 07:31 AM, Li Li wrote: > hi, > In our application of full text searching with lucene and solr. we will give jvm about 25GB memory. we use CMS as old generation garbage collector. But the jvm sometimes can't do anything. So our clients complain that the connection is time out. we find the reason is the jvm is doing full gc and it will stop service for about 1-3 seconds. > I know that this situation is inevitable when using CMS collector. but we have more than one searching machines, so if I know jvm is doing full gc(specially stop the world), I can send requests to other machines. But the question now is that jvm don't provide an api for that. I think it's not very difficult(for guys developing hotspot, but is in deed difficult for me ). So I want your help. > The first question is where is the position of CMS full gc. > from http://blogs.oracle.com/jonthecollector/entry/did_you_know > there are many steps: > 1. STW initial mark > 2. Concurrent marking > 3. Concurrent precleaning > 4. STW remark > 5. Concurrent sweeping > 6. Concurrent reset > there are 2 stop the world stages. I want to know the line number(or functions) of this stages. so I can tell java program that jvm now is doing full gc. > The second is that how to communicate between jvm and java program? My expected thing is like : > //java program > if(System.isStopTheWolrd()){ > //system is busy, tell the dispatch node that don't send request to me > }else{ > do service; > } > I have no experience in jvm developing. jvm is implemented in c and jni is the interface between them. is there any other method that jvm can achieve this? obviously, it can extend System class and add a static method named isStopTheWorld(). Could some one tell me how to do this in details? Thank you very much. > > You could probably use JVMTI. See: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#GarbageCollectionStart > > StefanK > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue Dec 13 18:31:59 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 13 Dec 2011 10:31:59 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE776AF.3090308@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> <4EE776AF.3090308@oracle.com> Message-ID: <4EE79A1F.7010104@oracle.com> Hi Bengt, Tony First of all - Bengt, thanks for looking over the changes. On 12/13/11 08:00, Tony Printezis wrote: > Bengt Rutisson wrote: >> >> Hi John, >> >> First a high level question: I think your changes are correct, but >> this got a bit more complex than I thought it would be when I >> suggested it in the review of 7112743. Is the extra complexity worth >> the benefits of only having to do the iterations once instead of twice? > > (Small correction: once instead of three times). The thought had also > crossed my mind. Maybe on some machines with not great single-threaded > performance it will be worth it. I don't think the extra complexity is *that* complex - it is after all just a simple cache with not too much overhead. Keeping it self contained was the reason why I wanted to do this as a separate RFE. Part of the motivation for this code, as Tony points out we may see more benefit on HW with slow single thread performance. Also, as we discussed earlier, a single threaded walk of the collection set to pre-calculate the starting heap regions is out as that will penalize all threads - especially on certain HW. The other motivation was that we may have more and more parallel iterations of the collection set in future (for example the removal of self forwarding pointers) and with each additional iteration we add, the complexity 'cost' decreases. >> One detail for my understanding: why do we need separate time stamps >> for each worker? > Each worker independently needs to know whether its starting region is > valid or not. If John didn't have a timestamp per worker, he'd need to > reset the table at the start or end of each GC. As Tony points out - an individual TS per worker is needed to avoid clearing the array containing the starting regions during evacuation pauses. >> Do all worker not participate in RSet scanning before they go on to >> do complete_marking_in_collection_set() ? Currently yes. But that may not always be the case and expanding the code to handle differing numbers of threads should be straight forward. Regards, JohnC From john.cuthbertson at oracle.com Tue Dec 13 18:39:48 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 13 Dec 2011 10:39:48 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE25EFE.9090902@oracle.com> References: <4EE25EFE.9090902@oracle.com> Message-ID: <4EE79BF4.2040809@oracle.com> Hi Everyone, I have a new webrev based upon comments from Tony, which can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.1/ Changes in this version include: * Using the value of the existing G1CollectedHeap::_gc_time_stamp field, rather than the value of _total_collections, as the TS values. * A small optimization that may reduce the number of iterations while walking the collection set to calculate the starting region for a worker. We check the entry for the previous worker and if that is valid then we starting iterating over the collection set from that region. Testing: GC test suite; jprt. Thanks, JohnC On 12/09/11 11:18, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers to review the changes for this CR? > The webrev can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ > > Summary: > As part of the code review comments for 7112743 (G1: Reduce overhead > of marking closure during evacuation pauses) it was suggested that > instead of recalculating the starting heap region for each worker > thread, we reuse the values calculated during RSet scanning. These > changes address that review comment. In these changes I maintain a > cache that is used and updated by > G1CollectedHeap::start_cset_region_for_worker(). The first time this > routine is called by a worker thread during an evacuation pause > (currently during RSet scanning) the cached value for the worker gets > set; when the routine is called subsequently the region that was > cached for the worker is returned. I employ a simple stamp mechanism > based upon the number of GCs that ensures the validity of the regions > in the cache and makes clearing the cache unnecessary. > > Testing: > GC Test suite with a small marking threshold (10%) with and without > verification; the configuration of SPECjbb used to test 7117423; > Kitchensink. > > Thanks, > > JohnC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.cuthbertson at oracle.com Tue Dec 13 18:54:34 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 13 Dec 2011 10:54:34 -0800 Subject: RFR(S): 7120038: G1: ParallelGCThreads==0 is broken Message-ID: <4EE79F6A.2020309@oracle.com> Hi Everyone, While testing the changes for 7119908 I discovered that running G1 with ParallelGCThreads=0 is broken. Can I have a couple of volunteers look over the changes fix the issues I discovered? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7120038/webrev.0/. Most of the changes are correcting unguarded references to the work gang (which is not created when PGCT==0) and a few assertion failures. Note: we do have an open RFE to remove code specific to PGCT==0 as it is not a typical configuration, but until then... Testing: GC test suite with/without -XX:ParallelGCThreads=0, Kitchensink, jprt. Thanks, JohnC From john.cuthbertson at oracle.com Tue Dec 13 19:41:27 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 13 Dec 2011 11:41:27 -0800 Subject: RFR(S): 7120038: G1: ParallelGCThreads==0 is broken In-Reply-To: <4EE7A397.90902@oracle.com> References: <4EE79F6A.2020309@oracle.com> <4EE7A397.90902@oracle.com> Message-ID: <4EE7AA67.3020507@oracle.com> Hi Vladimir, The JVM currently allows the flag. When specified, the VM thread (only) executes the GC code during STW GCs - including code that would normally be executed by the parallel worker threads. This is slightly different from when -XX:ParallelGCThreads=1- which creates a single GC worker thread; this single worker executes the parallel code. I have found that specifying PGCT=0 has been useful during bug triaging. JohnC On 12/13/11 11:12, Vladimir Ivanov wrote: > John, > > Can you elaborate what is the use case for ParallelGCThreads==0? > Why don't we simply abort execution during startup when > -XX:ParallelGCThreads=0 is passed on command line? > > Best regards, > Vladimir Ivanov > > On 12/13/11 21:54, John Cuthbertson wrote: > >> Hi Everyone, >> >> While testing the changes for 7119908 I discovered that running G1 with >> ParallelGCThreads=0 is broken. Can I have a couple of volunteers look >> over the changes fix the issues I discovered? The webrev can be found >> at: http://cr.openjdk.java.net/~johnc/7120038/webrev.0/. >> >> Most of the changes are correcting unguarded references to the work gang >> (which is not created when PGCT==0) and a few assertion failures. >> >> Note: we do have an open RFE to remove code specific to PGCT==0 as it is >> not a typical configuration, but until then... >> >> Testing: GC test suite with/without -XX:ParallelGCThreads=0, >> Kitchensink, jprt. >> >> Thanks, >> >> JohnC >> >> From stefan.karlsson at oracle.com Wed Dec 14 12:03:06 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 14 Dec 2011 13:03:06 +0100 Subject: Review request (S): 7121373: Clean up CollectedHeap::is_in Message-ID: <4EE8907A.80002@oracle.com> http://cr.openjdk.java.net/~stefank/7121373/webrev.00 This change: 1) Fixes an assert in G1CollectedHeap::is_in when pointers below the heap was passed in as arguments. 2) Updates the comments to more correctly reflect how is_in is actually used/implemented. 3) Makes Space::is_in pure virtual, since the default implementation is never used. 4) Includes a unit test for CollectedHeap::is_in StefanK From ysr1729 at gmail.com Wed Dec 14 20:11:51 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 14 Dec 2011 12:11:51 -0800 Subject: how to know jvm is stopping the world? In-Reply-To: References: <4EE61874.2090203@oracle.com> Message-ID: I agree. However, a quick remark in case one of your remarks below is misunderstood .... On Tue, Dec 13, 2011 at 9:45 AM, Charles K Pepperdine wrote: > Hi, > > Sorry but this thread looks like a train wreak about to happen with > everyone shouting.. FASTER... FASTER..... FASTER!!!! :-) > > First a call to System.gc() will *always* result in a Full GC being > executed. > Right about that. However, that GC need not be fully stop-world. E.g. with the concurrent collectors and -XX:+ExplicitGCInvokesConcurrent the call will kick off a concurrent GC cycle. The caller will return when the concurrent cycle completes. -- ramki The call to System.gc() is synchronized which means that is multiple > threads call it, the will be blocked waiting for the previous call complete. > Second, hooking things up to the JVMPI can result in a much slower > runtime, it can alter/prevent future optimizations. > > IMHO, what is really needed here is an understanding of *why* your > applications transactional rates are so slow and *why* you're having > difficulties with GC. IME, many of the problems you describe are more > easily addressable with memory tuning. This goes beyond just a technical > tuning of the JVM. It will involve analyzing how your application uses (and > in this case abuses) memory. Try object creation statistics via NetBeans > memory profiler.. or if you like to spend money to get the same > information, get a copy of YourKit (a great tool that does do a wee bit > more than NB profiler). Worst you could do it force a heap dump (jmap) on > your production machine and do a census of what's in it. > > Finally, technical tuning requires that you look at GC logs. I collect GC > logs as a hobby so if you happen to produce one from your production system > (negligible performance penalty to turn on gc logging) send it along and > I'm happy to take a look let you know what I see. > > Kind regards, > Kirk Pepperdine > > > On Dec 13, 2011, at 8:10 AM, Li Li wrote: > > thanks. > is there any resources about writing tools communicating with JVM using > JVMTI? > > On Tue, Dec 13, 2011 at 11:51 AM, Krystal Mok wrote: > >> The GC start/end events in JVMTI are available since a long time ago. You >> can use it in JDK 6 right now. [1] And in OpenJDK 7, too. >> >> The problem (for you) is this interface does not allow you to execute any >> Java code in the event callback. You'll need make some non-Java interface >> in your dispatcher so that this notification can ultimately propagate from >> the JVM in full GC to your dispatcher. >> >> - Kris >> >> [1]: >> http://docs.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#GarbageCollectionStart >> >> On Tue, Dec 13, 2011 at 11:40 AM, Li Li wrote: >> >>> That's what I want. >>> btw, this feature is only available in sun jdk7? >>> does it exist in openjdk7? >>> >>> >>> On Mon, Dec 12, 2011 at 11:06 PM, Stefan Karlsson < >>> stefan.karlsson at oracle.com> wrote: >>> >>>> On 12/11/2011 07:31 AM, Li Li wrote: >>>> >>>>> hi, >>>>> In our application of full text searching with lucene and solr. we >>>>> will give jvm about 25GB memory. we use CMS as old generation garbage >>>>> collector. But the jvm sometimes can't do anything. So our clients complain >>>>> that the connection is time out. we find the reason is the jvm is doing >>>>> full gc and it will stop service for about 1-3 seconds. >>>>> I know that this situation is inevitable when using CMS collector. >>>>> but we have more than one searching machines, so if I know jvm is doing >>>>> full gc(specially stop the world), I can send requests to other machines. >>>>> But the question now is that jvm don't provide an api for that. I think >>>>> it's not very difficult(for guys developing hotspot, but is in deed >>>>> difficult for me ). So I want your help. >>>>> The first question is where is the position of CMS full gc. >>>>> from http://blogs.oracle.com/**jonthecollector/entry/did_you_**know >>>>> there are many steps: >>>>> 1. STW initial mark >>>>> 2. Concurrent marking >>>>> 3. Concurrent precleaning >>>>> 4. STW remark >>>>> 5. Concurrent sweeping >>>>> 6. Concurrent reset >>>>> there are 2 stop the world stages. I want to know the line >>>>> number(or functions) of this stages. so I can tell java program that jvm >>>>> now is doing full gc. >>>>> The second is that how to communicate between jvm and java >>>>> program? My expected thing is like : >>>>> //java program >>>>> if(System.isStopTheWolrd()){ >>>>> //system is busy, tell the dispatch node that don't send >>>>> request to me >>>>> }else{ >>>>> do service; >>>>> } >>>>> I have no experience in jvm developing. jvm is implemented in c >>>>> and jni is the interface between them. is there any other method that jvm >>>>> can achieve this? obviously, it can extend System class and add a static >>>>> method named isStopTheWorld(). Could some one tell me how to do this in >>>>> details? Thank you very much. >>>>> >>>> >>>> You could probably use JVMTI. See: http://docs.oracle.com/javase/** >>>> 7/docs/platform/jvmti/jvmti.**html#GarbageCollectionStart >>>> >>>> StefanK >>>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Wed Dec 14 22:17:47 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 14 Dec 2011 17:17:47 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array Message-ID: <4EE9208B.5040203@oracle.com> Hi all, Can I have a couple of code review for this small change? http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ The CR has a bit more explanation. The short version is that I'm now encoding the "start index of the next chunk" in the from-space length field of a chunked array (say *that* quickly!) as a negative value to always be able to distinguish it from the real length. This will simplify the code for the CR John is currently working on (6484965) but it's a small, self-contained change so it's good to get it code reviewed and pushed separately. Tony From john.cuthbertson at oracle.com Wed Dec 14 22:23:09 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 14 Dec 2011 14:23:09 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE79BF4.2040809@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE79BF4.2040809@oracle.com> Message-ID: <4EE921CD.1010301@oracle.com> Hi Everyone, Based upon some further comments from Tony, I have another new webrev for this change. It can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.2/ Changes in this version include: * some minor name changes * the code that calculates the starting region was using total_workers() when it should have been using active_workers() * minor tweaks to the start and end index values to get a slightly better distribution. Testing: GC test suite Thanks, JohnC On 12/13/11 10:39, John Cuthbertson wrote: > Hi Everyone, > > I have a new webrev based upon comments from Tony, which can be found > at: http://cr.openjdk.java.net/~johnc/7119908/webrev.1/ > > Changes in this version include: > > * Using the value of the existing G1CollectedHeap::_gc_time_stamp > field, rather than the value of _total_collections, as the TS values. > * A small optimization that may reduce the number of iterations while > walking the collection set to calculate the starting region for a > worker. We check the entry for the previous worker and if that is > valid then we starting iterating over the collection set from that region. > > Testing: > GC test suite; jprt. > > Thanks, > > JohnC > > On 12/09/11 11:18, John Cuthbertson wrote: >> Hi Everyone, >> >> Can I have a couple of volunteers to review the changes for this CR? >> The webrev can be found at: >> http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ >> >> Summary: >> As part of the code review comments for 7112743 (G1: Reduce overhead >> of marking closure during evacuation pauses) it was suggested that >> instead of recalculating the starting heap region for each worker >> thread, we reuse the values calculated during RSet scanning. These >> changes address that review comment. In these changes I maintain a >> cache that is used and updated by >> G1CollectedHeap::start_cset_region_for_worker(). The first time this >> routine is called by a worker thread during an evacuation pause >> (currently during RSet scanning) the cached value for the worker gets >> set; when the routine is called subsequently the region that was >> cached for the worker is returned. I employ a simple stamp mechanism >> based upon the number of GCs that ensures the validity of the regions >> in the cache and makes clearing the cache unnecessary. >> >> Testing: >> GC Test suite with a small marking threshold (10%) with and without >> verification; the configuration of SPECjbb used to test 7117423; >> Kitchensink. >> >> Thanks, >> >> JohnC >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Dec 15 08:13:37 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 09:13:37 +0100 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE921CD.1010301@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE79BF4.2040809@oracle.com> <4EE921CD.1010301@oracle.com> Message-ID: <4EE9AC31.9090408@oracle.com> John, Looks good to me. One minor thing. I think the two asserts on lines 2710 and 2711 are unnecessary. They will never fail. 2709 HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int worker_i) { 2710 assert(_worker_cset_start_region != NULL, "sanity"); 2711 assert(_worker_cset_start_region_time_stamp != NULL, "sanity"); In the constructor for G1CollectedHeap you set the arrays up using NEW_C_HEAP_ARRAY. If that fails to allocate memory it will call vm_exit_out_of_memory(). So, you should never get to start_cset_region_for_worker() with the arrays being NULL. Bengt On 2011-12-14 23:23, John Cuthbertson wrote: > Hi Everyone, > > Based upon some further comments from Tony, I have another new webrev > for this change. It can be found at: > http://cr.openjdk.java.net/~johnc/7119908/webrev.2/ > > Changes in this version include: > > * some minor name changes > * the code that calculates the starting region was using > total_workers() when it should have been using active_workers() > * minor tweaks to the start and end index values to get a slightly > better distribution. > > Testing: > GC test suite > > Thanks, > > JohnC > > On 12/13/11 10:39, John Cuthbertson wrote: >> Hi Everyone, >> >> I have a new webrev based upon comments from Tony, which can be found >> at: http://cr.openjdk.java.net/~johnc/7119908/webrev.1/ >> >> Changes in this version include: >> >> * Using the value of the existing G1CollectedHeap::_gc_time_stamp >> field, rather than the value of _total_collections, as the TS values. >> * A small optimization that may reduce the number of iterations while >> walking the collection set to calculate the starting region for a >> worker. We check the entry for the previous worker and if that is >> valid then we starting iterating over the collection set from that >> region. >> >> Testing: >> GC test suite; jprt. >> >> Thanks, >> >> JohnC >> >> On 12/09/11 11:18, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> Can I have a couple of volunteers to review the changes for this CR? >>> The webrev can be found at: >>> http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ >>> >>> Summary: >>> As part of the code review comments for 7112743 (G1: Reduce overhead >>> of marking closure during evacuation pauses) it was suggested that >>> instead of recalculating the starting heap region for each worker >>> thread, we reuse the values calculated during RSet scanning. These >>> changes address that review comment. In these changes I maintain a >>> cache that is used and updated by >>> G1CollectedHeap::start_cset_region_for_worker(). The first time this >>> routine is called by a worker thread during an evacuation pause >>> (currently during RSet scanning) the cached value for the worker >>> gets set; when the routine is called subsequently the region that >>> was cached for the worker is returned. I employ a simple stamp >>> mechanism based upon the number of GCs that ensures the validity of >>> the regions in the cache and makes clearing the cache unnecessary. >>> >>> Testing: >>> GC Test suite with a small marking threshold (10%) with and without >>> verification; the configuration of SPECjbb used to test 7117423; >>> Kitchensink. >>> >>> Thanks, >>> >>> JohnC >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Thu Dec 15 08:24:21 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 09:24:21 +0100 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE79A1F.7010104@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> <4EE776AF.3090308@oracle.com> <4EE79A1F.7010104@oracle.com> Message-ID: <4EE9AEB5.9050904@oracle.com> John and Tony, Thanks for the explanations about the need for individual timestamps for the worker threads. A followup question below to make sure that I understand this correctly. > As Tony points out - an individual TS per worker is needed to avoid > clearing the array containing the starting regions during evacuation > pauses. > >>> Do all worker not participate in RSet scanning before they go on to >>> do complete_marking_in_collection_set() ? > > Currently yes. But that may not always be the case and expanding the > code to handle differing numbers of threads should be straight forward. So, in the current implementation it would be possible to change the interface for start_cset_region_for_worker() to be something like: HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int worker_i, bool use_cached_values) RSet scanning would pass use_cached_values=false, while the other uses would pass use_cached_values =true. And instead of looking at the timestamp to decide if we can trust the cached values we would look at use_cached_values. If use_cached_values == false we would not use the cached values, but when we have calculated a new value we would update the cache. Would that work? I am not saying it is a better alternative, I just want to make sure I understand the code paths here. (Of course with this approach you would not be able to do the latest optimization that you implemented - to look for the previous thread's cached value to see if you can use that as a starting point.) Bengt From bengt.rutisson at oracle.com Thu Dec 15 08:47:23 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 09:47:23 +0100 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: <4EE13466.6030603@oracle.com> References: <4EE13466.6030603@oracle.com> Message-ID: <4EE9B41B.3010508@oracle.com> Hi Tony, Sorry for the late review. I looks good to me. One minor thing: g1CollectorPolicy.hpp: Several lines in the range 373-432 (new version) has indentation that looks strange to me. For example line 375 here: 373 size_t predict_young_card_num(size_t rs_length) { 374 return (size_t) ((double) rs_length * 375 predict_young_cards_per_entry_ratio()); 376 } Other than that - Ship it! Bengt On 2011-12-08 23:04, Tony Printezis wrote: > Hi all, > > Could I have a couple of volunteers to look at this change? > > http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ > > We decided that the terms "fully-young" and "partially-young" GCs were > awkward so we are renaming them to "young" and "mixed". This change > not only changes the external G1 output that uses these terms (i.e., > GC log and GC ergonomic decision log) but also renames all the > occurrences of those terms in the code itself (fields, methods, > comments, etc.). Initially, I was not going to do the latter but it > turned out that the changes were not too many. So it's good to make > the code consistent with our current terminology. > > These are the most common fields / methods that I renamed: > > _full_young_gcs -> _gcs_are_young > full_young_gcs() -> gcs_are_young() > set_full_young_gcs() -> set_gcs_are_young() > _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs > _last_full_young_gc -> _last_young_gc > _last_young_gc_full -> _last_gc_was_young > > The changeset also includes some very minor code cleanup (mainly > introduction of curly brackets in if-else statements). > > Tony > From stefan.karlsson at oracle.com Thu Dec 15 13:19:03 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Thu, 15 Dec 2011 13:19:03 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7121373: Clean up CollectedHeap::is_in Message-ID: <20111215131909.2D340476D4@hg.openjdk.java.net> Changeset: 3c648b9ad052 Author: stefank Date: 2011-12-14 12:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3c648b9ad052 7121373: Clean up CollectedHeap::is_in Summary: Fixed G1CollectedHeap::is_in, added tests, cleaned up comments and made Space::is_in pure virtual. Reviewed-by: brutisso, tonyp, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/utilities/quickSort.cpp ! src/share/vm/utilities/quickSort.hpp From tony.printezis at oracle.com Thu Dec 15 15:25:00 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 15 Dec 2011 10:25:00 -0500 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: <4EE9B41B.3010508@oracle.com> References: <4EE13466.6030603@oracle.com> <4EE9B41B.3010508@oracle.com> Message-ID: <4EEA114C.8050308@oracle.com> Bengt, Thanks for looking at it! There were some long lines there and I was not sure how to best breakthem. Do you like this version better? http://cr.openjdk.java.net/~tonyp/7113012/webrev.1/ Tony Bengt Rutisson wrote: > > Hi Tony, > > Sorry for the late review. I looks good to me. > > One minor thing: > > g1CollectorPolicy.hpp: > Several lines in the range 373-432 (new version) has indentation that > looks strange to me. For example line 375 here: > > 373 size_t predict_young_card_num(size_t rs_length) { > 374 return (size_t) ((double) rs_length * > 375 > predict_young_cards_per_entry_ratio()); > 376 } > > Other than that - Ship it! > > Bengt > > On 2011-12-08 23:04, Tony Printezis wrote: >> Hi all, >> >> Could I have a couple of volunteers to look at this change? >> >> http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ >> >> We decided that the terms "fully-young" and "partially-young" GCs >> were awkward so we are renaming them to "young" and "mixed". This >> change not only changes the external G1 output that uses these terms >> (i.e., GC log and GC ergonomic decision log) but also renames all the >> occurrences of those terms in the code itself (fields, methods, >> comments, etc.). Initially, I was not going to do the latter but it >> turned out that the changes were not too many. So it's good to make >> the code consistent with our current terminology. >> >> These are the most common fields / methods that I renamed: >> >> _full_young_gcs -> _gcs_are_young >> full_young_gcs() -> gcs_are_young() >> set_full_young_gcs() -> set_gcs_are_young() >> _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs >> _last_full_young_gc -> _last_young_gc >> _last_young_gc_full -> _last_gc_was_young >> >> The changeset also includes some very minor code cleanup (mainly >> introduction of curly brackets in if-else statements). >> >> Tony >> > From john.cuthbertson at oracle.com Thu Dec 15 17:50:51 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 15 Dec 2011 09:50:51 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE9AEB5.9050904@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> <4EE776AF.3090308@oracle.com> <4EE79A1F.7010104@oracle.com> <4EE9AEB5.9050904@oracle.com> Message-ID: <4EEA337B.5030904@oracle.com> Hi Bengt, On 12/15/11 00:24, Bengt Rutisson wrote: > > So, in the current implementation it would be possible to change the > interface for start_cset_region_for_worker() to be something like: > > HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int > worker_i, bool use_cached_values) > > RSet scanning would pass use_cached_values=false, while the other uses > would pass use_cached_values =true. And instead of looking at the > timestamp to decide if we can trust the cached values we would look at > use_cached_values. If use_cached_values == false we would not use the > cached values, but when we have calculated a new value we would update > the cache. Would that work? I am not saying it is a better > alternative, I just want to make sure I understand the code paths here. > > (Of course with this approach you would not be able to do the latest > optimization that you implemented - to look for the previous thread's > cached value to see if you can use that as a starting point.) > > Bengt Changing the interface to use a "trusted" flag would have worked and you would not have needed to the per-worker time stamp. I initially thought about something similar (and much simpler) i.e. assuming that the entries would be valid post-RSet scanning. I did not, however, want to introduce a hard dependency between distinct phases of the pause. With the the "trusted" flag, the dependency is mostly eliminated (you could always pass false), but that defeats the purpose of caching the starting values. Also, as programmer, you would need to cognizant about when to trust the entries and when not to. Get it wrong (i.e. pass true before the entries can actually be trusted) and disaster will ensue. Unless you reduce the risk and take it out of the programmer's hands by using a global "trusted" flag which itself is set to "not-trust" at the start or end of the pause. As you said, though, we lose a little bit of flexibility. Regards, JohnC From john.cuthbertson at oracle.com Thu Dec 15 17:55:21 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 15 Dec 2011 09:55:21 -0800 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE9AC31.9090408@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE79BF4.2040809@oracle.com> <4EE921CD.1010301@oracle.com> <4EE9AC31.9090408@oracle.com> Message-ID: <4EEA3489.6030205@oracle.com> Hi Bengt, I was just being a little bit paranoid. Since the jprt job of the push failed - I'll remove them. Thanks, JohnC On 12/15/11 00:13, Bengt Rutisson wrote: > > John, > > Looks good to me. > > One minor thing. I think the two asserts on lines 2710 and 2711 are > unnecessary. They will never fail. > > 2709 HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int > worker_i) { > 2710 assert(_worker_cset_start_region != NULL, "sanity"); > 2711 assert(_worker_cset_start_region_time_stamp != NULL, "sanity"); > > In the constructor for G1CollectedHeap you set the arrays up using > NEW_C_HEAP_ARRAY. If that fails to allocate memory it will call > vm_exit_out_of_memory(). So, you should never get to > start_cset_region_for_worker() with the arrays being NULL. > > Bengt > > > On 2011-12-14 23:23, John Cuthbertson wrote: >> Hi Everyone, >> >> Based upon some further comments from Tony, I have another new webrev >> for this change. It can be found at: >> http://cr.openjdk.java.net/~johnc/7119908/webrev.2/ >> >> Changes in this version include: >> >> * some minor name changes >> * the code that calculates the starting region was using >> total_workers() when it should have been using active_workers() >> * minor tweaks to the start and end index values to get a slightly >> better distribution. >> >> Testing: >> GC test suite >> >> Thanks, >> >> JohnC >> >> On 12/13/11 10:39, John Cuthbertson wrote: >>> Hi Everyone, >>> >>> I have a new webrev based upon comments from Tony, which can be >>> found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.1/ >>> >>> Changes in this version include: >>> >>> * Using the value of the existing G1CollectedHeap::_gc_time_stamp >>> field, rather than the value of _total_collections, as the TS values. >>> * A small optimization that may reduce the number of iterations >>> while walking the collection set to calculate the starting region >>> for a worker. We check the entry for the previous worker and if that >>> is valid then we starting iterating over the collection set from >>> that region. >>> >>> Testing: >>> GC test suite; jprt. >>> >>> Thanks, >>> >>> JohnC >>> >>> On 12/09/11 11:18, John Cuthbertson wrote: >>>> Hi Everyone, >>>> >>>> Can I have a couple of volunteers to review the changes for this >>>> CR? The webrev can be found at: >>>> http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ >>>> >>>> Summary: >>>> As part of the code review comments for 7112743 (G1: Reduce >>>> overhead of marking closure during evacuation pauses) it was >>>> suggested that instead of recalculating the starting heap region >>>> for each worker thread, we reuse the values calculated during RSet >>>> scanning. These changes address that review comment. In these >>>> changes I maintain a cache that is used and updated by >>>> G1CollectedHeap::start_cset_region_for_worker(). The first time >>>> this routine is called by a worker thread during an evacuation >>>> pause (currently during RSet scanning) the cached value for the >>>> worker gets set; when the routine is called subsequently the region >>>> that was cached for the worker is returned. I employ a simple stamp >>>> mechanism based upon the number of GCs that ensures the validity of >>>> the regions in the cache and makes clearing the cache unnecessary. >>>> >>>> Testing: >>>> GC Test suite with a small marking threshold (10%) with and without >>>> verification; the configuration of SPECjbb used to test 7117423; >>>> Kitchensink. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Thu Dec 15 17:59:18 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 15 Dec 2011 12:59:18 -0500 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EE9AEB5.9050904@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> <4EE776AF.3090308@oracle.com> <4EE79A1F.7010104@oracle.com> <4EE9AEB5.9050904@oracle.com> Message-ID: <4EEA3576.1060409@oracle.com> Bengt, Your idea will definitely work. To add to what John said in his follow-up e-mail: it would have been easy to validate the use of the use_cached_value parameter by NULLing the per-worker entries between GCs in non-product builds. So, if use_cached_value == true, entry is NULL, and CSet head is not NULL, you know the use_cached_value is wrong. But, I like John's approach. It's a bit more flexible and more easily re-usable. Tony Bengt Rutisson wrote: > > John and Tony, > > Thanks for the explanations about the need for individual timestamps > for the worker threads. A followup question below to make sure that I > understand this correctly. > >> As Tony points out - an individual TS per worker is needed to avoid >> clearing the array containing the starting regions during evacuation >> pauses. >> >>>> Do all worker not participate in RSet scanning before they go on to >>>> do complete_marking_in_collection_set() ? >> >> Currently yes. But that may not always be the case and expanding the >> code to handle differing numbers of threads should be straight forward. > > So, in the current implementation it would be possible to change the > interface for start_cset_region_for_worker() to be something like: > > HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int > worker_i, bool use_cached_values) > > RSet scanning would pass use_cached_values=false, while the other uses > would pass use_cached_values =true. And instead of looking at the > timestamp to decide if we can trust the cached values we would look at > use_cached_values. If use_cached_values == false we would not use the > cached values, but when we have calculated a new value we would update > the cache. Would that work? I am not saying it is a better > alternative, I just want to make sure I understand the code paths here. > > (Of course with this approach you would not be able to do the latest > optimization that you implemented - to look for the previous thread's > cached value to see if you can use that as a starting point.) > > Bengt From john.cuthbertson at oracle.com Thu Dec 15 18:21:22 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 15 Dec 2011 10:21:22 -0800 Subject: RFR(S): 7120038: G1: ParallelGCThreads==0 is broken In-Reply-To: <4EE79F6A.2020309@oracle.com> References: <4EE79F6A.2020309@oracle.com> Message-ID: <4EEA3AA2.7070507@oracle.com> Hi Everyone, I have a new webrev of these changes based upon feedback from Tony Printezis and Jon Masamitsu. It can be found at: http://cr.openjdk.java.net/~johnc/7120038/webrev.1/ Changes in this version include: * Fixed a change in ConcurrentMark::calc_parallel_marking_threads() that effectively disabled using a dynamic number of threads. * Modified the cleaning of the card table (at the end of an evacuation pause) to use the current number of active worker threads. Testing: GC test suite. Thanks, JohnC On 12/13/11 10:54, John Cuthbertson wrote: > Hi Everyone, > > While testing the changes for 7119908 I discovered that running G1 > with ParallelGCThreads=0 is broken. Can I have a couple of volunteers > look over the changes fix the issues I discovered? The webrev can be > found at: http://cr.openjdk.java.net/~johnc/7120038/webrev.0/. > > Most of the changes are correcting unguarded references to the work > gang (which is not created when PGCT==0) and a few assertion failures. > > Note: we do have an open RFE to remove code specific to PGCT==0 as it > is not a typical configuration, but until then... > > Testing: GC test suite with/without -XX:ParallelGCThreads=0, > Kitchensink, jprt. > > Thanks, > > JohnC > From john.cuthbertson at oracle.com Thu Dec 15 18:44:59 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Thu, 15 Dec 2011 10:44:59 -0800 Subject: RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic In-Reply-To: <4EE6E28C.6080501@oracle.com> References: <4EDFA96C.9020007@oracle.com> <4EE261DD.9020806@oracle.com> <4EE65EDA.80300@oracle.com> <4EE6E28C.6080501@oracle.com> Message-ID: <4EEA402B.7030002@oracle.com> Hi David, On 12/12/11 21:28, David Holmes wrote: > On 13/12/2011 6:06 AM, John Cuthbertson wrote: >> Thanks for looking at the code changes and for the suggestions. >> >> Extending the os API is a good idea. Not sure about the name though - >> how about: javaMonotonicTimeMillis? Also I believe os_solaris.cpp >> already has an internal monotonic version of javaTimeMillis() so there >> are alternatives to using javaTimeNanos() in the implementation. > > I'm somewhat opposed to extending the API simply because there are > already too many time functions. What about a TO_MILLIS macro? > > #define TO_MILLIS(nanos) ((nanos)/NANOS_PER_MILLISEC > > jlong start = TO_MILLIS(javaTimeNanos()); I'm not a fan of this approach - to me it's just hiding the division and is really no different from the posted webrev. I'd rather go with what's in the webrev. > > BTW the "java" in javaTimeMillis and javaTimeNanos identifies these > methods as being part of the Java API (System.currentTimeMillis and > System.nanoTime respectively) - so javaMonotonicTimeMillis would not > be appropriate. I see. Thanks for the heads up. No java in the routine name (if it's decided that's the best approach). > > John: you have a recurrent typo in the comments: monton instead of > monoton (and I mistyped it myself writing that!) OK. Thanks. I correct those. > >> Thanks for the heads up about the other CR. I'll check. > > See 4741166. It wanted to make javaTimeMillis monotonic, which it can > not be. Pretty much all internal uses of javaTimeMillis (those not > part of implementing System.currentTimeMillis()) should really be > using a monotonic time source. To achieve that goal - I think an additional routine might be needed (say clockTimeMillis_monotonic) but I think a significant portion of the calls to javaTimeMillis is outside the scope of this CR. Unless there's any objection - I'll go with the posted webrev. Thanks, JohnC From bengt.rutisson at oracle.com Thu Dec 15 21:55:45 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 22:55:45 +0100 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: <4EEA114C.8050308@oracle.com> References: <4EE13466.6030603@oracle.com> <4EE9B41B.3010508@oracle.com> <4EEA114C.8050308@oracle.com> Message-ID: Tony, Thanks for fixing the indentation. Looks good. Ship it! Bengt 15 dec 2011 kl. 16:25 skrev Tony Printezis : > Bengt, > > Thanks for looking at it! There were some long lines there and I was not sure how to best breakthem. Do you like this version better? > > http://cr.openjdk.java.net/~tonyp/7113012/webrev.1/ > > Tony > > Bengt Rutisson wrote: >> >> Hi Tony, >> >> Sorry for the late review. I looks good to me. >> >> One minor thing: >> >> g1CollectorPolicy.hpp: >> Several lines in the range 373-432 (new version) has indentation that looks strange to me. For example line 375 here: >> >> 373 size_t predict_young_card_num(size_t rs_length) { >> 374 return (size_t) ((double) rs_length * >> 375 predict_young_cards_per_entry_ratio()); >> 376 } >> >> Other than that - Ship it! >> >> Bengt >> >> On 2011-12-08 23:04, Tony Printezis wrote: >>> Hi all, >>> >>> Could I have a couple of volunteers to look at this change? >>> >>> http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ >>> >>> We decided that the terms "fully-young" and "partially-young" GCs were awkward so we are renaming them to "young" and "mixed". This change not only changes the external G1 output that uses these terms (i.e., GC log and GC ergonomic decision log) but also renames all the occurrences of those terms in the code itself (fields, methods, comments, etc.). Initially, I was not going to do the latter but it turned out that the changes were not too many. So it's good to make the code consistent with our current terminology. >>> >>> These are the most common fields / methods that I renamed: >>> >>> _full_young_gcs -> _gcs_are_young >>> full_young_gcs() -> gcs_are_young() >>> set_full_young_gcs() -> set_gcs_are_young() >>> _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs >>> _last_full_young_gc -> _last_young_gc >>> _last_young_gc_full -> _last_gc_was_young >>> >>> The changeset also includes some very minor code cleanup (mainly introduction of curly brackets in if-else statements). >>> >>> Tony >>> >> From bengt.rutisson at oracle.com Thu Dec 15 22:00:02 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 23:00:02 +0100 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EEA3489.6030205@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE79BF4.2040809@oracle.com> <4EE921CD.1010301@oracle.com> <4EE9AC31.9090408@oracle.com> <4EEA3489.6030205@oracle.com> Message-ID: John, Thanks for removing the asserts! Hope your push succeeds this time. You do know about the "-extratime 5m" workaround for the failure that you got, right? Bengt 15 dec 2011 kl. 18:55 skrev John Cuthbertson : > Hi Bengt, > > I was just being a little bit paranoid. Since the jprt job of the push failed - I'll remove them. > > Thanks, > > JohnC > > On 12/15/11 00:13, Bengt Rutisson wrote: >> >> >> John, >> >> Looks good to me. >> >> One minor thing. I think the two asserts on lines 2710 and 2711 are unnecessary. They will never fail. >> >> 2709 HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int worker_i) { >> 2710 assert(_worker_cset_start_region != NULL, "sanity"); >> 2711 assert(_worker_cset_start_region_time_stamp != NULL, "sanity"); >> >> In the constructor for G1CollectedHeap you set the arrays up using NEW_C_HEAP_ARRAY. If that fails to allocate memory it will call vm_exit_out_of_memory(). So, you should never get to start_cset_region_for_worker() with the arrays being NULL. >> >> Bengt >> >> >> On 2011-12-14 23:23, John Cuthbertson wrote: >>> >>> Hi Everyone, >>> >>> Based upon some further comments from Tony, I have another new webrev for this change. It can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.2/ >>> >>> Changes in this version include: >>> >>> * some minor name changes >>> * the code that calculates the starting region was using total_workers() when it should have been using active_workers() >>> * minor tweaks to the start and end index values to get a slightly better distribution. >>> >>> Testing: >>> GC test suite >>> >>> Thanks, >>> >>> JohnC >>> >>> On 12/13/11 10:39, John Cuthbertson wrote: >>>> >>>> Hi Everyone, >>>> >>>> I have a new webrev based upon comments from Tony, which can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.1/ >>>> >>>> Changes in this version include: >>>> >>>> * Using the value of the existing G1CollectedHeap::_gc_time_stamp field, rather than the value of _total_collections, as the TS values. >>>> * A small optimization that may reduce the number of iterations while walking the collection set to calculate the starting region for a worker. We check the entry for the previous worker and if that is valid then we starting iterating over the collection set from that region. >>>> >>>> Testing: >>>> GC test suite; jprt. >>>> >>>> Thanks, >>>> >>>> JohnC >>>> >>>> On 12/09/11 11:18, John Cuthbertson wrote: >>>>> >>>>> Hi Everyone, >>>>> >>>>> Can I have a couple of volunteers to review the changes for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7119908/webrev.0/ >>>>> >>>>> Summary: >>>>> As part of the code review comments for 7112743 (G1: Reduce overhead of marking closure during evacuation pauses) it was suggested that instead of recalculating the starting heap region for each worker thread, we reuse the values calculated during RSet scanning. These changes address that review comment. In these changes I maintain a cache that is used and updated by G1CollectedHeap::start_cset_region_for_worker(). The first time this routine is called by a worker thread during an evacuation pause (currently during RSet scanning) the cached value for the worker gets set; when the routine is called subsequently the region that was cached for the worker is returned. I employ a simple stamp mechanism based upon the number of GCs that ensures the validity of the regions in the cache and makes clearing the cache unnecessary. >>>>> >>>>> Testing: >>>>> GC Test suite with a small marking threshold (10%) with and without verification; the configuration of SPECjbb used to test 7117423; Kitchensink. >>>>> >>>>> Thanks, >>>>> >>>>> JohnC >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Thu Dec 15 21:58:05 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 15 Dec 2011 16:58:05 -0500 Subject: CRR (S): 7113012: G1: rename not-fully-young GCs as "mixed" In-Reply-To: References: <4EE13466.6030603@oracle.com> <4EE9B41B.3010508@oracle.com> <4EEA114C.8050308@oracle.com> Message-ID: <4EEA6D6D.2010206@oracle.com> Thanks Bengt, I'll push it asap. Tony Bengt Rutisson wrote: > Tony, > > Thanks for fixing the indentation. > > Looks good. Ship it! > > Bengt > > 15 dec 2011 kl. 16:25 skrev Tony Printezis : > > >> Bengt, >> >> Thanks for looking at it! There were some long lines there and I was not sure how to best breakthem. Do you like this version better? >> >> http://cr.openjdk.java.net/~tonyp/7113012/webrev.1/ >> >> Tony >> >> Bengt Rutisson wrote: >> >>> Hi Tony, >>> >>> Sorry for the late review. I looks good to me. >>> >>> One minor thing: >>> >>> g1CollectorPolicy.hpp: >>> Several lines in the range 373-432 (new version) has indentation that looks strange to me. For example line 375 here: >>> >>> 373 size_t predict_young_card_num(size_t rs_length) { >>> 374 return (size_t) ((double) rs_length * >>> 375 predict_young_cards_per_entry_ratio()); >>> 376 } >>> >>> Other than that - Ship it! >>> >>> Bengt >>> >>> On 2011-12-08 23:04, Tony Printezis wrote: >>> >>>> Hi all, >>>> >>>> Could I have a couple of volunteers to look at this change? >>>> >>>> http://cr.openjdk.java.net/~tonyp/7113012/webrev.0/ >>>> >>>> We decided that the terms "fully-young" and "partially-young" GCs were awkward so we are renaming them to "young" and "mixed". This change not only changes the external G1 output that uses these terms (i.e., GC log and GC ergonomic decision log) but also renames all the occurrences of those terms in the code itself (fields, methods, comments, etc.). Initially, I was not going to do the latter but it turned out that the changes were not too many. So it's good to make the code consistent with our current terminology. >>>> >>>> These are the most common fields / methods that I renamed: >>>> >>>> _full_young_gcs -> _gcs_are_young >>>> full_young_gcs() -> gcs_are_young() >>>> set_full_young_gcs() -> set_gcs_are_young() >>>> _should_revert_to_full_young_gcs -> _should_revert_to_young_gcs >>>> _last_full_young_gc -> _last_young_gc >>>> _last_young_gc_full -> _last_gc_was_young >>>> >>>> The changeset also includes some very minor code cleanup (mainly introduction of curly brackets in if-else statements). >>>> >>>> Tony >>>> >>>> From bengt.rutisson at oracle.com Thu Dec 15 22:05:01 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 15 Dec 2011 23:05:01 +0100 Subject: RFR(S): 7119908: G1: Cache CSet start region for each worker for subsequent reuse In-Reply-To: <4EEA337B.5030904@oracle.com> References: <4EE25EFE.9090902@oracle.com> <4EE74755.5050408@oracle.com> <4EE776AF.3090308@oracle.com> <4EE79A1F.7010104@oracle.com> <4EE9AEB5.9050904@oracle.com> <4EEA337B.5030904@oracle.com> Message-ID: John, Thanks for the explanation and for confirming my thoughts. I agree that your current solution is more robust for future code changes. Bengt 15 dec 2011 kl. 18:50 skrev John Cuthbertson : > Hi Bengt, > > On 12/15/11 00:24, Bengt Rutisson wrote: >> >> So, in the current implementation it would be possible to change the interface for start_cset_region_for_worker() to be something like: >> >> HeapRegion* G1CollectedHeap::start_cset_region_for_worker(int worker_i, bool use_cached_values) >> >> RSet scanning would pass use_cached_values=false, while the other uses would pass use_cached_values =true. And instead of looking at the timestamp to decide if we can trust the cached values we would look at use_cached_values. If use_cached_values == false we would not use the cached values, but when we have calculated a new value we would update the cache. Would that work? I am not saying it is a better alternative, I just want to make sure I understand the code paths here. >> >> (Of course with this approach you would not be able to do the latest optimization that you implemented - to look for the previous thread's cached value to see if you can use that as a starting point.) >> >> Bengt > > Changing the interface to use a "trusted" flag would have worked and you would not have needed to the per-worker time stamp. I initially thought about something similar (and much simpler) i.e. assuming that the entries would be valid post-RSet scanning. I did not, however, want to introduce a hard dependency between distinct phases of the pause. With the the "trusted" flag, the dependency is mostly eliminated (you could always pass false), but that defeats the purpose of caching the starting values. Also, as programmer, you would need to cognizant about when to trust the entries and when not to. Get it wrong (i.e. pass true before the entries can actually be trusted) and disaster will ensue. Unless you reduce the risk and take it out of the programmer's hands by using a global "trusted" flag which itself is set to "not-trust" at the start or end of the pause. As you said, though, we lose a little bit of flexibility. > > Regards, > > JohnC From john.coomes at oracle.com Fri Dec 16 04:53:52 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:53:52 +0000 Subject: hg: hsx/hotspot-gc: 3 new changesets Message-ID: <20111216045353.2E95D47709@hg.openjdk.java.net> Changeset: 8606f4ab62dc Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/8606f4ab62dc Added tag jdk8-b17 for changeset 4e06ae613e99 ! .hgtags Changeset: d82d3bb3a2e5 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/d82d3bb3a2e5 Added tag jdk8-b16 for changeset 4e06ae613e99 ! .hgtags Changeset: 7010bd24cdd0 Author: katleman Date: 2011-12-15 15:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/7010bd24cdd0 Merge ! .hgtags From john.coomes at oracle.com Fri Dec 16 04:54:06 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:54:06 +0000 Subject: hg: hsx/hotspot-gc/corba: 3 new changesets Message-ID: <20111216045411.738704770A@hg.openjdk.java.net> Changeset: 05f47d29b438 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/05f47d29b438 Added tag jdk8-b17 for changeset 82dc033975bb ! .hgtags Changeset: 6e51ad8d3707 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/6e51ad8d3707 Added tag jdk8-b16 for changeset 82dc033975bb ! .hgtags Changeset: 312cf15d1657 Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/312cf15d1657 Merge ! .hgtags From john.coomes at oracle.com Fri Dec 16 04:54:21 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:54:21 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 5 new changesets Message-ID: <20111216045421.B6E1C4770B@hg.openjdk.java.net> Changeset: e32444f13774 Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/e32444f13774 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 09eb517404b0 Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/09eb517404b0 Merge Changeset: db44484a9d6e Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/db44484a9d6e Added tag jdk8-b17 for changeset 09eb517404b0 ! .hgtags Changeset: bc3ed3122933 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/bc3ed3122933 Added tag jdk8-b16 for changeset 09eb517404b0 ! .hgtags Changeset: ebec6a7e8d4e Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/ebec6a7e8d4e Merge ! .hgtags From john.coomes at oracle.com Fri Dec 16 04:54:29 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:54:29 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 5 new changesets Message-ID: <20111216045429.5728D4770C@hg.openjdk.java.net> Changeset: 23c42f40fd3e Author: katleman Date: 2011-12-06 08:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/23c42f40fd3e 7117162: jdk8/jaxws/Makefile default DROPS_DIR should set to jdk8-drops Reviewed-by: ohair, xdono, mchung ! build.properties ! make/Makefile Changeset: 3d45ab79643d Author: katleman Date: 2011-12-07 13:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/3d45ab79643d Merge Changeset: b38846b9974c Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b38846b9974c Added tag jdk8-b17 for changeset 3d45ab79643d ! .hgtags Changeset: e662b652098c Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/e662b652098c Added tag jdk8-b16 for changeset 3d45ab79643d ! .hgtags Changeset: 54928c8850f5 Author: katleman Date: 2011-12-15 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/54928c8850f5 Merge ! .hgtags From john.coomes at oracle.com Fri Dec 16 04:55:47 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Dec 2011 04:55:47 +0000 Subject: hg: hsx/hotspot-gc/jdk: 64 new changesets Message-ID: <20111216051124.0F5AC47713@hg.openjdk.java.net> Changeset: 23acf34c80b0 Author: neugens Date: 2011-12-03 15:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/23acf34c80b0 7117914: Fix javac warnings in src/share/classes/sun/java2d Summary: Fix some javac warnings in java2d related code for the Warning Cleanup Day. Reviewed-by: prr, flar ! src/share/classes/java/awt/geom/Path2D.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/SurfaceDataProxy.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/java2d/opengl/OGLBufImgOps.java ! src/share/classes/sun/java2d/opengl/OGLDrawImage.java ! src/share/classes/sun/java2d/opengl/OGLPaints.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceData.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedRenderPipe.java ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/classes/sun/java2d/pipe/GlyphListPipe.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/solaris/classes/sun/java2d/x11/X11Renderer.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java Changeset: 70b40ea06df0 Author: prr Date: 2011-12-03 16:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/70b40ea06df0 7117199: Fix javac warnings in src/share/classes/java/awt/font Reviewed-by: jgodinez, bae ! src/share/classes/java/awt/font/StyledParagraph.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/font/TextLayout.java ! src/share/classes/java/awt/font/TextLine.java ! src/share/classes/java/awt/font/TextMeasurer.java Changeset: 4075d524fa46 Author: lana Date: 2011-12-06 16:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4075d524fa46 Merge Changeset: e53a078c2840 Author: anthony Date: 2011-11-09 13:43 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e53a078c2840 7045370: Java Statically Determines Display Size on Linux platforms Summary: Listen to ConfigureNotify events on the root window and update the current screen size accordingly Reviewed-by: art, bae ! src/share/classes/java/awt/Component.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 84e473cf4531 Author: rupashka Date: 2011-11-10 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/84e473cf4531 6938583: Unexpected NullPointerException by InputContext.endComposition() Reviewed-by: rupashka Contributed-by: Charles Lee ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/6938583/bug6938583.java Changeset: 81f1b32f9e24 Author: malenkov Date: 2011-11-10 17:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/81f1b32f9e24 7057459: Regression: Performance degradation with java.beans.XMLEncoder Reviewed-by: rupashka ! src/share/classes/java/beans/Encoder.java Changeset: e120c78cb45c Author: malenkov Date: 2011-11-10 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e120c78cb45c 7064279: Introspector.getBeanInfo() should release some resources in timely manner Reviewed-by: art, alexp ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyEditorManager.java + src/share/classes/java/beans/ThreadGroupContext.java ! test/java/beans/Beans/6669869/TestDesignTime.java ! test/java/beans/Beans/6669869/TestGuiAvailable.java ! test/java/beans/Introspector/6380849/TestBeanInfo.java + test/java/beans/Introspector/7064279/Test7064279.java + test/java/beans/Introspector/7064279/test.jar ! test/java/beans/Introspector/Test6660539.java ! test/java/beans/PropertyEditor/6380849/TestPropertyEditor.java Changeset: 8b6a69b2e482 Author: malenkov Date: 2011-11-10 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8b6a69b2e482 7087876: java/beans/PropertyDescriptor.html#createPropertyEditor() throws RE if editor cannot be created Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/PropertyEditor/Test7087876.java Changeset: b02495c51b9c Author: malenkov Date: 2011-11-10 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b02495c51b9c 7092744: XMLEncoder fails to encode and breaks backward compatibility Reviewed-by: rupashka ! src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ConstructorFinder.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java + test/java/beans/XMLEncoder/Test7092744.java Changeset: 16327765859c Author: malenkov Date: 2011-11-10 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/16327765859c 7087429: Constructor of java.beans.PropertyChangeEvent should declare thrown NPE for null source Reviewed-by: rupashka ! src/share/classes/java/beans/PropertyChangeEvent.java + test/java/beans/PropertyChangeSupport/Test7087429.java Changeset: f614bcada2a9 Author: anthony Date: 2011-11-11 15:17 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f614bcada2a9 7103610: _NET_WM_PID and WM_CLIENT_MACHINE are not set Summary: Set the properties to all top-level windows Reviewed-by: anthony Contributed-by: Danesh Dadachanji ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c0f3f1558a94 Author: rupashka Date: 2011-11-14 14:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c0f3f1558a94 7109617: Test was writed for Metal L&F but not set it Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/plaf/metal/MetalLookAndFeel/5073047/bug5073047.java Changeset: a51777c9228a Author: malenkov Date: 2011-11-14 14:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a51777c9228a 7110521: Regression test failed: Introspector/TestTypeResolver.java Reviewed-by: rupashka ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 28f768c41a90 Author: serb Date: 2011-11-12 04:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/28f768c41a90 6996291: command line selection of MToolkit by -Dawt.toolkit=sun.awt.motif.MToolkit fails from jdk7 b21 on Reviewed-by: art, dcherepanov, bae, prr ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/awt/mawt.gmk - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java - src/solaris/classes/sun/awt/motif/AWTLockAccess.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_AWTEvent.c ! src/solaris/native/sun/awt/awt_Component.h - src/solaris/native/sun/awt/awt_Cursor.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_Font.c ! src/solaris/native/sun/awt/awt_Font.h ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/awt/awt_InputMethod.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h ! src/solaris/native/sun/awt/awt_Robot.c - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h ! src/solaris/native/sun/awt/awt_p.h ! src/solaris/native/sun/awt/awt_util.c ! src/solaris/native/sun/awt/awt_util.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h ! src/solaris/native/sun/awt/canvas.h ! src/solaris/native/sun/awt/multi_font.c ! src/solaris/native/sun/awt/multi_font.h ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.h ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 6a9d735ebd0a Author: bagiras Date: 2011-11-16 15:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6a9d735ebd0a 7108598: Pogo Table Games freeze with JDK 7 Reviewed-by: art, ant ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java + test/java/awt/print/PaintSetEnabledDeadlock/PaintSetEnabledDeadlock.java Changeset: 1df53949945d Author: lana Date: 2011-11-18 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1df53949945d Merge Changeset: 90d33a64a404 Author: rupashka Date: 2011-11-21 18:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/90d33a64a404 7109085: Test use hotkeys not intended for Mac Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com ! test/javax/swing/regtesthelpers/Util.java + test/javax/swing/text/DefaultEditorKit/4278839/bug4278839.java + test/javax/swing/text/JTextComponent/5074573/bug5074573.java + test/javax/swing/text/html/HTMLEditorKit/5043626/bug5043626.java Changeset: c3c80f96cb83 Author: rupashka Date: 2011-11-25 11:52 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c3c80f96cb83 7113337: Swing closed test tries to click in the area reserved for resize by Mac OS X Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java Changeset: 9cbc208dcf08 Author: rupashka Date: 2011-11-29 12:47 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9cbc208dcf08 7112925: closed/javax/swing/JTabbedPane/4624207/bug4624207.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTabbedPane/4624207/bug4624207.java Changeset: 051beb804b12 Author: rupashka Date: 2011-11-30 16:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/051beb804b12 7110440: closed/javax/swing/JScrollBar/4865918/bug4865918.java fails on Aqua L&F Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JScrollBar/4865918/bug4865918.java Changeset: 7dd4395fe4a5 Author: rupashka Date: 2011-11-30 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7dd4395fe4a5 7115357: closed/javax/swing/JTable/6263446/bug6263446Table.java fails on MacOS Reviewed-by: rupashka Contributed-by: alexandr.scherbatiy at oracle.com + test/javax/swing/JTable/6263446/bug6263446.java Changeset: 4b416a0180dc Author: lana Date: 2011-11-29 15:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4b416a0180dc Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 45eb5a61da07 Author: lana Date: 2011-11-30 12:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/45eb5a61da07 Merge Changeset: 79b5c5a8c7e9 Author: serb Date: 2011-12-05 17:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/79b5c5a8c7e9 7115400: jdk 8 awt-gate build fails in headless toolkit on solaris. Reviewed-by: prr, art, bae ! make/sun/awt/FILES_c_unix.gmk + src/solaris/native/sun/awt/HeadlessToolkit.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h Changeset: 2b1438297561 Author: lana Date: 2011-12-06 16:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2b1438297561 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 387190e1f782 Author: chegar Date: 2011-11-25 10:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/387190e1f782 7115150: java.net.HttpCookie code cleanup, style, formatting, typos Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java Changeset: e5ecbf555679 Author: chegar Date: 2011-11-25 13:46 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e5ecbf555679 7115586: Suppress creation of SocketImpl in SocketAdaptor's constructor Reviewed-by: chegar, alanb Contributed-by: sajia at taobao.com ! src/share/classes/sun/nio/ch/SocketAdaptor.java Changeset: 022540b11147 Author: weijun Date: 2011-11-28 18:16 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/022540b11147 7115744: Do not call File::deleteOnExit in security tests Reviewed-by: xuelei ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java Changeset: d1928ae4e0a2 Author: xuelei Date: 2011-11-28 02:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d1928ae4e0a2 7115524: sun.security.provider.certpath.ssl.SSLServerCertStore no longer works Reviewed-by: weijun ! src/share/classes/sun/security/provider/certpath/ssl/SSLServerCertStore.java Changeset: 955aae8c1106 Author: ngmr Date: 2011-11-24 11:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/955aae8c1106 7115070: (fs) lookupPrincipalByName/lookupPrincipalByGroupName should treat ESRCH as not found Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 6fbd69f8e3ab Author: ngmr Date: 2011-11-18 09:03 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6fbd69f8e3ab 7094995: Trailing daemon thread causes continuous GC in agentvm mode Summary: Shutdown GcInducingThread once test (successfully) finishes Reviewed-by: alanb, chegar, dholmes, darcy Contributed-by: Neil Richards ! test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java Changeset: cf47846165f4 Author: dholmes Date: 2011-11-29 00:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cf47846165f4 7109092: Wrong computation results with double at armsflt Summary: need to link to custom soft-float library with required FP accuracy Reviewed-by: alanb, ohair ! make/common/Defs-embedded.gmk Changeset: a47de985fec9 Author: sherman Date: 2011-11-29 11:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a47de985fec9 7110149: Update the JDK8 bundled zlib library to the latest version 1.2.5 Summary: updated to zlib-1.2.5 Reviewed-by: alanb ! make/common/Defs.gmk ! make/java/zip/FILES_c.gmk ! make/sun/splashscreen/FILES_c.gmk - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h + src/share/native/java/util/zip/zlib-1.2.5/ChangeLog + src/share/native/java/util/zip/zlib-1.2.5/README + src/share/native/java/util/zip/zlib-1.2.5/compress.c + src/share/native/java/util/zip/zlib-1.2.5/crc32.h + src/share/native/java/util/zip/zlib-1.2.5/deflate.c + src/share/native/java/util/zip/zlib-1.2.5/deflate.h + src/share/native/java/util/zip/zlib-1.2.5/gzclose.c + src/share/native/java/util/zip/zlib-1.2.5/gzguts.h + src/share/native/java/util/zip/zlib-1.2.5/gzlib.c + src/share/native/java/util/zip/zlib-1.2.5/gzread.c + src/share/native/java/util/zip/zlib-1.2.5/gzwrite.c + src/share/native/java/util/zip/zlib-1.2.5/infback.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.c + src/share/native/java/util/zip/zlib-1.2.5/inffast.h + src/share/native/java/util/zip/zlib-1.2.5/inffixed.h + src/share/native/java/util/zip/zlib-1.2.5/inflate.c + src/share/native/java/util/zip/zlib-1.2.5/inflate.h + src/share/native/java/util/zip/zlib-1.2.5/inftrees.c + src/share/native/java/util/zip/zlib-1.2.5/inftrees.h + src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java + src/share/native/java/util/zip/zlib-1.2.5/trees.c + src/share/native/java/util/zip/zlib-1.2.5/trees.h + src/share/native/java/util/zip/zlib-1.2.5/uncompr.c + src/share/native/java/util/zip/zlib-1.2.5/zadler32.c + src/share/native/java/util/zip/zlib-1.2.5/zconf.h + src/share/native/java/util/zip/zlib-1.2.5/zcrc32.c + src/share/native/java/util/zip/zlib-1.2.5/zlib.h + src/share/native/java/util/zip/zlib-1.2.5/zutil.c + src/share/native/java/util/zip/zlib-1.2.5/zutil.h + test/java/util/zip/DeInflate.java Changeset: 07e359b01d8a Author: sherman Date: 2011-11-29 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/07e359b01d8a 7109837: Provide a mechanism for computing an Adler32 checksum for the contents of a ByteBuffer Summary: added methods Adler32/CRC32.update(ByteBuffer) Reviewed-by: alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c + test/java/util/zip/TimeChecksum.java Changeset: c5313d712ab0 Author: lana Date: 2011-11-29 12:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c5313d712ab0 Merge Changeset: a3edcdff37e1 Author: lana Date: 2011-11-29 13:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/a3edcdff37e1 Merge Changeset: 4749df4f04f1 Author: alanb Date: 2011-11-30 10:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4749df4f04f1 7030624: size_t usages in src/windows/native/java/io/io_util_md.c need to be re-visited Reviewed-by: lancea, chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h Changeset: 7795c41ed54c Author: alanb Date: 2011-11-30 12:42 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7795c41ed54c 7116404: Miscellaneous warnings (java.rmi.**, serialization, some core classes) Reviewed-by: lancea, chegar, smarks ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java Changeset: 43a630f11af6 Author: smarks Date: 2011-11-30 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/43a630f11af6 7116322: enhance javac make rule with a little bit of instrumentation Reviewed-by: dholmes, ohair ! make/common/Rules.gmk Changeset: 3b8186aee592 Author: chegar Date: 2011-12-01 11:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3b8186aee592 7116722: Miscellaneous warnings sun.misc ( and related classes ) Reviewed-by: alanb, darcy, forax, hawtin, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/Signal.java ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java Changeset: 89130611b178 Author: mcimadamore Date: 2011-12-01 18:34 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/89130611b178 7116954: Misc warnings in java.beans/java.beans.context Summary: Remove generic warnings form java.beans and java.beans.context Reviewed-by: alanb, chegar ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ChangeListenerMap.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/PropertyEditorSupport.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/SimpleBeanInfo.java ! src/share/classes/java/beans/Statement.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/XMLEncoder.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java Changeset: 0e3f706741ca Author: smarks Date: 2011-12-01 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/0e3f706741ca 7116890: additional warnings fixes for java.io Reviewed-by: alanb, smarks Contributed-by: Sebastian Sickelmann ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: b03da32c3186 Author: peytoia Date: 2011-12-02 16:09 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b03da32c3186 7056472: Speed up test/java/util/ResourceBundle/Control/ExpirationTest.sh Reviewed-by: okutsu - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: f615db07991e Author: chegar Date: 2011-12-02 11:39 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f615db07991e 7116946: JSSecurityManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: prr ! src/share/classes/com/sun/media/sound/JSSecurityManager.java Changeset: 37f6e294759f Author: chegar Date: 2011-12-02 14:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/37f6e294759f 7116957: javax.script.ScriptEngineManager should use java.util.ServiceLoader to lookup service providers Reviewed-by: alanb, lancea ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/net/ftp/FtpClientProvider.java Changeset: 9950e2c9f3b5 Author: alanb Date: 2011-12-02 17:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9950e2c9f3b5 7117357: Warnings in sun.instrument, tools and other sun.* classes Reviewed-by: lancea, chegar ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java ! src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/protocol/jar/Handler.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jps/Jps.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java Changeset: 42532a097816 Author: naoto Date: 2011-12-02 16:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/42532a097816 7117465: Warning cleanup for IMF classes Reviewed-by: okutsu ! src/share/classes/java/awt/im/InputMethodHighlight.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/awt/im/CompositionAreaHandler.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodContext.java ! src/share/classes/sun/awt/im/InputMethodJFrame.java ! src/share/classes/sun/awt/im/InputMethodManager.java ! src/share/classes/sun/awt/im/SimpleInputMethodWindow.java Changeset: 1d7037df65ed Author: sherman Date: 2011-12-02 16:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/1d7037df65ed 5035850: (str) String.CASE_INSENSITIVE_ORDER should override readResolve() Summary: Fix to ensure singleton property of String.CaseInsensitiveComparator is maintained through de/serialization. Reviewed-by: alanb, forax, smarks, dholmes Contributed-by: darryl.mocek at oracle.com ! src/share/classes/java/lang/String.java + test/java/lang/String/CaseInsensitiveComparator.java Changeset: 98502d7a3f98 Author: mchung Date: 2011-12-02 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/98502d7a3f98 7117585: Eliminate java.lang.instrument, java.lang.management warnings Reviewed-by: mchung Contributed-by: Jon VanAlten ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java Changeset: 3c524deb8431 Author: lancea Date: 2011-12-02 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3c524deb8431 7116445: Miscellaneous warnings in the JDBC/RowSet classes Reviewed-by: smarks, chegar ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/WebRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/share/classes/com/sun/rowset/internal/Row.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/sql/Timestamp.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: f2a5d0001f15 Author: okutsu Date: 2011-12-03 10:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f2a5d0001f15 7117487: Warnings Cleanup: some i18n classes in java.util and sun.util Reviewed-by: lancea, naoto ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/ResourceBundle.java ! src/share/classes/sun/util/calendar/BaseCalendar.java ! src/share/classes/sun/util/calendar/CalendarSystem.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNamesBundle.java Changeset: 2ae848ea980a Author: weijun Date: 2011-12-05 10:19 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/2ae848ea980a 7116857: Warnings in javax.security and some sun.misc Reviewed-by: smarks ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/FormattedFloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 053cb321467a Author: alanb Date: 2011-12-05 12:23 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/053cb321467a 7117717: (aio) Tests failing due to implementation bug 7052549 Reviewed-by: weijun, chegar ! test/ProblemList.txt ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java Changeset: da28826c5672 Author: alanb Date: 2011-12-05 12:24 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/da28826c5672 Merge Changeset: f352dd3cdff8 Author: dl Date: 2011-12-05 13:58 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f352dd3cdff8 7117360: Warnings in java.util.concurrent.atomic package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java Changeset: 194faa6fdb3c Author: sherman Date: 2011-12-05 10:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/194faa6fdb3c 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier() incorrect return value Summary: updated the incorrect StringBuilder constructor usage Reviewed-by: dholmes, sherman Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/util/Formatter.java + test/java/util/MissingFormatArgumentException/GetFormatSpecifier.java Changeset: ca383e32deaf Author: peytoia Date: 2011-12-06 08:39 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/ca383e32deaf 7116914: Miscellaneous warnings (sun.text) Reviewed-by: smarks, okutsu ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java Changeset: f4fe86bba8a2 Author: smarks Date: 2011-12-05 16:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f4fe86bba8a2 7116993: fix warnings in java.applet Reviewed-by: art, smarks Contributed-by: Danesh Dadachanji ! src/share/classes/java/applet/Applet.java Changeset: 85363edbc92f Author: naoto Date: 2011-12-05 17:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/85363edbc92f 7117469: Warning cleanup for j.u.Currency and j.u.Locale related classes Reviewed-by: okutsu, smarks ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java ! src/share/classes/sun/util/resources/LocaleData.java Changeset: 77f6d4360f4b Author: smarks Date: 2011-12-06 10:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77f6d4360f4b 7116997: fix warnings in java.util.PropertyPermission Reviewed-by: smarks Contributed-by: Brandon Passanisi ! src/share/classes/java/util/PropertyPermission.java Changeset: b71d1acfae52 Author: lana Date: 2011-12-06 20:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/b71d1acfae52 Merge ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/Encoder.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: cd95291bbbf3 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd95291bbbf3 Added tag jdk8-b17 for changeset b71d1acfae52 ! .hgtags Changeset: 8f3d916a9164 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/8f3d916a9164 Added tag jdk8-b16 for changeset 929597c6e777 ! .hgtags Changeset: e55ac966ed95 Author: katleman Date: 2011-12-15 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e55ac966ed95 Merge ! .hgtags - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh From john.cuthbertson at oracle.com Fri Dec 16 05:18:57 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Fri, 16 Dec 2011 05:18:57 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7119908: G1: Cache CSet start region for each worker for subsequent reuse Message-ID: <20111216051903.CA96C47715@hg.openjdk.java.net> Changeset: fd2b426c30db Author: johnc Date: 2011-12-14 17:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/fd2b426c30db 7119908: G1: Cache CSet start region for each worker for subsequent reuse Summary: Cache workers' calculated starting heap region, used for parallel iteration over the collcection set, for subsequent reuse. Reviewed-by: tonyp, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp From tony.printezis at oracle.com Fri Dec 16 12:44:19 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Fri, 16 Dec 2011 12:44:19 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7113012: G1: rename not-fully-young GCs as "mixed" Message-ID: <20111216124425.C9CD14772D@hg.openjdk.java.net> Changeset: 41406797186b Author: tonyp Date: 2011-12-16 02:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/41406797186b 7113012: G1: rename not-fully-young GCs as "mixed" Summary: Renamed partially-young GCs as mixed and fully-young GCs as young. Change all external output that includes those terms (GC log and GC ergo log) as well as any comments, fields, methods, etc. The changeset also includes very minor code tidying up (added some curly brackets). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.cpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.hpp From john.cuthbertson at oracle.com Sat Dec 17 05:53:05 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Sat, 17 Dec 2011 05:53:05 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7120038: G1: ParallelGCThreads==0 is broken Message-ID: <20111217055311.6BDC54774F@hg.openjdk.java.net> Changeset: adedfbbf0360 Author: johnc Date: 2011-12-16 11:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/adedfbbf0360 7120038: G1: ParallelGCThreads==0 is broken Summary: Running G1 with ParallelGCThreads==0 results in various crashes and asserts. Most of these are caused by unguarded references to the worker threads array or an incorrect number of active workers. Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From bengt.rutisson at oracle.com Mon Dec 19 12:48:27 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 19 Dec 2011 13:48:27 +0100 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Message-ID: <4EEF329B.1060005@oracle.com> Hi everyone, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ The idea is to give G1 some room to allow it to use its heuristics for calculating the young gen size even when the heap size is fixed. CR: 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx http://monaco.us.oracle.com/detail.jsf?cr=7113021 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 I introduce two new develop flags, G1DefaultMinNewGenPercent and G1DefaultMaxNewGenPercent. I will try to get the performance team to evaluate some good default values for these flags. Right now they are 20 and 50 respectively. This might change if we find that some other values are more appropriate. Background: There are three command line options related to the young gen size: NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is just a short form for NewSize==MaxNewSize). G1 will use its internal heuristics to calculate the actual young gen size, so these options basically only limit the range within which G1 can pick a young gen size. Also, these are general options taking byte sizes. G1 will internally work with a number of regions instead. So, some rounding will occur. The idea is that my fix should work pretty much as follows: If nothing related to the the young gen size is set on the command line we should allow the young gen to be between 20% and 50% of the heap size. This means that every time the heap size changes the limits for the young gen size will be updated. If only -XX:NewSize is set we should use the specified value as the minimum size for young gen. Still using 50% of the heap as maximum. If only -XX:MaxNewSize is set we should use the specified value as the maximum size for young gen. Still using 20% of the heap as minimum. If -XX:NewSize and -XX:MaxNewSize are both specified we use these values. No updates when the heap size changes. There is a special case when NewSize==MaxNewSize. This is interpreted as "fixed" and will use a different heuristic for calculating the collection set when we do mixed collection. If only -XX:NewRatio is set we should use the specified ratio of the heap as both min and max. This will be interpreted as "fixed" just like the NewSize==MaxNewSize case above. But we will update the min and max everytime the heap size changes. NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if it is combined with either NewSize or MaxNewSize. (A warning message is printed.) Thanks, Bengt From jon.masamitsu at oracle.com Mon Dec 19 19:33:36 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 19 Dec 2011 11:33:36 -0800 Subject: request for review (m) - 7121618 Message-ID: <4EEF9190.90809@oracle.com> This changes the type used for the number of GC threads to unsigned int from mostly size_t and changes corresponding variables that take the number of GC threads also to unsigned int. Some variables names were also changed in the process (principally "int i" in the work() method where "i" refers to the thread to "uint worker_id"). There are many changes but all are straightforward type or name changes. 7121618: Change type of number of GC workers to unsigned int. http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ Thanks. From john.cuthbertson at oracle.com Mon Dec 19 23:26:29 2011 From: john.cuthbertson at oracle.com (john.cuthbertson at oracle.com) Date: Mon, 19 Dec 2011 23:26:29 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Message-ID: <20111219232632.2AB164775F@hg.openjdk.java.net> Changeset: e7dead7e90af Author: johnc Date: 2011-12-19 10:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e7dead7e90af 7117303: VM uses non-monotonic time source and complains that it is non-monotonic Summary: Replaces calls to os::javaTimeMillis(), which does not (and cannot) guarantee monotonicity, in GC code to an equivalent expression that uses os::javaTimeNanos(). os::javaTimeNanos is guaranteed monotonically non-decreasing if the underlying platform provides a monotonic time source. Changes in OS files are to make use of the newly defined constants in globalDefinitions.hpp. Reviewed-by: dholmes, ysr ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/utilities/globalDefinitions.hpp From bengt.rutisson at oracle.com Tue Dec 20 08:04:21 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Dec 2011 09:04:21 +0100 Subject: request for review (m) - 7121618 In-Reply-To: <4EEF9190.90809@oracle.com> References: <4EEF9190.90809@oracle.com> Message-ID: <4EF04185.1080209@oracle.com> Hi Jon, Thanks for cleaning this up! I like it much better! Some details: I think some method declarations still have to change to use "worker_id" instead of "i" as their parameter: concurrentMarkSweepGeneration.cpp Line 3782: void work(uint i); for CMSConcMarkingTask Line 5081: void work(uint i); for CMSParRemarkTask. Line 5742 "virtual void work(uint i);" for CMSRefProcTaskProxy parNewGeneration.cpp Line 758: "virtual void work(uint i);" for ParNewRefProcTaskProxy parNewGeneration.hpp Line 242: "void work(uint i);" for ParNewGenTask workgroup.hpp Line 71: "virtual void work(uint i) = 0;" for AbstractGangTask yieldingWorkgroup.hpp Line 74: "virtual void work(uint i) = 0;" for FlexibleGangTask Line 131 "virtual void work(uint i) = 0;" for YieldingFlexibleGangTask A question regarding uint and uintx in flag definitions in globals.hpp. There are no flags using "only" uint. All int flags use uintx. This seems reasonable since we should be using the best int for the platform we are running on. However, now that we internally use uint for the number of GC workers it looks kind of strange that the flag for setting it is uintx. This causes some extra casting in the code. For example: g1\concurrentMark.cpp line 489: "_max_task_num(MAX2((uint)ParallelGCThreads, 1U)),". In theory I guess we could also get issues with a 64 bit value being cast down to a 32 bit value. Seems unlikely that anybody wants > 4 billion worker threads though... Is it Hotspot policy to use uintx for the flags or would it be ok to change ParallelGCThreads to be an uint instead? That would make more sense to me since that is our internal representation. I guess that would propagate to other flags that set number of threads such as ConcGCThreads. parCardTableModRefBS.cpp A little bit too picky maybe, but line 59 looks like this: "uint n_strides = n_threads * ParGCStridesPerThread;". It is the only use of ParGCStridesPerThread. For some reason ParGCStridesPerThread is declared an intx in globals.hpp. Would you be ok with including a change of ParGCStridesPerThread to uintx in your fix? Makes me a little nervous that we mix signed and unsigned types even though it seems to work out here. Thanks, Bengt On 2011-12-19 20:33, Jon Masamitsu wrote: > This changes the type used for the number of GC threads to unsigned > int from > mostly size_t and changes corresponding variables that take the number > of GC > threads also to unsigned int. Some variables names were also changed in > the process (principally "int i" in the work() method where "i" refers to > the thread to "uint worker_id"). > > There are many changes but all are straightforward type or > name changes. > > 7121618: Change type of number of GC workers to unsigned int. > > http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ > > Thanks. From tony.printezis at oracle.com Tue Dec 20 13:38:56 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 08:38:56 -0500 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up Message-ID: <4EF08FF0.7080308@oracle.com> Hi all, Can I have a couple of quick reviews for this very small change (< 10 lines changed)? http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ During parallel verification each worker now takes a lock after it detects a failure and while it's generating output. This way the output from separate workers is not interleaved and it's easier to read. I came across this issue while testing some recent changes and this patch made my life easier. It might make your life easier some day too. :-) Tony From jon.masamitsu at oracle.com Tue Dec 20 15:24:13 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 20 Dec 2011 07:24:13 -0800 Subject: request for review (m) - 7121618 In-Reply-To: <4EF04185.1080209@oracle.com> References: <4EEF9190.90809@oracle.com> <4EF04185.1080209@oracle.com> Message-ID: <4EF0A89D.1010004@oracle.com> Bengt, Thanks for reviewing this. I'll fix the other work() methods. My apologies for not being more diligent on that score. I don't know the answer to the question of using uint as a flag type. I know there is some machinery behind the flag types. For example there is a get_uintx() and no get_uint() and I don't know it is just a lack of an implementation for uint or something else. If you don't mind, I'd like to avoid stepping into that question with this set of changes. Inline comment below. On 12/20/11 00:04, Bengt Rutisson wrote: > > Hi Jon, > > Thanks for cleaning this up! I like it much better! > > Some details: > > I think some method declarations still have to change to use > "worker_id" instead of "i" as their parameter: > > concurrentMarkSweepGeneration.cpp > Line 3782: void work(uint i); for CMSConcMarkingTask > Line 5081: void work(uint i); for CMSParRemarkTask. > Line 5742 "virtual void work(uint i);" for CMSRefProcTaskProxy > > parNewGeneration.cpp > Line 758: "virtual void work(uint i);" for ParNewRefProcTaskProxy > > parNewGeneration.hpp > Line 242: "void work(uint i);" for ParNewGenTask > > workgroup.hpp > Line 71: "virtual void work(uint i) = 0;" for AbstractGangTask > > yieldingWorkgroup.hpp > Line 74: "virtual void work(uint i) = 0;" for FlexibleGangTask > Line 131 "virtual void work(uint i) = 0;" for YieldingFlexibleGangTask > > > A question regarding uint and uintx in flag definitions in > globals.hpp. There are no flags using "only" uint. All int flags use > uintx. This seems reasonable since we should be using the best int for > the platform we are running on. However, now that we internally use > uint for the number of GC workers it looks kind of strange that the > flag for setting it is uintx. This causes some extra casting in the > code. For example: g1\concurrentMark.cpp line 489: > "_max_task_num(MAX2((uint)ParallelGCThreads, 1U)),". In theory I guess > we could also get issues with a 64 bit value being cast down to a 32 > bit value. Seems unlikely that anybody wants > 4 billion worker > threads though... > > Is it Hotspot policy to use uintx for the flags or would it be ok to > change ParallelGCThreads to be an uint instead? That would make more > sense to me since that is our internal representation. I guess that > would propagate to other flags that set number of threads such as > ConcGCThreads. > > parCardTableModRefBS.cpp > A little bit too picky maybe, but line 59 looks like this: "uint > n_strides = n_threads * ParGCStridesPerThread;". It is the only use of > ParGCStridesPerThread. For some reason ParGCStridesPerThread is > declared an intx in globals.hpp. Would you be ok with including a > change of ParGCStridesPerThread to uintx in your fix? Makes me a > little nervous that we mix signed and unsigned types even though it > seems to work out here. Yes I'll change ParGCStridesPerThread to uintx Thanks again. Jon > > Thanks, > Bengt > > > > > On 2011-12-19 20:33, Jon Masamitsu wrote: >> This changes the type used for the number of GC threads to unsigned >> int from >> mostly size_t and changes corresponding variables that take the >> number of GC >> threads also to unsigned int. Some variables names were also changed in >> the process (principally "int i" in the work() method where "i" >> refers to >> the thread to "uint worker_id"). >> >> There are many changes but all are straightforward type or >> name changes. >> >> 7121618: Change type of number of GC workers to unsigned int. >> >> http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ >> >> Thanks. > From bengt.rutisson at oracle.com Tue Dec 20 15:25:28 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Dec 2011 16:25:28 +0100 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up In-Reply-To: <4EF08FF0.7080308@oracle.com> References: <4EF08FF0.7080308@oracle.com> Message-ID: Tony, Looks good to me. One style question. Line 97. Would you be ok with adding a newline after "template "? I think that's common in hotspot and it's what is done on line 193. Bengt 20 dec 2011 kl. 14:38 skrev Tony Printezis : > Hi all, > > Can I have a couple of quick reviews for this very small change (< 10 lines changed)? > > http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ > > During parallel verification each worker now takes a lock after it detects a failure and while it's generating output. This way the output from separate workers is not interleaved and it's easier to read. I came across this issue while testing some recent changes and this patch made my life easier. It might make your life easier some day too. :-) > > Tony > From tony.printezis at oracle.com Tue Dec 20 16:28:47 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 11:28:47 -0500 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up In-Reply-To: References: <4EF08FF0.7080308@oracle.com> Message-ID: <4EF0B7BF.2040608@oracle.com> Bengt, Thanks for the _very_ prompt code review! I made the change you requested, latest webrev here: http://cr.openjdk.java.net/~tonyp/7123165/webrev.1/ Tony On 12/20/2011 10:25 AM, Bengt Rutisson wrote: > Tony, > > Looks good to me. > > One style question. Line 97. Would you be ok with adding a newline after "template"? > > I think that's common in hotspot and it's what is done on line 193. > > Bengt > > > 20 dec 2011 kl. 14:38 skrev Tony Printezis: > >> Hi all, >> >> Can I have a couple of quick reviews for this very small change (< 10 lines changed)? >> >> http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ >> >> During parallel verification each worker now takes a lock after it detects a failure and while it's generating output. This way the output from separate workers is not interleaved and it's easier to read. I came across this issue while testing some recent changes and this patch made my life easier. It might make your life easier some day too. :-) >> >> Tony >> From john.cuthbertson at oracle.com Tue Dec 20 17:34:41 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 20 Dec 2011 09:34:41 -0800 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up In-Reply-To: <4EF08FF0.7080308@oracle.com> References: <4EF08FF0.7080308@oracle.com> Message-ID: <4EF0C731.9030806@oracle.com> Hi Tony, Looks good to me. JohnC On 12/20/11 05:38, Tony Printezis wrote: > Hi all, > > Can I have a couple of quick reviews for this very small change (< 10 > lines changed)? > > http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ > > During parallel verification each worker now takes a lock after it > detects a failure and while it's generating output. This way the > output from separate workers is not interleaved and it's easier to > read. I came across this issue while testing some recent changes and > this patch made my life easier. It might make your life easier some > day too. :-) > > Tony > From john.cuthbertson at oracle.com Tue Dec 20 17:46:48 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 20 Dec 2011 09:46:48 -0800 Subject: RFR(S): 7121547: G1: High number mispredicted branches while iterating over the marking bitmap Message-ID: <4EF0CA08.8060206@oracle.com> Hi Everyone, Can I have a couple of volunteers review this small change? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7121547/webrev.0/ Summary: While analyzing the data from some collect/analyze runs of the changes for 6484965 (Piggy back liveness accounting on marking) it was noticed that there was a significant number of mispredicted branches associated with the actual call of BitMap::iterate() from within CMBitMapRO::iterate(). With the changes in the webrev I can see a slight reduction in the CPU time (a few percentage points), a slight reduction in the number of L2 misses (again a few points), and between a 20-40% drop in the number of mis-predicted branches. Testing: The GC test suite and Kitchensink (with low marking thresholds); collect/analyze runs of SPECjbb2005; jprt. Thanks, JohnC From tony.printezis at oracle.com Tue Dec 20 17:52:37 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 12:52:37 -0500 Subject: CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet Message-ID: <4EF0CB65.6090703@oracle.com> Hi all, I'd like a couple of code reviews for this small change that resolves the race that we identified a few weeks ago (and which we already guard against in the code): http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/ Instead of using atomics I decided to take an alternative approach to eliminate the race which as described in the CR: "The final fix is somewhat different to what I had originally planned and does not use atomics. The observation is that only two threads can update the fields in question: a mutator thread that retires a region before allocating a new one (and it has to take the Heap_lock in order to do so - so those updates are serialized anyway) and a concurrent refinement thread that samples the RSets in the inc CSet. What we'll do is to accumulate the updates from each thread on separate fields and we'll just combine them at the start of a GC." Thanks, Tony From tony.printezis at oracle.com Tue Dec 20 18:04:23 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 13:04:23 -0500 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up In-Reply-To: <4EF0C731.9030806@oracle.com> References: <4EF08FF0.7080308@oracle.com> <4EF0C731.9030806@oracle.com> Message-ID: <4EF0CE27.8080905@oracle.com> Hi all, All set thanks to Bengt, John, and Jon! Tony On 12/20/2011 12:34 PM, John Cuthbertson wrote: > Hi Tony, > > Looks good to me. > > JohnC > > On 12/20/11 05:38, Tony Printezis wrote: >> Hi all, >> >> Can I have a couple of quick reviews for this very small change (< 10 >> lines changed)? >> >> http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ >> >> During parallel verification each worker now takes a lock after it >> detects a failure and while it's generating output. This way the >> output from separate workers is not interleaved and it's easier to >> read. I came across this issue while testing some recent changes and >> this patch made my life easier. It might make your life easier some >> day too. :-) >> >> Tony >> > From jon.masamitsu at oracle.com Tue Dec 20 18:34:07 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 20 Dec 2011 10:34:07 -0800 Subject: request for review (m) - 7121618 In-Reply-To: <4EEF9190.90809@oracle.com> References: <4EEF9190.90809@oracle.com> Message-ID: <4EF0D51F.8030400@oracle.com> I've updated the webrev for review comments (thanks, Bengt). http://cr.openjdk.java.net/~jmasa/7121618/webrev.01/ On 12/19/11 11:33, Jon Masamitsu wrote: > This changes the type used for the number of GC threads to unsigned > int from > mostly size_t and changes corresponding variables that take the number > of GC > threads also to unsigned int. Some variables names were also changed in > the process (principally "int i" in the work() method where "i" refers to > the thread to "uint worker_id"). > > There are many changes but all are straightforward type or > name changes. > > 7121618: Change type of number of GC workers to unsigned int. > > http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ > > Thanks. From bengt.rutisson at oracle.com Tue Dec 20 19:11:24 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Dec 2011 20:11:24 +0100 Subject: CRR (XS): 7123165: G1: output during parallel verification can get messed up In-Reply-To: <4EF0B7BF.2040608@oracle.com> References: <4EF08FF0.7080308@oracle.com> <4EF0B7BF.2040608@oracle.com> Message-ID: <4EF0DDDC.9040601@oracle.com> On 2011-12-20 17:28, Tony Printezis wrote: > Bengt, > > Thanks for the _very_ prompt code review! I made the change you > requested, latest webrev here: > > http://cr.openjdk.java.net/~tonyp/7123165/webrev.1/ Thanks for fixing that! Looks good. Ship it! Bengt > > Tony > > On 12/20/2011 10:25 AM, Bengt Rutisson wrote: >> Tony, >> >> Looks good to me. >> >> One style question. Line 97. Would you be ok with adding a newline >> after "template"? >> >> I think that's common in hotspot and it's what is done on line 193. >> >> Bengt >> >> >> 20 dec 2011 kl. 14:38 skrev Tony Printezis: >> >>> Hi all, >>> >>> Can I have a couple of quick reviews for this very small change (< >>> 10 lines changed)? >>> >>> http://cr.openjdk.java.net/~tonyp/7123165/webrev.0/ >>> >>> During parallel verification each worker now takes a lock after it >>> detects a failure and while it's generating output. This way the >>> output from separate workers is not interleaved and it's easier to >>> read. I came across this issue while testing some recent changes and >>> this patch made my life easier. It might make your life easier some >>> day too. :-) >>> >>> Tony >>> From john.cuthbertson at oracle.com Tue Dec 20 19:16:09 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 20 Dec 2011 11:16:09 -0800 Subject: RFR(L): 6484965: G1: piggy-back liveness accounting phase on marking In-Reply-To: <4ED38788.4010106@oracle.com> References: <4E8A40BE.9020800@oracle.com> <4EC2B317.3000006@oracle.com> <4ED38788.4010106@oracle.com> Message-ID: <4EF0DEF9.30306@oracle.com> Hi Bengt, As I mentioned earlier - thanks for the code review. I've applied your suggestions, merged with the the latest changeset in hsx/hotspot-gc/hotspot (resolving any conflicts), fixed the int <-> size_t issue you also mentioned, and retested using the GC test suite. A new webrev can be found at: http://cr.openjdk.java.net/~johnc/6484965/webrev.2/ Specific replies are inline. On 11/28/11 05:07, Bengt Rutisson wrote: > > John, > > A little late, but here are some comments on this webrev. I know you > have some more improvements to this change coming, but overall I think > it looks good. Most of my comments are just minor coding style comments. > > Bengt > > concurrentMark.hpp > > Rename ConcurrentMark::clear() to ConcurrentMark::clear_mark() or > ConcurrentMark::unmark()? The commment you added is definitely needed > to understand what this method does. But it would be even better if it > was possible to get that from the method name itself. Done. > It seems like everywhere we use count_marked_bytes_for(int worker_i) > we almost directly use the array returned to index with the heap > region that we are interested in. How about wrapping all of this is in > something like count_set_marked_bytes_for(int worker_i, int hrs_index) > and count_get_marked_bytes_for(int worker_i, int hrs_index) ? That way > the data structure does not have to be exposed outside ConcurrentMark. > It would mean that ConcurrentMark::count_region() would have to take a > worker_i value instead of a marked_bytes_array. I did not do this. I embed the marked_bytes array for a worker into the CMTask for that worker to save a de-reference. This was one of the requests from the original code walk-through. Avoiding the de-reference in the CMTask::do_marking_step() shaves a couple of points off the marking time. I think your suggestion would reinstate the de-reference again and we would lose those few percentage points again. > If you don't agree with the suggestion above I would suggest to change > the name from count_marked_bytes_for() to > count_marked_bytes_array_for() since in every place that it is being > called the resulting value is stored in a local variable called > marked_bytes_array, which seems like a more informative name to me. Done. I agree - the new name sounds better. > I think this comment: > > // As above - but we don't know the heap region containing the > // object and so have to supply it. > inline bool par_mark_and_count(oop obj, int worker_i); > > should be something like "we don't know the heap region containing the > object so we will have to look it up". > > Same thing here: > > // As above - but we don't have the heap region containing the > // object, so we have to supply it. > // Should *not* be called from parallel code. > inline bool mark_and_count(oop obj); > > Comments were changed to: > concurrentMark.cpp > > Since you are changing CalcLiveObjectsClosure::doHeapRegion() anyway, > could you please remove this unused code (1393-1397): > > /* > gclog_or_tty->print_cr("Setting bits from %d/%d.", > obj_card_num - _bottom_card_num, > obj_last_card_num - _bottom_card_num); > */ > > Done. > What about the destructor ConcurrentMark::~ConcurrentMark() ? I > remember Tony mentioning that it won't be called. Do you still want to > keep the code? I removed the entire destructor - I don't see it being called in the experiments I've run. > FinalCountDataUpdateClosure::set_bit_for_region() > Probably not worth it, but would it make sense to add information in a > startsHumongous HeapRegion to be able to give you the last > continuesHumongous region? Since we know this when we set the regions > up it seems like a waste to have to iterate over the region list to > find it. If you read the original comment - the original author did not want to make any assumptions about the internal field values of the HeapRegions spanned by a humongous object and so used the loop technique. I think you are correct and I now use the information in the startsHumongous region to find the index of the last continuesHumongous region spaned by the H-obj. > G1ParFinalCountTask > To me it is a bit surprising that we mix in the verify code inside > this closure. Would it be possible to extract this code out somehow? I did it this way to avoid another iteration over the heap regions. But it probably does make more sense to separate them and use another iteration to do the verify. Done. > Line 3378: "// Use fill_to_bytes". Is this something you plan on doing? I removed the comment. I was thinking of doing this as fill_to_bytes is typically implemented using (a possibly specialized version of) memset. But it's probably not worth it in this case. > G1ParFinalCountTask::work() > Just for the record. I don't really like the way we have to set up > both a VerifyLiveObjectDataHRClosure and a Mux2HRClosure even though > we will only use them if we have VerifyDuringGC enabled. I realize it > is due to the scoping, but I still think it obstucts the code flow and > introduces unnecessary work. Unfortunately I don't have a good > suggestion for how to work around it. > > Since both VerifyLiveObjectDataHRClosure and a Mux2HRClosure are > StackObjs I assume it is not possible to get around the issue with a > ResourceMark. Now that the verification is performed in a separate iteration of the heap regions there's no need to create the VerifyLiveObjectDataHRClosure and Mux2HRClosure instances here. Done. I have also removed the now-redundant Mux2HRClosure. Hopefully the new webrev addresses these comments. Thanks again for looking. JohnC From bengt.rutisson at oracle.com Tue Dec 20 20:13:30 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Dec 2011 21:13:30 +0100 Subject: request for review (m) - 7121618 In-Reply-To: <4EF0D51F.8030400@oracle.com> References: <4EEF9190.90809@oracle.com> <4EF0D51F.8030400@oracle.com> Message-ID: <4EF0EC6A.4010107@oracle.com> Jon, On 2011-12-20 19:34, Jon Masamitsu wrote: > I've updated the webrev for review comments > (thanks, Bengt). > > http://cr.openjdk.java.net/~jmasa/7121618/webrev.01/ Thanks for applying my comments. Looks good. Do you have any input on the other questions? A question regarding uint and uintx in flag definitions in globals.hpp. There are no flags using "only" uint. All int flags use uintx. This seems reasonable since we should be using the best int for the platform we are running on. However, now that we internally use uint for the number of GC workers it looks kind of strange that the flag for setting it is uintx. This causes some extra casting in the code. For example: g1\concurrentMark.cpp line 489: "_max_task_num(MAX2((uint)ParallelGCThreads, 1U)),". In theory I guess we could also get issues with a 64 bit value being cast down to a 32 bit value. Seems unlikely that anybody wants > 4 billion worker threads though... Is it Hotspot policy to use uintx for the flags or would it be ok to change ParallelGCThreads to be an uint instead? That would make more sense to me since that is our internal representation. I guess that would propagate to other flags that set number of threads such as ConcGCThreads. parCardTableModRefBS.cpp A little bit too picky maybe, but line 59 looks like this: "uint n_strides = n_threads * ParGCStridesPerThread;". It is the only use of ParGCStridesPerThread. For some reason ParGCStridesPerThread is declared an intx in globals.hpp. Would you be ok with including a change of ParGCStridesPerThread to uintx in your fix? Makes me a little nervous that we mix signed and unsigned types even though it seems to work out here. Thanks, Bengt > > On 12/19/11 11:33, Jon Masamitsu wrote: >> This changes the type used for the number of GC threads to unsigned >> int from >> mostly size_t and changes corresponding variables that take the >> number of GC >> threads also to unsigned int. Some variables names were also changed in >> the process (principally "int i" in the work() method where "i" >> refers to >> the thread to "uint worker_id"). >> >> There are many changes but all are straightforward type or >> name changes. >> >> 7121618: Change type of number of GC workers to unsigned int. >> >> http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ >> >> Thanks. From bengt.rutisson at oracle.com Tue Dec 20 20:48:27 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 20 Dec 2011 21:48:27 +0100 Subject: CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet In-Reply-To: <4EF0CB65.6090703@oracle.com> References: <4EF0CB65.6090703@oracle.com> Message-ID: <4EF0F49B.9040202@oracle.com> Tony, Looks good. I like that it was possible to avoid atomic updates. Bengt On 2011-12-20 18:52, Tony Printezis wrote: > Hi all, > > I'd like a couple of code reviews for this small change that resolves > the race that we identified a few weeks ago (and which we already > guard against in the code): > > http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/ > > Instead of using atomics I decided to take an alternative approach to > eliminate the race which as described in the CR: > > "The final fix is somewhat different to what I had originally planned > and does not use atomics. The observation is that only two threads can > update the fields in question: a mutator thread that retires a region > before allocating a new one (and it has to take the Heap_lock in order > to do so - so those updates are serialized anyway) and a concurrent > refinement thread that samples the RSets in the inc CSet. What we'll > do is to accumulate the updates from each thread on separate fields > and we'll just combine them at the start of a GC." > > Thanks, > > Tony From john.cuthbertson at oracle.com Tue Dec 20 21:18:59 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Tue, 20 Dec 2011 13:18:59 -0800 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EE9208B.5040203@oracle.com> References: <4EE9208B.5040203@oracle.com> Message-ID: <4EF0FBC3.5030806@oracle.com> Hi Tony, Looks good to me. JohnC On 12/14/11 14:17, Tony Printezis wrote: > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ > > The CR has a bit more explanation. The short version is that I'm now > encoding the "start index of the next chunk" in the from-space length > field of a chunked array (say *that* quickly!) as a negative value to > always be able to distinguish it from the real length. This will > simplify the code for the CR John is currently working on (6484965) > but it's a small, self-contained change so it's good to get it code > reviewed and pushed separately. > > Tony > From tony.printezis at oracle.com Tue Dec 20 21:51:51 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 16:51:51 -0500 Subject: CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet In-Reply-To: <4EF0F49B.9040202@oracle.com> References: <4EF0CB65.6090703@oracle.com> <4EF0F49B.9040202@oracle.com> Message-ID: <4EF10377.6000709@oracle.com> Bengt, Thanks for the code review. Yes, I like the non-atomics version too. Tony On 12/20/2011 03:48 PM, Bengt Rutisson wrote: > > Tony, > > Looks good. I like that it was possible to avoid atomic updates. > > Bengt > > On 2011-12-20 18:52, Tony Printezis wrote: >> Hi all, >> >> I'd like a couple of code reviews for this small change that resolves >> the race that we identified a few weeks ago (and which we already >> guard against in the code): >> >> http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/ >> >> Instead of using atomics I decided to take an alternative approach to >> eliminate the race which as described in the CR: >> >> "The final fix is somewhat different to what I had originally planned >> and does not use atomics. The observation is that only two threads >> can update the fields in question: a mutator thread that retires a >> region before allocating a new one (and it has to take the Heap_lock >> in order to do so - so those updates are serialized anyway) and a >> concurrent refinement thread that samples the RSets in the inc CSet. >> What we'll do is to accumulate the updates from each thread on >> separate fields and we'll just combine them at the start of a GC." >> >> Thanks, >> >> Tony > From igor.veresov at oracle.com Tue Dec 20 23:22:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 20 Dec 2011 15:22:39 -0800 Subject: CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet In-Reply-To: <4EF0CB65.6090703@oracle.com> References: <4EF0CB65.6090703@oracle.com> Message-ID: Looks good. igor On Tuesday, December 20, 2011 at 9:52 AM, Tony Printezis wrote: > Hi all, > > I'd like a couple of code reviews for this small change that resolves > the race that we identified a few weeks ago (and which we already guard > against in the code): > > http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/ > > Instead of using atomics I decided to take an alternative approach to > eliminate the race which as described in the CR: > > "The final fix is somewhat different to what I had originally planned > and does not use atomics. The observation is that only two threads can > update the fields in question: a mutator thread that retires a region > before allocating a new one (and it has to take the Heap_lock in order > to do so - so those updates are serialized anyway) and a concurrent > refinement thread that samples the RSets in the inc CSet. What we'll do > is to accumulate the updates from each thread on separate fields and > we'll just combine them at the start of a GC." > > Thanks, > > Tony From tony.printezis at oracle.com Tue Dec 20 23:27:10 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 20 Dec 2011 18:27:10 -0500 Subject: CRR (S): 7119027: G1: use atomics to update RS length / predict time of inc CSet In-Reply-To: References: <4EF0CB65.6090703@oracle.com> Message-ID: <4EF119CE.9050003@oracle.com> Thanks Igor! All set thanks to Igor and Bengt. Tony On 12/20/2011 06:22 PM, Igor Veresov wrote: > Looks good. > > igor > > > On Tuesday, December 20, 2011 at 9:52 AM, Tony Printezis wrote: > >> Hi all, >> >> I'd like a couple of code reviews for this small change that resolves >> the race that we identified a few weeks ago (and which we already guard >> against in the code): >> >> http://cr.openjdk.java.net/~tonyp/7119027/webrev.0/ >> >> Instead of using atomics I decided to take an alternative approach to >> eliminate the race which as described in the CR: >> >> "The final fix is somewhat different to what I had originally planned >> and does not use atomics. The observation is that only two threads can >> update the fields in question: a mutator thread that retires a region >> before allocating a new one (and it has to take the Heap_lock in order >> to do so - so those updates are serialized anyway) and a concurrent >> refinement thread that samples the RSets in the inc CSet. What we'll do >> is to accumulate the updates from each thread on separate fields and >> we'll just combine them at the start of a GC." >> >> Thanks, >> >> Tony > From tony.printezis at oracle.com Wed Dec 21 01:17:39 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Wed, 21 Dec 2011 01:17:39 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7123165: G1: output during parallel verification can get messed up Message-ID: <20111221011745.909DC47774@hg.openjdk.java.net> Changeset: 3b2b58fb1425 Author: tonyp Date: 2011-12-20 12:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b2b58fb1425 7123165: G1: output during parallel verification can get messed up Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent. Reviewed-by: brutisso, johnc, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp From ysr1729 at gmail.com Wed Dec 21 06:34:37 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 20 Dec 2011 22:34:37 -0800 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EE9208B.5040203@oracle.com> References: <4EE9208B.5040203@oracle.com> Message-ID: Hi Tony -- For some reason, I cannot seem to be able to view either of the CR's you mention below, and thus lack the requisite background context for this change. The localized change however looks fine, and it is nice to distinguish the two states of the array in this way by means of the sign of the length field. One question is whether, for the sake of debugging & representational uniformity, it would make sense to use the same encoding in the other collectors that do this chunking (even though I understand they may not have the need to deal with 6484965, whatever that might be :-) Reviewed! -- ramki On Wed, Dec 14, 2011 at 2:17 PM, Tony Printezis wrote: > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~**tonyp/7121623/webrev.0/ > > The CR has a bit more explanation. The short version is that I'm now > encoding the "start index of the next chunk" in the from-space length field > of a chunked array (say *that* quickly!) as a negative value to always be > able to distinguish it from the real length. This will simplify the code > for the CR John is currently working on (6484965) but it's a small, > self-contained change so it's good to get it code reviewed and pushed > separately. > > Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Wed Dec 21 06:46:42 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 20 Dec 2011 22:46:42 -0800 Subject: request for review (m) - 7121618 In-Reply-To: <4EEF9190.90809@oracle.com> References: <4EEF9190.90809@oracle.com> Message-ID: Hi Jon -- I probably won't have the time to look at the specific changes but I'm so happy to see those int's change to unit's. This has been a wart that needed fixing for a long time, and I am glad you are cleaning this up. So my "+1" for this change!! :-) -- ramki On Mon, Dec 19, 2011 at 11:33 AM, Jon Masamitsu wrote: > This changes the type used for the number of GC threads to unsigned int > from > mostly size_t and changes corresponding variables that take the number of > GC > threads also to unsigned int. Some variables names were also changed in > the process (principally "int i" in the work() method where "i" refers to > the thread to "uint worker_id"). > > There are many changes but all are straightforward type or > name changes. > > 7121618: Change type of number of GC workers to unsigned int. > > http://cr.openjdk.java.net/~**jmasa/7121618/webrev.00/ > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Dec 21 07:02:32 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Dec 2011 08:02:32 +0100 Subject: request for review (m) - 7121618 In-Reply-To: <4EF0A89D.1010004@oracle.com> References: <4EEF9190.90809@oracle.com> <4EF04185.1080209@oracle.com> <4EF0A89D.1010004@oracle.com> Message-ID: <4EF18488.60307@oracle.com> Jon, Sorry, I missed this email for some reason. (Thanks for pointing me to it!) Let's leave the flags as uintx. Thanks for fixing ParGCStridesPerThread. Apologies again for my previous confusing email. Thanks, Bengt On 2011-12-20 16:24, Jon Masamitsu wrote: > Bengt, > > Thanks for reviewing this. I'll fix the other work() methods. > My apologies for not being more diligent on that score. > > I don't know the answer to the question of using uint as a flag > type. I know there is some machinery behind the flag types. > For example there is a get_uintx() and no get_uint() and > I don't know it is just a lack of an implementation for uint or > something else. If you don't mind, I'd like to avoid stepping into > that question with this set of changes. > > Inline comment below. > > > On 12/20/11 00:04, Bengt Rutisson wrote: >> >> Hi Jon, >> >> Thanks for cleaning this up! I like it much better! >> >> Some details: >> >> I think some method declarations still have to change to use >> "worker_id" instead of "i" as their parameter: >> >> concurrentMarkSweepGeneration.cpp >> Line 3782: void work(uint i); for CMSConcMarkingTask >> Line 5081: void work(uint i); for CMSParRemarkTask. >> Line 5742 "virtual void work(uint i);" for CMSRefProcTaskProxy >> >> parNewGeneration.cpp >> Line 758: "virtual void work(uint i);" for ParNewRefProcTaskProxy >> >> parNewGeneration.hpp >> Line 242: "void work(uint i);" for ParNewGenTask >> >> workgroup.hpp >> Line 71: "virtual void work(uint i) = 0;" for AbstractGangTask >> >> yieldingWorkgroup.hpp >> Line 74: "virtual void work(uint i) = 0;" for FlexibleGangTask >> Line 131 "virtual void work(uint i) = 0;" for YieldingFlexibleGangTask >> >> >> A question regarding uint and uintx in flag definitions in >> globals.hpp. There are no flags using "only" uint. All int flags use >> uintx. This seems reasonable since we should be using the best int >> for the platform we are running on. However, now that we internally >> use uint for the number of GC workers it looks kind of strange that >> the flag for setting it is uintx. This causes some extra casting in >> the code. For example: g1\concurrentMark.cpp line 489: >> "_max_task_num(MAX2((uint)ParallelGCThreads, 1U)),". In theory I >> guess we could also get issues with a 64 bit value being cast down to >> a 32 bit value. Seems unlikely that anybody wants > 4 billion worker >> threads though... >> >> Is it Hotspot policy to use uintx for the flags or would it be ok to >> change ParallelGCThreads to be an uint instead? That would make more >> sense to me since that is our internal representation. I guess that >> would propagate to other flags that set number of threads such as >> ConcGCThreads. >> >> parCardTableModRefBS.cpp >> A little bit too picky maybe, but line 59 looks like this: "uint >> n_strides = n_threads * ParGCStridesPerThread;". It is the only use >> of ParGCStridesPerThread. For some reason ParGCStridesPerThread is >> declared an intx in globals.hpp. Would you be ok with including a >> change of ParGCStridesPerThread to uintx in your fix? Makes me a >> little nervous that we mix signed and unsigned types even though it >> seems to work out here. > > Yes I'll change ParGCStridesPerThread to uintx > > Thanks again. > > Jon > >> >> Thanks, >> Bengt >> >> >> >> >> On 2011-12-19 20:33, Jon Masamitsu wrote: >>> This changes the type used for the number of GC threads to unsigned >>> int from >>> mostly size_t and changes corresponding variables that take the >>> number of GC >>> threads also to unsigned int. Some variables names were also >>> changed in >>> the process (principally "int i" in the work() method where "i" >>> refers to >>> the thread to "uint worker_id"). >>> >>> There are many changes but all are straightforward type or >>> name changes. >>> >>> 7121618: Change type of number of GC workers to unsigned int. >>> >>> http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ >>> >>> Thanks. >> From tony.printezis at oracle.com Wed Dec 21 08:53:01 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 03:53:01 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: References: <4EE9208B.5040203@oracle.com> Message-ID: <4EF19E6D.2090200@oracle.com> Ramki, Thanks for looking at this! Here's an explanation why we need this: (As you know!) in G1 we don't have an initial-mark pause and we piggy-back marking the roots on an evacuation pause. This means that we might have to mark an object we are copying / have copied. This is mostly straightforward and it's been in G1 for quite a while. John is working on some changes to piggy-back liveness counting on the marking phase. For that we need to know the size of each object we mark. For objects that are being moved this is not as straightforward. Consider the case where a thread is scanning a root that points to an object being copied by another thread. Even though we know the reference to the from-/to-images we do not know whether the to-image is actually complete given that an object gets forwarded first, then copied and there's no easy way to find out whether it's been copied or not without some additional synchronization which it'd be good to avoid: we only need this during initial-mark pauses which are infrequent. One idea is to always read the size from the from-image, which works mots of the time apart from the case where the object is a chunked object array since we use its length to store how much of the object we have not processed yet (and without its length we cannot work out its size). Again, currently there's no way to determine whether the length is the actual length or an encoded index given that they both look like ints >= 0. Encoding it as a negative integer, which is what this changeset does, allows us to distinguish a valid length (>=0) from an encoded index (<0). FWIW, here's the code (from a follow-up changeset) that relies on this encoding to calculate the size of a forwarded object (old -> from-image, obj -> to-image): int size; if (!old->is_objArray()) { // The easy case. This is safe, the from-image of all non-object // arrays should be well formed. size = old->size(); } else { objArrayOop array_old = objArrayOop(old); int length = array_old->length(); if (length < 0) { // It's been chunked so we cannot trust the from-image. We will // get the size from the to-image which we know is well formed // (copy is finished before the length becomes negative). objArrayOop array_obj = objArrayOop(obj); length = array_obj->length(); } else { // Because the length is positive we know it's correct, i.e. the // array is not being chunked right now. } size = objArrayOopDesc::object_size(length); } Hope this clears things up. Tony On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote: > Hi Tony -- > > For some reason, I cannot seem to be able to view either of the CR's > you mention below, and thus > lack the requisite background context for this change. The localized > change however looks fine, > and it is nice to distinguish the two states of the array in this way > by means of the sign of the length field. > > One question is whether, for the sake of debugging & representational > uniformity, it would make sense to use the same > encoding in the other collectors that do this chunking (even though I > understand they may not have > the need to deal with 6484965, whatever that might be :-) > > Reviewed! > -- ramki > > On Wed, Dec 14, 2011 at 2:17 PM, Tony Printezis > > wrote: > > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ > > > The CR has a bit more explanation. The short version is that I'm > now encoding the "start index of the next chunk" in the from-space > length field of a chunked array (say *that* quickly!) as a > negative value to always be able to distinguish it from the real > length. This will simplify the code for the CR John is currently > working on (6484965) but it's a small, self-contained change so > it's good to get it code reviewed and pushed separately. > > Tony > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Wed Dec 21 09:21:13 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 04:21:13 -0500 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EEF329B.1060005@oracle.com> References: <4EEF329B.1060005@oracle.com> Message-ID: <4EF1A509.9070100@oracle.com> Bengt, First, to repeat what I told you privately the other day: I really liked the fact that you introduced the enum for the sizing policy. It makes the code much easier to understand. I only have a couple of minor comments: g1CollectorPolicy.cpp: Instead of having the asserts: 448 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, "Min larger than max"); 449 assert(G1DefaultMinNewGenPercent> 0&& G1DefaultMinNewGenPercent< 100, "Min out of bounds"); 456 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, "Min larger than max"); 457 assert(G1DefaultMaxNewGenPercent> 0&& G1DefaultMaxNewGenPercent< 100, "Max out of bounds"); at the start of calculate_default_{min,max}_size(), why don't you just do those checks once in the G1YoungGenSizer constructor (i.e., treat them like product params)? g1CollectorPolicy.hpp: 100 // If only -XX:NewSize is set we should use the specified value as the 101 // minimum size for young gen. Still using 50% of the heap as maximum. 102 // 103 // If only -XX:MaxNewSize is set we should use the specified value as the 104 // maximum size for young gen. Still using 20% of the heap as minimum. Instead of saying 20% and 50%, why don't you just refer to the two develop parameters, as those might change in the future? Apart from that, looks great! Ship it. Tony On 12/19/2011 07:48 AM, Bengt Rutisson wrote: > > Hi everyone, > > Could I have a couple of reviews for this change? > http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ > > The idea is to give G1 some room to allow it to use its heuristics for > calculating the young gen size even when the heap size is fixed. > > CR: > 7113021 G1: automatically enable young gen size auto-tuning when > -Xms==-Xmx > http://monaco.us.oracle.com/detail.jsf?cr=7113021 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 > > I introduce two new develop flags, G1DefaultMinNewGenPercent and > G1DefaultMaxNewGenPercent. I will try to get the performance team to > evaluate some good default values for these flags. Right now they are > 20 and 50 respectively. This might change if we find that some other > values are more appropriate. > > Background: > > There are three command line options related to the young gen size: > NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is just > a short form for NewSize==MaxNewSize). G1 will use its internal > heuristics to calculate the actual young gen size, so these options > basically only limit the range within which G1 can pick a young gen > size. Also, these are general options taking byte sizes. G1 will > internally work with a number of regions instead. So, some rounding > will occur. > > The idea is that my fix should work pretty much as follows: > > If nothing related to the the young gen size is set on the command > line we should allow the young gen to be between 20% and 50% of the > heap size. This means that every time the heap size changes the limits > for the young gen size will be updated. > > If only -XX:NewSize is set we should use the specified value as the > minimum size for young gen. Still using 50% of the heap as maximum. > > If only -XX:MaxNewSize is set we should use the specified value as the > maximum size for young gen. Still using 20% of the heap as minimum. > > If -XX:NewSize and -XX:MaxNewSize are both specified we use these > values. No updates when the heap size changes. There is a special case > when NewSize==MaxNewSize. This is interpreted as "fixed" and will use > a different heuristic for calculating the collection set when we do > mixed collection. > > If only -XX:NewRatio is set we should use the specified ratio of the > heap as both min and max. This will be interpreted as "fixed" just > like the NewSize==MaxNewSize case above. But we will update the min > and max everytime the heap size changes. > > NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if > it is combined with either NewSize or MaxNewSize. (A warning message > is printed.) > > Thanks, > Bengt From lokesh.gidra at yahoo.com Wed Dec 21 09:21:30 2011 From: lokesh.gidra at yahoo.com (Lokesh Gidra) Date: Wed, 21 Dec 2011 14:51:30 +0530 (IST) Subject: Modification to the write barrier Message-ID: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> Hi, I want to make some modifications to the write barrier of the parallel scavenge GC. The changes I made are visible in interpreted mode, but not in JIT compiled code. Can someone please point me to the code location where I can find the code for write barrier for JIT compilation, so that I can run my test without -Xint option as well. Thanks in advance. Regards, Lokesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.rutisson at oracle.com Wed Dec 21 10:05:02 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Dec 2011 11:05:02 +0100 Subject: RFR(L): 6484965: G1: piggy-back liveness accounting phase on marking In-Reply-To: <4EF0DEF9.30306@oracle.com> References: <4E8A40BE.9020800@oracle.com> <4EC2B317.3000006@oracle.com> <4ED38788.4010106@oracle.com> <4EF0DEF9.30306@oracle.com> Message-ID: <4EF1AF4E.80107@oracle.com> Hi John, Thanks for updating your fix! Looks good. One quesiton: In concurrentMark.cpp it seems to me that the VerifyLiveObjectDataHRClosure could get the same kind of messed up output that Tony just fixed with 7123165 for the VerifyLiveClosure in heapRegion.cpp. There are several workers simultaneously doing the verification, right? Is it worth adding the same kind of locking that Tony added? Bengt On 2011-12-20 20:16, John Cuthbertson wrote: > Hi Bengt, > > As I mentioned earlier - thanks for the code review. I've applied your > suggestions, merged with the the latest changeset in > hsx/hotspot-gc/hotspot (resolving any conflicts), fixed the int <-> > size_t issue you also mentioned, and retested using the GC test suite. > A new webrev can be found at: > http://cr.openjdk.java.net/~johnc/6484965/webrev.2/ > > Specific replies are inline. > > On 11/28/11 05:07, Bengt Rutisson wrote: >> >> John, >> >> A little late, but here are some comments on this webrev. I know you >> have some more improvements to this change coming, but overall I >> think it looks good. Most of my comments are just minor coding style >> comments. >> >> Bengt >> >> concurrentMark.hpp >> >> Rename ConcurrentMark::clear() to ConcurrentMark::clear_mark() or >> ConcurrentMark::unmark()? The commment you added is definitely needed >> to understand what this method does. But it would be even better if >> it was possible to get that from the method name itself. > > Done. > >> It seems like everywhere we use count_marked_bytes_for(int worker_i) >> we almost directly use the array returned to index with the heap >> region that we are interested in. How about wrapping all of this is >> in something like count_set_marked_bytes_for(int worker_i, int >> hrs_index) and count_get_marked_bytes_for(int worker_i, int >> hrs_index) ? That way the data structure does not have to be exposed >> outside ConcurrentMark. It would mean that >> ConcurrentMark::count_region() would have to take a worker_i value >> instead of a marked_bytes_array. > > I did not do this. I embed the marked_bytes array for a worker into > the CMTask for that worker to save a de-reference. This was one of the > requests from the original code walk-through. Avoiding the > de-reference in the CMTask::do_marking_step() shaves a couple of > points off the marking time. I think your suggestion would reinstate > the de-reference again and we would lose those few percentage points > again. > >> If you don't agree with the suggestion above I would suggest to >> change the name from count_marked_bytes_for() to >> count_marked_bytes_array_for() since in every place that it is being >> called the resulting value is stored in a local variable called >> marked_bytes_array, which seems like a more informative name to me. > > Done. I agree - the new name sounds better. > >> I think this comment: >> >> // As above - but we don't know the heap region containing the >> // object and so have to supply it. >> inline bool par_mark_and_count(oop obj, int worker_i); >> >> should be something like "we don't know the heap region containing >> the object so we will have to look it up". >> >> Same thing here: >> >> // As above - but we don't have the heap region containing the >> // object, so we have to supply it. >> // Should *not* be called from parallel code. >> inline bool mark_and_count(oop obj); >> >> > > Comments were changed to: > > >> concurrentMark.cpp >> >> Since you are changing CalcLiveObjectsClosure::doHeapRegion() anyway, >> could you please remove this unused code (1393-1397): >> >> /* >> gclog_or_tty->print_cr("Setting bits from %d/%d.", >> obj_card_num - _bottom_card_num, >> obj_last_card_num - _bottom_card_num); >> */ >> >> > > Done. > >> What about the destructor ConcurrentMark::~ConcurrentMark() ? I >> remember Tony mentioning that it won't be called. Do you still want >> to keep the code? > > I removed the entire destructor - I don't see it being called in the > experiments I've run. > >> FinalCountDataUpdateClosure::set_bit_for_region() >> Probably not worth it, but would it make sense to add information in >> a startsHumongous HeapRegion to be able to give you the last >> continuesHumongous region? Since we know this when we set the regions >> up it seems like a waste to have to iterate over the region list to >> find it. > > If you read the original comment - the original author did not want to > make any assumptions about the internal field values of the > HeapRegions spanned by a humongous object and so used the loop > technique. I think you are correct and I now use the information in > the startsHumongous region to find the index of the last > continuesHumongous region spaned by the H-obj. > >> G1ParFinalCountTask >> To me it is a bit surprising that we mix in the verify code inside >> this closure. Would it be possible to extract this code out somehow? > > I did it this way to avoid another iteration over the heap regions. > But it probably does make more sense to separate them and use another > iteration to do the verify. Done. > >> Line 3378: "// Use fill_to_bytes". Is this something you plan on doing? > > I removed the comment. I was thinking of doing this as fill_to_bytes > is typically implemented using (a possibly specialized version of) > memset. But it's probably not worth it in this case. > >> G1ParFinalCountTask::work() >> Just for the record. I don't really like the way we have to set up >> both a VerifyLiveObjectDataHRClosure and a Mux2HRClosure even though >> we will only use them if we have VerifyDuringGC enabled. I realize it >> is due to the scoping, but I still think it obstucts the code flow >> and introduces unnecessary work. Unfortunately I don't have a good >> suggestion for how to work around it. >> >> Since both VerifyLiveObjectDataHRClosure and a Mux2HRClosure are >> StackObjs I assume it is not possible to get around the issue with a >> ResourceMark. > > Now that the verification is performed in a separate iteration of the > heap regions there's no need to create the > VerifyLiveObjectDataHRClosure and Mux2HRClosure instances here. Done. > I have also removed the now-redundant Mux2HRClosure. > > Hopefully the new webrev addresses these comments. > > Thanks again for looking. > > JohnC > From tony.printezis at oracle.com Wed Dec 21 10:21:05 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 05:21:05 -0500 Subject: RFR(S): 7121547: G1: High number mispredicted branches while iterating over the marking bitmap In-Reply-To: <4EF0CA08.8060206@oracle.com> References: <4EF0CA08.8060206@oracle.com> Message-ID: <4EF1B311.7080806@oracle.com> John, Please update the copyright year in bitMap.inline.hpp. Stylistic issues: 31 inline bool CMBitMapRO::iterate(BitMapClosure* cl, MemRegion mr) { 32 HeapWord* left = MAX2(_bmStartWord, mr.start()); 33 HeapWord* right = MIN2(_bmStartWord + _bmWordSize, mr.end()); ... 55 inline bool CMBitMapRO::iterate(BitMapClosure* cl) { 56 MemRegion mr(startWord(), sizeInWords()); ... Could you use in both cases either startWord() / sizeInWords() or _bmStartWord / _bmWordSize to be consistent? I had to go and check that the two were the same. Also, instead of left / right and start / end can you maybe use start_addr / end_addr and start_index / end_index to make the code a bit clearer? Regarding the weakening of the assert: I wonder why we haven't come across it before. I can only assume that so far iterations that have used this method have only given ranges that were aligned on bitmap word boundaries (if I understand correctly what the issue is!)? Can you maybe tighten it up a bit? I.e., if r_offset is bitmap word aligned -> res_offset < r_offset, otherwise -> res_offset < size()? Did analyzer show whether do_bit() is now getting inlined? Tony On 12/20/2011 12:46 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers review this small change? The webrev > can be found at: http://cr.openjdk.java.net/~johnc/7121547/webrev.0/ > > Summary: > While analyzing the data from some collect/analyze runs of the changes > for 6484965 (Piggy back liveness accounting on marking) it was noticed > that there was a significant number of mispredicted branches > associated with the actual call of BitMap::iterate() from within > CMBitMapRO::iterate(). With the changes in the webrev I can see a > slight reduction in the CPU time (a few percentage points), a slight > reduction in the number of L2 misses (again a few points), and between > a 20-40% drop in the number of mis-predicted branches. > > Testing: The GC test suite and Kitchensink (with low marking > thresholds); collect/analyze runs of SPECjbb2005; jprt. > > Thanks, > > JohnC From jon.masamitsu at oracle.com Wed Dec 21 12:02:25 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 21 Dec 2011 12:02:25 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 10 new changesets Message-ID: <20111221120247.B8C8847779@hg.openjdk.java.net> Changeset: 3b688d6ff3d0 Author: fparain Date: 2011-12-14 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3b688d6ff3d0 7104647: Adding a diagnostic command framework Reviewed-by: phh, dcubed ! src/share/vm/services/attachListener.cpp + src/share/vm/services/diagnosticArgument.cpp + src/share/vm/services/diagnosticArgument.hpp + src/share/vm/services/diagnosticCommand.cpp + src/share/vm/services/diagnosticCommand.hpp + src/share/vm/services/diagnosticFramework.cpp + src/share/vm/services/diagnosticFramework.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 31f6f10e4379 Author: vladidan Date: 2011-12-14 20:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/31f6f10e4379 Merge Changeset: 698a22e99f74 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/698a22e99f74 Added tag jdk8-b17 for changeset d1f29d4e0bc6 ! .hgtags Changeset: 09f3b8a372b2 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/09f3b8a372b2 Added tag jdk8-b16 for changeset d1f29d4e0bc6 ! .hgtags Changeset: e46c2339d0fc Author: katleman Date: 2011-12-15 15:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/e46c2339d0fc Merge ! .hgtags Changeset: a2fef924d8e6 Author: amurillo Date: 2011-12-16 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a2fef924d8e6 Merge ! .hgtags Changeset: 61165f53f165 Author: amurillo Date: 2011-12-16 12:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/61165f53f165 Added tag hs23-b08 for changeset a2fef924d8e6 ! .hgtags Changeset: 434acc838772 Author: amurillo Date: 2011-12-16 12:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/434acc838772 7122001: new hotspot build - hs23-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 129cd462ae89 Author: jmasa Date: 2011-12-20 12:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/129cd462ae89 Merge Changeset: d15b458c4225 Author: jmasa Date: 2011-12-20 20:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d15b458c4225 Merge From bengt.rutisson at oracle.com Wed Dec 21 12:22:55 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Dec 2011 13:22:55 +0100 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EF1A509.9070100@oracle.com> References: <4EEF329B.1060005@oracle.com> <4EF1A509.9070100@oracle.com> Message-ID: <4EF1CF9F.7070303@oracle.com> Tony, Thanks for the review! Good comments. I fixed them. Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7113021/webrev.03/ Bengt On 2011-12-21 10:21, Tony Printezis wrote: > Bengt, > > First, to repeat what I told you privately the other day: I really > liked the fact that you introduced the enum for the sizing policy. It > makes the code much easier to understand. I only have a couple of > minor comments: > > g1CollectorPolicy.cpp: > > Instead of having the asserts: > > 448 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, > "Min larger than max"); > 449 assert(G1DefaultMinNewGenPercent> 0&& > G1DefaultMinNewGenPercent< 100, "Min out of bounds"); > > 456 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, > "Min larger than max"); > 457 assert(G1DefaultMaxNewGenPercent> 0&& > G1DefaultMaxNewGenPercent< 100, "Max out of bounds"); > > at the start of calculate_default_{min,max}_size(), why don't you just > do those checks once in the G1YoungGenSizer constructor (i.e., treat > them like product params)? > > > g1CollectorPolicy.hpp: > > 100 // If only -XX:NewSize is set we should use the specified value > as the > 101 // minimum size for young gen. Still using 50% of the heap as > maximum. > 102 // > 103 // If only -XX:MaxNewSize is set we should use the specified > value as the > 104 // maximum size for young gen. Still using 20% of the heap as > minimum. > > Instead of saying 20% and 50%, why don't you just refer to the two > develop parameters, as those might change in the future? > > Apart from that, looks great! Ship it. > > Tony > > > On 12/19/2011 07:48 AM, Bengt Rutisson wrote: >> >> Hi everyone, >> >> Could I have a couple of reviews for this change? >> http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ >> >> The idea is to give G1 some room to allow it to use its heuristics >> for calculating the young gen size even when the heap size is fixed. >> >> CR: >> 7113021 G1: automatically enable young gen size auto-tuning when >> -Xms==-Xmx >> http://monaco.us.oracle.com/detail.jsf?cr=7113021 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 >> >> I introduce two new develop flags, G1DefaultMinNewGenPercent and >> G1DefaultMaxNewGenPercent. I will try to get the performance team to >> evaluate some good default values for these flags. Right now they are >> 20 and 50 respectively. This might change if we find that some other >> values are more appropriate. >> >> Background: >> >> There are three command line options related to the young gen size: >> NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is >> just a short form for NewSize==MaxNewSize). G1 will use its internal >> heuristics to calculate the actual young gen size, so these options >> basically only limit the range within which G1 can pick a young gen >> size. Also, these are general options taking byte sizes. G1 will >> internally work with a number of regions instead. So, some rounding >> will occur. >> >> The idea is that my fix should work pretty much as follows: >> >> If nothing related to the the young gen size is set on the command >> line we should allow the young gen to be between 20% and 50% of the >> heap size. This means that every time the heap size changes the >> limits for the young gen size will be updated. >> >> If only -XX:NewSize is set we should use the specified value as the >> minimum size for young gen. Still using 50% of the heap as maximum. >> >> If only -XX:MaxNewSize is set we should use the specified value as >> the maximum size for young gen. Still using 20% of the heap as minimum. >> >> If -XX:NewSize and -XX:MaxNewSize are both specified we use these >> values. No updates when the heap size changes. There is a special >> case when NewSize==MaxNewSize. This is interpreted as "fixed" and >> will use a different heuristic for calculating the collection set >> when we do mixed collection. >> >> If only -XX:NewRatio is set we should use the specified ratio of the >> heap as both min and max. This will be interpreted as "fixed" just >> like the NewSize==MaxNewSize case above. But we will update the min >> and max everytime the heap size changes. >> >> NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if >> it is combined with either NewSize or MaxNewSize. (A warning message >> is printed.) >> >> Thanks, >> Bengt From tony.printezis at oracle.com Wed Dec 21 12:48:15 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 07:48:15 -0500 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EF1CF9F.7070303@oracle.com> References: <4EEF329B.1060005@oracle.com> <4EF1A509.9070100@oracle.com> <4EF1CF9F.7070303@oracle.com> Message-ID: <4EF1D58F.8000805@oracle.com> Thanks, ship it. On 12/21/2011 07:22 AM, Bengt Rutisson wrote: > > Tony, > > Thanks for the review! > > Good comments. I fixed them. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7113021/webrev.03/ > > Bengt > > On 2011-12-21 10:21, Tony Printezis wrote: >> Bengt, >> >> First, to repeat what I told you privately the other day: I really >> liked the fact that you introduced the enum for the sizing policy. It >> makes the code much easier to understand. I only have a couple of >> minor comments: >> >> g1CollectorPolicy.cpp: >> >> Instead of having the asserts: >> >> 448 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >> "Min larger than max"); >> 449 assert(G1DefaultMinNewGenPercent> 0&& >> G1DefaultMinNewGenPercent< 100, "Min out of bounds"); >> >> 456 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >> "Min larger than max"); >> 457 assert(G1DefaultMaxNewGenPercent> 0&& >> G1DefaultMaxNewGenPercent< 100, "Max out of bounds"); >> >> at the start of calculate_default_{min,max}_size(), why don't you >> just do those checks once in the G1YoungGenSizer constructor (i.e., >> treat them like product params)? >> >> >> g1CollectorPolicy.hpp: >> >> 100 // If only -XX:NewSize is set we should use the specified value >> as the >> 101 // minimum size for young gen. Still using 50% of the heap as >> maximum. >> 102 // >> 103 // If only -XX:MaxNewSize is set we should use the specified >> value as the >> 104 // maximum size for young gen. Still using 20% of the heap as >> minimum. >> >> Instead of saying 20% and 50%, why don't you just refer to the two >> develop parameters, as those might change in the future? >> >> Apart from that, looks great! Ship it. >> >> Tony >> >> >> On 12/19/2011 07:48 AM, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Could I have a couple of reviews for this change? >>> http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ >>> >>> The idea is to give G1 some room to allow it to use its heuristics >>> for calculating the young gen size even when the heap size is fixed. >>> >>> CR: >>> 7113021 G1: automatically enable young gen size auto-tuning when >>> -Xms==-Xmx >>> http://monaco.us.oracle.com/detail.jsf?cr=7113021 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 >>> >>> I introduce two new develop flags, G1DefaultMinNewGenPercent and >>> G1DefaultMaxNewGenPercent. I will try to get the performance team to >>> evaluate some good default values for these flags. Right now they >>> are 20 and 50 respectively. This might change if we find that some >>> other values are more appropriate. >>> >>> Background: >>> >>> There are three command line options related to the young gen size: >>> NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is >>> just a short form for NewSize==MaxNewSize). G1 will use its internal >>> heuristics to calculate the actual young gen size, so these options >>> basically only limit the range within which G1 can pick a young gen >>> size. Also, these are general options taking byte sizes. G1 will >>> internally work with a number of regions instead. So, some rounding >>> will occur. >>> >>> The idea is that my fix should work pretty much as follows: >>> >>> If nothing related to the the young gen size is set on the command >>> line we should allow the young gen to be between 20% and 50% of the >>> heap size. This means that every time the heap size changes the >>> limits for the young gen size will be updated. >>> >>> If only -XX:NewSize is set we should use the specified value as the >>> minimum size for young gen. Still using 50% of the heap as maximum. >>> >>> If only -XX:MaxNewSize is set we should use the specified value as >>> the maximum size for young gen. Still using 20% of the heap as minimum. >>> >>> If -XX:NewSize and -XX:MaxNewSize are both specified we use these >>> values. No updates when the heap size changes. There is a special >>> case when NewSize==MaxNewSize. This is interpreted as "fixed" and >>> will use a different heuristic for calculating the collection set >>> when we do mixed collection. >>> >>> If only -XX:NewRatio is set we should use the specified ratio of the >>> heap as both min and max. This will be interpreted as "fixed" just >>> like the NewSize==MaxNewSize case above. But we will update the min >>> and max everytime the heap size changes. >>> >>> NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if >>> it is combined with either NewSize or MaxNewSize. (A warning message >>> is printed.) >>> >>> Thanks, >>> Bengt > From vitalyd at gmail.com Wed Dec 21 14:35:10 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 21 Dec 2011 09:35:10 -0500 Subject: Modification to the write barrier In-Reply-To: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> References: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> Message-ID: I *think* it's in src/share/vm/opto/macro.cpp and graphKit.cpp ... do a text search there and you'll find it On Dec 21, 2011 4:22 AM, "Lokesh Gidra" wrote: > Hi, > > I want to make some modifications to the write barrier of the parallel > scavenge GC. The changes I made are visible in interpreted mode, but not in > JIT compiled code. Can someone please point me to the code location where I > can find the code for write barrier for JIT compilation, so that I can run > my test without -Xint option as well. > > Thanks in advance. > > Regards, > Lokesh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Wed Dec 21 14:43:53 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 09:43:53 -0500 Subject: request for review (m) - 7121618 In-Reply-To: <4EF0D51F.8030400@oracle.com> References: <4EEF9190.90809@oracle.com> <4EF0D51F.8030400@oracle.com> Message-ID: <4EF1F0A9.1030501@oracle.com> Jon, Thanks for doing this cleanup! Only some minor nits: Is "...worker_id-th task queue" a valid expression? :-) Maybe "...task queue for worker_id"? concurrentMark.cpp: 1701 gclog_or_tty->print(" Worker thread %d [%8.3f..%8.3f = %8.3f ms] " 1702 "claimed %d regions (tot = %8.3f ms, max = %8.3f ms).\n", 1703 worker_id, start, end, (end-start)*1000.0, Now that worker_id is uint shouldn't "Worker thread %d..." be "Worker thread %u..."? 2921 int _worker_id; 3024 int _worker_id; 3056 int _worker_id; (and their uses) 3308 bool ConcurrentMark::do_yield_check(int worker_id) { You don't want to turn these into uint's too?) g1CollectorPolicy.cpp 2319 ParKnownGarbageHRClosure parKnownGarbageCl(_hrSorted, _chunk_size, 2320 worker_id); worker_id should be aligned with _hrSorted. genCollectedHeap.hpp 422 void set_par_threads(uint t); 423 424 Maybe remove one of the empty lines? referenceProcessor.hpp 271 uint num_q() { return _num_q; } 272 uint max_num_q() { return _max_num_q; } 273 void set_active_mt_degree(uint v) { _num_q = v; } Please re-align { _num_q = v; } with the two lines above it. workgroup.hpp 332 FlexibleWorkGang(const char* name, uint workers, 333 bool are_GC_task_threads, 334 bool are_ConcurrentGC_threads) : 335 WorkGang(name, workers, are_GC_task_threads, are_ConcurrentGC_threads), 336 _active_workers(UseDynamicNumberOfGCThreads ? 1U : ParallelGCThreads) {}; (not your fault) Why is there a semicolon at the end? Can you maybe remove it? 377 Monitor* monitor() { return&_monitor; } 378 uint n_workers() { return _n_workers; } 379 uint n_completed() { return _n_completed; } 380 bool should_reset() { return _should_reset; } Please re-align. Tony On 12/20/2011 01:34 PM, Jon Masamitsu wrote: > I've updated the webrev for review comments > (thanks, Bengt). > > http://cr.openjdk.java.net/~jmasa/7121618/webrev.01/ > > On 12/19/11 11:33, Jon Masamitsu wrote: >> This changes the type used for the number of GC threads to unsigned >> int from >> mostly size_t and changes corresponding variables that take the >> number of GC >> threads also to unsigned int. Some variables names were also changed in >> the process (principally "int i" in the work() method where "i" >> refers to >> the thread to "uint worker_id"). >> >> There are many changes but all are straightforward type or >> name changes. >> >> 7121618: Change type of number of GC workers to unsigned int. >> >> http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ >> >> Thanks. From jon.masamitsu at oracle.com Wed Dec 21 16:15:30 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Dec 2011 08:15:30 -0800 Subject: Modification to the write barrier In-Reply-To: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> References: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> Message-ID: <4EF20622.8060905@oracle.com> Forwarding to hotspot-compiler-dev. On 12/21/2011 1:21 AM, Lokesh Gidra wrote: > Hi, > > I want to make some modifications to the write barrier of the parallel scavenge GC. The changes I made are visible in interpreted mode, but not in JIT compiled code. Can someone please point me to the code location where I can find the code for write barrier for JIT compilation, so that I can run my test without -Xint option as well. > > Thanks in advance. > > Regards, > Lokesh > From john.cuthbertson at oracle.com Wed Dec 21 17:08:14 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 21 Dec 2011 09:08:14 -0800 Subject: RFR(L): 6484965: G1: piggy-back liveness accounting phase on marking In-Reply-To: <4EF1AF4E.80107@oracle.com> References: <4E8A40BE.9020800@oracle.com> <4EC2B317.3000006@oracle.com> <4ED38788.4010106@oracle.com> <4EF0DEF9.30306@oracle.com> <4EF1AF4E.80107@oracle.com> Message-ID: <4EF2127E.5050809@oracle.com> Hi Bengt, That's a good observation. I guess it is possible but I haven't seen it in practice (though I was typically only using 4 threads when debugging a verification failure). It won't do any harm so I'll add the locking. Thanks, JohnC On 12/21/2011 2:05 AM, Bengt Rutisson wrote: > > Hi John, > > Thanks for updating your fix! Looks good. > > One quesiton: > In concurrentMark.cpp it seems to me that the > VerifyLiveObjectDataHRClosure could get the same kind of messed up > output that Tony just fixed with 7123165 for the VerifyLiveClosure in > heapRegion.cpp. There are several workers simultaneously doing the > verification, right? Is it worth adding the same kind of locking that > Tony added? > > Bengt > > On 2011-12-20 20:16, John Cuthbertson wrote: >> Hi Bengt, >> >> As I mentioned earlier - thanks for the code review. I've applied >> your suggestions, merged with the the latest changeset in >> hsx/hotspot-gc/hotspot (resolving any conflicts), fixed the int <-> >> size_t issue you also mentioned, and retested using the GC test >> suite. A new webrev can be found at: >> http://cr.openjdk.java.net/~johnc/6484965/webrev.2/ >> >> Specific replies are inline. >> >> On 11/28/11 05:07, Bengt Rutisson wrote: >>> >>> John, >>> >>> A little late, but here are some comments on this webrev. I know you >>> have some more improvements to this change coming, but overall I >>> think it looks good. Most of my comments are just minor coding style >>> comments. >>> >>> Bengt >>> >>> concurrentMark.hpp >>> >>> Rename ConcurrentMark::clear() to ConcurrentMark::clear_mark() or >>> ConcurrentMark::unmark()? The commment you added is definitely >>> needed to understand what this method does. But it would be even >>> better if it was possible to get that from the method name itself. >> >> Done. >> >>> It seems like everywhere we use count_marked_bytes_for(int worker_i) >>> we almost directly use the array returned to index with the heap >>> region that we are interested in. How about wrapping all of this is >>> in something like count_set_marked_bytes_for(int worker_i, int >>> hrs_index) and count_get_marked_bytes_for(int worker_i, int >>> hrs_index) ? That way the data structure does not have to be exposed >>> outside ConcurrentMark. It would mean that >>> ConcurrentMark::count_region() would have to take a worker_i value >>> instead of a marked_bytes_array. >> >> I did not do this. I embed the marked_bytes array for a worker into >> the CMTask for that worker to save a de-reference. This was one of >> the requests from the original code walk-through. Avoiding the >> de-reference in the CMTask::do_marking_step() shaves a couple of >> points off the marking time. I think your suggestion would reinstate >> the de-reference again and we would lose those few percentage points >> again. >> >>> If you don't agree with the suggestion above I would suggest to >>> change the name from count_marked_bytes_for() to >>> count_marked_bytes_array_for() since in every place that it is being >>> called the resulting value is stored in a local variable called >>> marked_bytes_array, which seems like a more informative name to me. >> >> Done. I agree - the new name sounds better. >> >>> I think this comment: >>> >>> // As above - but we don't know the heap region containing the >>> // object and so have to supply it. >>> inline bool par_mark_and_count(oop obj, int worker_i); >>> >>> should be something like "we don't know the heap region containing >>> the object so we will have to look it up". >>> >>> Same thing here: >>> >>> // As above - but we don't have the heap region containing the >>> // object, so we have to supply it. >>> // Should *not* be called from parallel code. >>> inline bool mark_and_count(oop obj); >>> >>> >> >> Comments were changed to: >> >> >>> concurrentMark.cpp >>> >>> Since you are changing CalcLiveObjectsClosure::doHeapRegion() >>> anyway, could you please remove this unused code (1393-1397): >>> >>> /* >>> gclog_or_tty->print_cr("Setting bits from %d/%d.", >>> obj_card_num - _bottom_card_num, >>> obj_last_card_num - _bottom_card_num); >>> */ >>> >>> >> >> Done. >> >>> What about the destructor ConcurrentMark::~ConcurrentMark() ? I >>> remember Tony mentioning that it won't be called. Do you still want >>> to keep the code? >> >> I removed the entire destructor - I don't see it being called in the >> experiments I've run. >> >>> FinalCountDataUpdateClosure::set_bit_for_region() >>> Probably not worth it, but would it make sense to add information in >>> a startsHumongous HeapRegion to be able to give you the last >>> continuesHumongous region? Since we know this when we set the >>> regions up it seems like a waste to have to iterate over the region >>> list to find it. >> >> If you read the original comment - the original author did not want >> to make any assumptions about the internal field values of the >> HeapRegions spanned by a humongous object and so used the loop >> technique. I think you are correct and I now use the information in >> the startsHumongous region to find the index of the last >> continuesHumongous region spaned by the H-obj. >> >>> G1ParFinalCountTask >>> To me it is a bit surprising that we mix in the verify code inside >>> this closure. Would it be possible to extract this code out somehow? >> >> I did it this way to avoid another iteration over the heap regions. >> But it probably does make more sense to separate them and use another >> iteration to do the verify. Done. >> >>> Line 3378: "// Use fill_to_bytes". Is this something you plan on doing? >> >> I removed the comment. I was thinking of doing this as fill_to_bytes >> is typically implemented using (a possibly specialized version of) >> memset. But it's probably not worth it in this case. >> >>> G1ParFinalCountTask::work() >>> Just for the record. I don't really like the way we have to set up >>> both a VerifyLiveObjectDataHRClosure and a Mux2HRClosure even though >>> we will only use them if we have VerifyDuringGC enabled. I realize >>> it is due to the scoping, but I still think it obstucts the code >>> flow and introduces unnecessary work. Unfortunately I don't have a >>> good suggestion for how to work around it. >>> >>> Since both VerifyLiveObjectDataHRClosure and a Mux2HRClosure are >>> StackObjs I assume it is not possible to get around the issue with a >>> ResourceMark. >> >> Now that the verification is performed in a separate iteration of the >> heap regions there's no need to create the >> VerifyLiveObjectDataHRClosure and Mux2HRClosure instances here. >> Done. I have also removed the now-redundant Mux2HRClosure. >> >> Hopefully the new webrev addresses these comments. >> >> Thanks again for looking. >> >> JohnC >> > From jon.masamitsu at oracle.com Wed Dec 21 17:23:48 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 21 Dec 2011 09:23:48 -0800 Subject: request for review (m) - 7121618 In-Reply-To: <4EF0D51F.8030400@oracle.com> References: <4EEF9190.90809@oracle.com> <4EF0D51F.8030400@oracle.com> Message-ID: <4EF21624.4060707@oracle.com> I've updated the webrev for additional review comments (thanks, Tony) http://cr.openjdk.java.net/~jmasa/7121618/webrev.02/ On 12/20/2011 10:34 AM, Jon Masamitsu wrote: > I've updated the webrev for review comments > (thanks, Bengt). > > http://cr.openjdk.java.net/~jmasa/7121618/webrev.01/ > > On 12/19/11 11:33, Jon Masamitsu wrote: >> This changes the type used for the number of GC threads to unsigned >> int from >> mostly size_t and changes corresponding variables that take the >> number of GC >> threads also to unsigned int. Some variables names were also changed in >> the process (principally "int i" in the work() method where "i" >> refers to >> the thread to "uint worker_id"). >> >> There are many changes but all are straightforward type or >> name changes. >> >> 7121618: Change type of number of GC workers to unsigned int. >> >> http://cr.openjdk.java.net/~jmasa/7121618/webrev.00/ >> >> Thanks. From tom.rodriguez at oracle.com Wed Dec 21 17:46:07 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 21 Dec 2011 09:46:07 -0800 Subject: Modification to the write barrier In-Reply-To: <4EF20622.8060905@oracle.com> References: <1324459290.38586.YahooMailNeo@web137403.mail.in.yahoo.com> <4EF20622.8060905@oracle.com> Message-ID: <75922118-EB10-4B97-BED2-AC6700F5EAB6@oracle.com> On Dec 21, 2011, at 8:15 AM, Jon Masamitsu wrote: > Forwarding to hotspot-compiler-dev. > > On 12/21/2011 1:21 AM, Lokesh Gidra wrote: >> Hi, >> >> I want to make some modifications to the write barrier of the parallel scavenge GC. The changes I made are visible in interpreted mode, but not in JIT compiled code. Can someone please point me to the code location where I can find the code for write barrier for JIT compilation, so that I can run my test without -Xint option as well. The C2 barrier code is in src/share/vm/opto/graphKit.cpp and the C1 code is in src/share/vm/c1/c1_LIRGenerator.cpp. tom >> >> Thanks in advance. >> >> Regards, >> Lokesh >> From john.cuthbertson at oracle.com Wed Dec 21 18:04:42 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 21 Dec 2011 10:04:42 -0800 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EF1CF9F.7070303@oracle.com> References: <4EEF329B.1060005@oracle.com> <4EF1A509.9070100@oracle.com> <4EF1CF9F.7070303@oracle.com> Message-ID: <4EF21FBA.4010905@oracle.com> Hi Bengt, Looks good except for the following couple of items: g1_globals.hpp: 294 develop(uintx, G1DefaultMinNewGenPercent, 20, \ 295 "Percentage (0-100) of the heap size to use as minunimum " \ 296 "young gen size.") \ Should be "minimum". 298 develop(uintx, G1DefaultMaxNewGenPercent, 50, \ 299 "Percentage (0-100) of the heap size to use as minunimum " \ 300 "young gen size.") Should be "maximum". g1CollectorPolicy.[ch]pp: Can you rename calculate_default_min_size() to be something like "calculate_default_min_region_num()"? Similarly for calculate_default_max_size(). They return a number of regions rather than a size in bytes. Regards, JohnC On 12/21/2011 4:22 AM, Bengt Rutisson wrote: > > Tony, > > Thanks for the review! > > Good comments. I fixed them. Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7113021/webrev.03/ > > Bengt > > On 2011-12-21 10:21, Tony Printezis wrote: >> Bengt, >> >> First, to repeat what I told you privately the other day: I really >> liked the fact that you introduced the enum for the sizing policy. It >> makes the code much easier to understand. I only have a couple of >> minor comments: >> >> g1CollectorPolicy.cpp: >> >> Instead of having the asserts: >> >> 448 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >> "Min larger than max"); >> 449 assert(G1DefaultMinNewGenPercent> 0&& >> G1DefaultMinNewGenPercent< 100, "Min out of bounds"); >> >> 456 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >> "Min larger than max"); >> 457 assert(G1DefaultMaxNewGenPercent> 0&& >> G1DefaultMaxNewGenPercent< 100, "Max out of bounds"); >> >> at the start of calculate_default_{min,max}_size(), why don't you >> just do those checks once in the G1YoungGenSizer constructor (i.e., >> treat them like product params)? >> >> >> g1CollectorPolicy.hpp: >> >> 100 // If only -XX:NewSize is set we should use the specified value >> as the >> 101 // minimum size for young gen. Still using 50% of the heap as >> maximum. >> 102 // >> 103 // If only -XX:MaxNewSize is set we should use the specified >> value as the >> 104 // maximum size for young gen. Still using 20% of the heap as >> minimum. >> >> Instead of saying 20% and 50%, why don't you just refer to the two >> develop parameters, as those might change in the future? >> >> Apart from that, looks great! Ship it. >> >> Tony >> >> >> On 12/19/2011 07:48 AM, Bengt Rutisson wrote: >>> >>> Hi everyone, >>> >>> Could I have a couple of reviews for this change? >>> http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ >>> >>> The idea is to give G1 some room to allow it to use its heuristics >>> for calculating the young gen size even when the heap size is fixed. >>> >>> CR: >>> 7113021 G1: automatically enable young gen size auto-tuning when >>> -Xms==-Xmx >>> http://monaco.us.oracle.com/detail.jsf?cr=7113021 >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 >>> >>> I introduce two new develop flags, G1DefaultMinNewGenPercent and >>> G1DefaultMaxNewGenPercent. I will try to get the performance team to >>> evaluate some good default values for these flags. Right now they >>> are 20 and 50 respectively. This might change if we find that some >>> other values are more appropriate. >>> >>> Background: >>> >>> There are three command line options related to the young gen size: >>> NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is >>> just a short form for NewSize==MaxNewSize). G1 will use its internal >>> heuristics to calculate the actual young gen size, so these options >>> basically only limit the range within which G1 can pick a young gen >>> size. Also, these are general options taking byte sizes. G1 will >>> internally work with a number of regions instead. So, some rounding >>> will occur. >>> >>> The idea is that my fix should work pretty much as follows: >>> >>> If nothing related to the the young gen size is set on the command >>> line we should allow the young gen to be between 20% and 50% of the >>> heap size. This means that every time the heap size changes the >>> limits for the young gen size will be updated. >>> >>> If only -XX:NewSize is set we should use the specified value as the >>> minimum size for young gen. Still using 50% of the heap as maximum. >>> >>> If only -XX:MaxNewSize is set we should use the specified value as >>> the maximum size for young gen. Still using 20% of the heap as minimum. >>> >>> If -XX:NewSize and -XX:MaxNewSize are both specified we use these >>> values. No updates when the heap size changes. There is a special >>> case when NewSize==MaxNewSize. This is interpreted as "fixed" and >>> will use a different heuristic for calculating the collection set >>> when we do mixed collection. >>> >>> If only -XX:NewRatio is set we should use the specified ratio of the >>> heap as both min and max. This will be interpreted as "fixed" just >>> like the NewSize==MaxNewSize case above. But we will update the min >>> and max everytime the heap size changes. >>> >>> NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored if >>> it is combined with either NewSize or MaxNewSize. (A warning message >>> is printed.) >>> >>> Thanks, >>> Bengt > From tony.printezis at oracle.com Wed Dec 21 21:29:28 2011 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Wed, 21 Dec 2011 21:29:28 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7119027: G1: use atomics to update RS length / predict time of inc CSet Message-ID: <20111221212930.D128E4777F@hg.openjdk.java.net> Changeset: 67fdcb391461 Author: tonyp Date: 2011-12-21 07:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/67fdcb391461 7119027: G1: use atomics to update RS length / predict time of inc CSet Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way. Reviewed-by: brutisso, iveresov ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp From bengt.rutisson at oracle.com Wed Dec 21 22:07:35 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Dec 2011 23:07:35 +0100 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EF21FBA.4010905@oracle.com> References: <4EEF329B.1060005@oracle.com> <4EF1A509.9070100@oracle.com> <4EF1CF9F.7070303@oracle.com> <4EF21FBA.4010905@oracle.com> Message-ID: <4EF258A7.8060208@oracle.com> Hi John, Thanks for the review! Some comments inline. On 2011-12-21 19:04, John Cuthbertson wrote: > Hi Bengt, > > Looks good except for the following couple of items: > > g1_globals.hpp: > > 294 develop(uintx, G1DefaultMinNewGenPercent, > 20, \ > 295 "Percentage (0-100) of the heap size to use as > minunimum " \ > 296 "young gen > size.") \ > > Should be "minimum". > > 298 develop(uintx, G1DefaultMaxNewGenPercent, > 50, \ > 299 "Percentage (0-100) of the heap size to use as > minunimum " \ > 300 "young gen size.") > > Should be "maximum". Thanks for detecting this! Fixed it. > g1CollectorPolicy.[ch]pp: > > Can you rename calculate_default_min_size() to be something like > "calculate_default_min_region_num()"? Similarly for > calculate_default_max_size(). They return a number of regions rather > than a size in bytes. Good point. How about calculate_default_min_length() since the variables we set are called *_length and I think we often refer to the young gen "size" as the length? Here is an updated webrev: http://cr.openjdk.java.net/~brutisso/7113021/webrev.04/ Thanks again for the review! Bengt > > Regards, > > JohnC > > > On 12/21/2011 4:22 AM, Bengt Rutisson wrote: >> >> Tony, >> >> Thanks for the review! >> >> Good comments. I fixed them. Here is an updated webrev: >> http://cr.openjdk.java.net/~brutisso/7113021/webrev.03/ >> >> Bengt >> >> On 2011-12-21 10:21, Tony Printezis wrote: >>> Bengt, >>> >>> First, to repeat what I told you privately the other day: I really >>> liked the fact that you introduced the enum for the sizing policy. >>> It makes the code much easier to understand. I only have a couple of >>> minor comments: >>> >>> g1CollectorPolicy.cpp: >>> >>> Instead of having the asserts: >>> >>> 448 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >>> "Min larger than max"); >>> 449 assert(G1DefaultMinNewGenPercent> 0&& >>> G1DefaultMinNewGenPercent< 100, "Min out of bounds"); >>> >>> 456 assert(G1DefaultMinNewGenPercent<= G1DefaultMaxNewGenPercent, >>> "Min larger than max"); >>> 457 assert(G1DefaultMaxNewGenPercent> 0&& >>> G1DefaultMaxNewGenPercent< 100, "Max out of bounds"); >>> >>> at the start of calculate_default_{min,max}_size(), why don't you >>> just do those checks once in the G1YoungGenSizer constructor (i.e., >>> treat them like product params)? >>> >>> >>> g1CollectorPolicy.hpp: >>> >>> 100 // If only -XX:NewSize is set we should use the specified value >>> as the >>> 101 // minimum size for young gen. Still using 50% of the heap as >>> maximum. >>> 102 // >>> 103 // If only -XX:MaxNewSize is set we should use the specified >>> value as the >>> 104 // maximum size for young gen. Still using 20% of the heap as >>> minimum. >>> >>> Instead of saying 20% and 50%, why don't you just refer to the two >>> develop parameters, as those might change in the future? >>> >>> Apart from that, looks great! Ship it. >>> >>> Tony >>> >>> >>> On 12/19/2011 07:48 AM, Bengt Rutisson wrote: >>>> >>>> Hi everyone, >>>> >>>> Could I have a couple of reviews for this change? >>>> http://cr.openjdk.java.net/~brutisso/7113021/webrev.02/ >>>> >>>> The idea is to give G1 some room to allow it to use its heuristics >>>> for calculating the young gen size even when the heap size is fixed. >>>> >>>> CR: >>>> 7113021 G1: automatically enable young gen size auto-tuning when >>>> -Xms==-Xmx >>>> http://monaco.us.oracle.com/detail.jsf?cr=7113021 >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7113021 >>>> >>>> I introduce two new develop flags, G1DefaultMinNewGenPercent and >>>> G1DefaultMaxNewGenPercent. I will try to get the performance team >>>> to evaluate some good default values for these flags. Right now >>>> they are 20 and 50 respectively. This might change if we find that >>>> some other values are more appropriate. >>>> >>>> Background: >>>> >>>> There are three command line options related to the young gen size: >>>> NewSize, MaxNewSize and NewRatio (There is also -Xmn, but that is >>>> just a short form for NewSize==MaxNewSize). G1 will use its >>>> internal heuristics to calculate the actual young gen size, so >>>> these options basically only limit the range within which G1 can >>>> pick a young gen size. Also, these are general options taking byte >>>> sizes. G1 will internally work with a number of regions instead. >>>> So, some rounding will occur. >>>> >>>> The idea is that my fix should work pretty much as follows: >>>> >>>> If nothing related to the the young gen size is set on the command >>>> line we should allow the young gen to be between 20% and 50% of the >>>> heap size. This means that every time the heap size changes the >>>> limits for the young gen size will be updated. >>>> >>>> If only -XX:NewSize is set we should use the specified value as the >>>> minimum size for young gen. Still using 50% of the heap as maximum. >>>> >>>> If only -XX:MaxNewSize is set we should use the specified value as >>>> the maximum size for young gen. Still using 20% of the heap as >>>> minimum. >>>> >>>> If -XX:NewSize and -XX:MaxNewSize are both specified we use these >>>> values. No updates when the heap size changes. There is a special >>>> case when NewSize==MaxNewSize. This is interpreted as "fixed" and >>>> will use a different heuristic for calculating the collection set >>>> when we do mixed collection. >>>> >>>> If only -XX:NewRatio is set we should use the specified ratio of >>>> the heap as both min and max. This will be interpreted as "fixed" >>>> just like the NewSize==MaxNewSize case above. But we will update >>>> the min and max everytime the heap size changes. >>>> >>>> NewSize and MaxNewSize override NewRatio. So, NewRatio is ignored >>>> if it is combined with either NewSize or MaxNewSize. (A warning >>>> message is printed.) >>>> >>>> Thanks, >>>> Bengt >> > From john.cuthbertson at oracle.com Wed Dec 21 22:08:31 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Wed, 21 Dec 2011 14:08:31 -0800 Subject: Request for review (S): 7113021 G1: automatically enable young gen size auto-tuning when -Xms==-Xmx In-Reply-To: <4EF258A7.8060208@oracle.com> References: <4EEF329B.1060005@oracle.com> <4EF1A509.9070100@oracle.com> <4EF1CF9F.7070303@oracle.com> <4EF21FBA.4010905@oracle.com> <4EF258A7.8060208@oracle.com> Message-ID: <4EF258DF.6060504@oracle.com> Hi Bengt, On 12/21/11 14:07, Bengt Rutisson wrote: >> >> Can you rename calculate_default_min_size() to be something like >> "calculate_default_min_region_num()"? Similarly for >> calculate_default_max_size(). They return a number of regions rather >> than a size in bytes. > g1CollectorPolicy.[ch]pp: > > Good point. How about calculate_default_min_length() since the > variables we set are called *_length and I think we often refer to the > young gen "size" as the length? That's fine with me. > Here is an updated webrev: > http://cr.openjdk.java.net/~brutisso/7113021/webrev.04/ > > Thanks again for the review! > Bengt Looks good. Ship it. JohnC From tony.printezis at oracle.com Wed Dec 21 22:25:05 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 17:25:05 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EE9208B.5040203@oracle.com> References: <4EE9208B.5040203@oracle.com> Message-ID: <4EF25CC1.6030105@oracle.com> Hi all, I have two code reviews (thanks to John and Ramki!). Can I push or is anybody else still looking at this? Tony On 12/14/2011 05:17 PM, Tony Printezis wrote: > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ > > The CR has a bit more explanation. The short version is that I'm now > encoding the "start index of the next chunk" in the from-space length > field of a chunked array (say *that* quickly!) as a negative value to > always be able to distinguish it from the real length. This will > simplify the code for the CR John is currently working on (6484965) > but it's a small, self-contained change so it's good to get it code > reviewed and pushed separately. > > Tony > > From tony.printezis at oracle.com Wed Dec 21 22:37:44 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 21 Dec 2011 17:37:44 -0500 Subject: CRR (L): 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces Message-ID: <4EF25FB8.5050507@oracle.com> Hi all, I'd like a couple of code reviews for the following non-trivial changes (large, not necessary in lines of code modified but more due to the fact that the evacuation pause / concurrent marking interaction is changed quite dramatically): http://cr.openjdk.java.net/~tonyp/6888336/webrev.0/ Here's some background, motivation, and a summary of the changes (I felt that it was important to write a longer then usual explanation): * Background / Motivation Each G1 heap region has a field top-at-mark-start (aka TAMS) which denotes where the top of the region was when marking started. An object is considered implicitly live if it's over TAMS (i.e., it was allocated since marking started) or explicitly live if it's below TAMS (i.e., it was allocated before marking started) and marked on the bitmap. (It follows that it's unnecessary to explicitly mark objects over TAMS.) In fact, we have two copies of the above marking information: "Next TAMS / Next Bitmap" and "Prev TAMS / Prev Bitmap". Prev is the copy that was obtained by the last marking cycle that was successfully completed (so, it is consistent: all live objects should appear as live in the prev marking information). Next is the copy that will be obtained / is currently being obtained and it's not consistent because it's not guaranteed to be complete. G1 uses SATB marking which has the advantage not to require objects allocated since the start of marking to be visited at all by the marking threads (they are implicitly live and they do not need to be scanned). So, the active marking cycle can totally ignore objects over NTAMS (since they have been allocated since marking started). The current interaction between evacuation pauses (let's call these "GCs" from now on) and concurrent marking is very tricky. Even though marking ignores all objects over NTAMS (currently: all objects in Eden regions) it still has to visit and mark objects in the Survivors regions. But those will be moved by subsequent GCs. So, a GC needs to be aware that it's moving objects that have been marked by the marking threads and not only propagate those marks but also notify the marking threads that said objects have been moved. For that we use several data structures: pushes to the global marking stack and also to what's referred to as the "region stack" which is only used by the GC to push a group of objects instead of pushing them individually ("region" here is a mem region and smaller than a G1 region). Additionally, because the marking threads could come across objects that could potentially move we have to make sure that we don't leave references to regions that have been evacuated on any marking data structure. To do that we treat as roots all entries on the taskqueues / global stack and drained all SATB buffers (both active buffers and also enqueued buffers). The first issue with the above interaction is that it has performance issues. Draining all SATB buffers and scanning the mark stack and taskqueues has been shown to be very time-consuming in some cases. Also, having to check whether objects are marked and propagate the marks appropriately during GC is an extra overhead. The second issue is that it has been shown to be very fragile. We have discovered and fixed many issues over time which were subtle and hard to reproduce. We really need to simplify the GC/marking interaction to both improve performance of GCs during marking, as well as improve our reliability. This changeset does exactly that. * Explanation of the changes The goal is to ensure that all the objects that are copied by the GC do not need to be visited by the marking threads and as a result do not need to be explicitly marked, pushed, etc. The first observation is that most objects copied during a GC are allocated after marking starts and are therefore implicitly live. This is the case for all objects on Eden regions, as well as most objects on Survivor regions. The only exception are objects on the Survivor regions during the initial-mark pause. Unfortunately, it's not easy to track those separately as they will get mixed in with future Survivors. The first decision to deal with this is to turn off Survivors during the initial-mark pause. This ensures that all objects copied during each subsequent GC will only visit objects that have been allocated since marking started and are therefore implicitly live (i.e., over NTAMS). This allows us to totally eliminate that code that propagates marks during the GC. We just have to make sure that all copied objects are over NTAMS. Turning off Survivors during an initial-mark pause is a bit of a "big hammer" approach, but it will suffice for now. We have ideas on how to re-enable them in the future and we'll explore a couple of alternatives. Given that the GC only copies objects that are implicitly marked it follows that none of the objects that are copied during any GC should appear on either the taskqueues nor the global marking stack. Also remember that we filter SATB buffers before enqueueing them which will filter out all implicitly marked objects. It follows that no enqueued SATB buffer should have references to objects that are being moved. This leaves the currently active SATB buffers given that the code that populates them is unconditional. But if we run the filtering on those during each GC such "offending" references are also quickly eliminated. So, instead of having to scan all stacks and all SATB buffers we only have to filter the active SATB buffers, which should be much, much faster. * Implementation Notes The actual changes are not too extensive as they basically mostly disable functionality in the GC code. The tricky part was to get the TAMS fields correct at various phases (start of copying, start of marking, etc.) and especially when an evacuation failure occurs. I put all that functionality in methods on HeapRegion which do the right thing when a GC starts, a marking starts, etc. The most important changes are in the "main" GC code, i.e. G1ParCopyHelper::do_oop_work() and G1ParCopyHelper::copy_to_survivor_space(). Instead of having to propagate marks we only now need to mark objects directly reachable from roots during the initial-mark pause. The resulting code is much simplified (and hopefully more performant!). I also added a method verify_no_cset_oops() which checks that indeed all the marking data structures do not point to regions that are being GCed at the start / end of each GC. (BTW, I'm considering adding a develop flag to enable this on demand.) I should point out that this changeset will leave a lot of dead code. However, I took the decision to keep the changes to a minimum in order not overwhelm the code reviewers and make the important changes clearer. (I also discussed this with a couple of potential code reviewers and they agreed that this is a good approach.) I temporarily added guarantees to ensure that methods that should not be called are not called. I will remove all dead code with a future push. I also have to apologize to John Cuthbertson for removing a lot of code he's added to deal with various bugs we had in the GC/marking interaction. Hopefully the new code will be less fragile compared to what we've had so far and John will be able to concentrate on more interesting features than trying to track down hard-to-reproduce failures! Tony From ysr1729 at gmail.com Thu Dec 22 06:31:57 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Wed, 21 Dec 2011 22:31:57 -0800 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EF19E6D.2090200@oracle.com> References: <4EE9208B.5040203@oracle.com> <4EF19E6D.2090200@oracle.com> Message-ID: Thanks Tony for the clear explanation of the context!. So did you have any opinion about the second part of my email below? (not that that issue needs to be done in this CR or anything, but just thought it would be nice to have all scavengers use this encoding.) -- ramki On Wed, Dec 21, 2011 at 12:53 AM, Tony Printezis wrote: > Ramki, > > Thanks for looking at this! Here's an explanation why we need this: > > (As you know!) in G1 we don't have an initial-mark pause and we piggy-back > marking the roots on an evacuation pause. This means that we might have to > mark an object we are copying / have copied. This is mostly straightforward > and it's been in G1 for quite a while. > > John is working on some changes to piggy-back liveness counting on the > marking phase. For that we need to know the size of each object we mark. > For objects that are being moved this is not as straightforward. Consider > the case where a thread is scanning a root that points to an object being > copied by another thread. Even though we know the reference to the > from-/to-images we do not know whether the to-image is actually complete > given that an object gets forwarded first, then copied and there's no easy > way to find out whether it's been copied or not without some additional > synchronization which it'd be good to avoid: we only need this during > initial-mark pauses which are infrequent. > > One idea is to always read the size from the from-image, which works mots > of the time apart from the case where the object is a chunked object array > since we use its length to store how much of the object we have not > processed yet (and without its length we cannot work out its size). Again, > currently there's no way to determine whether the length is the actual > length or an encoded index given that they both look like ints >= 0. > Encoding it as a negative integer, which is what this changeset does, > allows us to distinguish a valid length (>=0) from an encoded index (<0). > > FWIW, here's the code (from a follow-up changeset) that relies on this > encoding to calculate the size of a forwarded object (old -> from-image, > obj -> to-image): > > int size; > if (!old->is_objArray()) { > // The easy case. This is safe, the from-image of all non-object > // arrays should be well formed. > size = old->size(); > } else { > objArrayOop array_old = objArrayOop(old); > int length = array_old->length(); > if (length < 0) { > // It's been chunked so we cannot trust the from-image. We will > // get the size from the to-image which we know is well formed > // (copy is finished before the length becomes negative). > objArrayOop array_obj = objArrayOop(obj); > length = array_obj->length(); > } else { > // Because the length is positive we know it's correct, i.e. the > // array is not being chunked right now. > } > size = objArrayOopDesc::object_size(length); > } > > Hope this clears things up. > > Tony > > > On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote: > > Hi Tony -- > > For some reason, I cannot seem to be able to view either of the CR's you > mention below, and thus > lack the requisite background context for this change. The localized > change however looks fine, > and it is nice to distinguish the two states of the array in this way by > means of the sign of the length field. > > One question is whether, for the sake of debugging & representational > uniformity, it would make sense to use the same > encoding in the other collectors that do this chunking (even though I > understand they may not have > the need to deal with 6484965, whatever that might be :-) > > Reviewed! > -- ramki > > On Wed, Dec 14, 2011 at 2:17 PM, Tony Printezis > wrote: > >> Hi all, >> >> Can I have a couple of code review for this small change? >> >> http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ >> >> The CR has a bit more explanation. The short version is that I'm now >> encoding the "start index of the next chunk" in the from-space length field >> of a chunked array (say *that* quickly!) as a negative value to always be >> able to distinguish it from the real length. This will simplify the code >> for the CR John is currently working on (6484965) but it's a small, >> self-contained change so it's good to get it code reviewed and pushed >> separately. >> >> Tony >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Thu Dec 22 08:23:33 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Thu, 22 Dec 2011 03:23:33 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: References: <4EE9208B.5040203@oracle.com> <4EF19E6D.2090200@oracle.com> Message-ID: <4EF2E905.6020108@oracle.com> Ramki, (sorry, I forgot to answer your question) We could implement the same encoding on the other GCs but I'm not sure whether it's worth it. Of course, if we had the encoding / decoding code factored out we could have done it with no much effort. :-) Tony On 12/22/2011 01:31 AM, Srinivas Ramakrishna wrote: > Thanks Tony for the clear explanation of the context!. So did you have > any opinion about the second part of my email below? (not that > that issue needs to be done in this CR or anything, but just thought > it would be nice to have all scavengers use this encoding.) > > -- ramki > > > On Wed, Dec 21, 2011 at 12:53 AM, Tony Printezis > > wrote: > > Ramki, > > Thanks for looking at this! Here's an explanation why we need this: > > (As you know!) in G1 we don't have an initial-mark pause and we > piggy-back marking the roots on an evacuation pause. This means > that we might have to mark an object we are copying / have copied. > This is mostly straightforward and it's been in G1 for quite a while. > > John is working on some changes to piggy-back liveness counting on > the marking phase. For that we need to know the size of each > object we mark. For objects that are being moved this is not as > straightforward. Consider the case where a thread is scanning a > root that points to an object being copied by another thread. Even > though we know the reference to the from-/to-images we do not know > whether the to-image is actually complete given that an object > gets forwarded first, then copied and there's no easy way to find > out whether it's been copied or not without some additional > synchronization which it'd be good to avoid: we only need this > during initial-mark pauses which are infrequent. > > One idea is to always read the size from the from-image, which > works mots of the time apart from the case where the object is a > chunked object array since we use its length to store how much of > the object we have not processed yet (and without its length we > cannot work out its size). Again, currently there's no way to > determine whether the length is the actual length or an encoded > index given that they both look like ints >= 0. Encoding it as a > negative integer, which is what this changeset does, allows us to > distinguish a valid length (>=0) from an encoded index (<0). > > FWIW, here's the code (from a follow-up changeset) that relies on > this encoding to calculate the size of a forwarded object (old -> > from-image, obj -> to-image): > > int size; > if (!old->is_objArray()) { > // The easy case. This is safe, the from-image of all non-object > // arrays should be well formed. > size = old->size(); > } else { > objArrayOop array_old = objArrayOop(old); > int length = array_old->length(); > if (length < 0) { > // It's been chunked so we cannot trust the from-image. We will > // get the size from the to-image which we know is well formed > // (copy is finished before the length becomes negative). > objArrayOop array_obj = objArrayOop(obj); > length = array_obj->length(); > } else { > // Because the length is positive we know it's correct, i.e. the > // array is not being chunked right now. > } > size = objArrayOopDesc::object_size(length); > } > > Hope this clears things up. > > Tony > > > On 12/21/2011 01:34 AM, Srinivas Ramakrishna wrote: >> Hi Tony -- >> >> For some reason, I cannot seem to be able to view either of the >> CR's you mention below, and thus >> lack the requisite background context for this change. The >> localized change however looks fine, >> and it is nice to distinguish the two states of the array in this >> way by means of the sign of the length field. >> >> One question is whether, for the sake of debugging & >> representational uniformity, it would make sense to use the same >> encoding in the other collectors that do this chunking (even >> though I understand they may not have >> the need to deal with 6484965, whatever that might be :-) >> >> Reviewed! >> -- ramki >> >> On Wed, Dec 14, 2011 at 2:17 PM, Tony Printezis >> > wrote: >> >> Hi all, >> >> Can I have a couple of code review for this small change? >> >> http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ >> >> >> The CR has a bit more explanation. The short version is that >> I'm now encoding the "start index of the next chunk" in the >> from-space length field of a chunked array (say *that* >> quickly!) as a negative value to always be able to >> distinguish it from the real length. This will simplify the >> code for the CR John is currently working on (6484965) but >> it's a small, self-contained change so it's good to get it >> code reviewed and pushed separately. >> >> Tony >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Thu Dec 22 09:47:03 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Thu, 22 Dec 2011 09:47:03 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7121618: Change type of number of GC workers to unsigned int. Message-ID: <20111222094707.3E48E4778D@hg.openjdk.java.net> Changeset: 441e946dc1af Author: jmasa Date: 2011-12-14 13:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/441e946dc1af 7121618: Change type of number of GC workers to unsigned int. Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id). Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp From bengt.rutisson at oracle.com Thu Dec 22 23:45:20 2011 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Thu, 22 Dec 2011 23:45:20 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Message-ID: <20111222234522.AC3134779E@hg.openjdk.java.net> Changeset: 1cbe7978b021 Author: brutisso Date: 2011-12-21 22:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/1cbe7978b021 7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp From john.coomes at oracle.com Fri Dec 23 05:21:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:21:17 +0000 Subject: hg: hsx/hotspot-gc: Added tag jdk8-b18 for changeset 7010bd24cdd0 Message-ID: <20111223052117.8D252477B9@hg.openjdk.java.net> Changeset: e1fc13802e0c Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/e1fc13802e0c Added tag jdk8-b18 for changeset 7010bd24cdd0 ! .hgtags From john.coomes at oracle.com Fri Dec 23 05:21:24 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:21:24 +0000 Subject: hg: hsx/hotspot-gc/corba: Added tag jdk8-b18 for changeset 312cf15d1657 Message-ID: <20111223052126.47EA6477BA@hg.openjdk.java.net> Changeset: 46bd4a46a5a8 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/46bd4a46a5a8 Added tag jdk8-b18 for changeset 312cf15d1657 ! .hgtags From john.coomes at oracle.com Fri Dec 23 05:21:36 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:21:36 +0000 Subject: hg: hsx/hotspot-gc/jaxp: Added tag jdk8-b18 for changeset ebec6a7e8d4e Message-ID: <20111223052136.B2513477BB@hg.openjdk.java.net> Changeset: 5fb25931f1c2 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/5fb25931f1c2 Added tag jdk8-b18 for changeset ebec6a7e8d4e ! .hgtags From john.coomes at oracle.com Fri Dec 23 05:21:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:21:43 +0000 Subject: hg: hsx/hotspot-gc/jaxws: Added tag jdk8-b18 for changeset 54928c8850f5 Message-ID: <20111223052143.BDA8B477BC@hg.openjdk.java.net> Changeset: 72d410c3bab1 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/72d410c3bab1 Added tag jdk8-b18 for changeset 54928c8850f5 ! .hgtags From john.coomes at oracle.com Fri Dec 23 05:22:41 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:22:41 +0000 Subject: hg: hsx/hotspot-gc/jdk: 6 new changesets Message-ID: <20111223052403.BFD1C477BD@hg.openjdk.java.net> Changeset: 134420afe9c2 Author: ngthomas Date: 2011-11-13 21:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/134420afe9c2 7109885: security baseline for 7u2 or above is not set correctly Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: 6f594239e9dc Author: ngthomas Date: 2011-11-15 23:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f594239e9dc 7112298: remove security baseline sanity check Reviewed-by: ccheung, igor, ohair ! make/common/shared/Sanity.gmk Changeset: fcc7cafa0027 Author: herrick Date: 2011-11-18 06:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/fcc7cafa0027 Merge - make/sun/rmi/rmi/mapfile-vers - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java - src/share/classes/sun/security/x509/CertAndKeyGen.java - src/share/native/sun/rmi/server/MarshalInputStream.c - test/java/net/DatagramSocket/ChangingAddress.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java Changeset: 526e99f06a59 Author: igor Date: 2011-12-06 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/526e99f06a59 Merge - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/io/etc/FileDescriptorSharing.java Changeset: 334bd51fb3f3 Author: igor Date: 2011-12-19 10:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/334bd51fb3f3 Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: c6fab5332075 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c6fab5332075 Added tag jdk8-b18 for changeset 334bd51fb3f3 ! .hgtags From john.coomes at oracle.com Fri Dec 23 05:27:07 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 23 Dec 2011 05:27:07 +0000 Subject: hg: hsx/hotspot-gc/langtools: 14 new changesets Message-ID: <20111223052740.7F2F3477BE@hg.openjdk.java.net> Changeset: c896d95e7469 Author: mcimadamore Date: 2011-11-24 13:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/c896d95e7469 7115046: Add AST node for lambda expressions Summary: Add tree nodes for representing lambda expressions and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: ec59a2ce9114 Author: mcimadamore Date: 2011-11-24 13:38 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ec59a2ce9114 7115049: Add AST node for method references Summary: Add tree nodes for representing method/constructor references and update relevant visitors interfaces Reviewed-by: jjg + src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java Changeset: 9448fe783fd2 Author: mcimadamore Date: 2011-11-28 15:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9448fe783fd2 7115050: Add parser support for lambda expressions Summary: Add support for parsing lambda expressions to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Lexer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/diags/examples/LambdaNotSupported.java + test/tools/javac/diags/examples/NotAStatement.java ! test/tools/javac/generics/rare/6665356/T6665356.out + test/tools/javac/lambda/LambdaParserTest.java Changeset: 3343b22e2761 Author: mcimadamore Date: 2011-11-28 16:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3343b22e2761 7115052: Add parser support for method references Summary: Add support for parsing method references to JavacParser Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/IllegalChar.java + test/tools/javac/diags/examples/MethodReferencesNotSupported.java + test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/quid/T6999438.out Changeset: 2584f5358cba Author: lana Date: 2011-12-06 20:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/2584f5358cba Merge Changeset: abfa0d8ea803 Author: ksrini Date: 2011-12-07 10:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/abfa0d8ea803 7086015: fix test/tools/javac/parser/netbeans/JavacParserTest.java Reviewed-by: ksrini, jjg Contributed-by: matherey.nunez at oracle.com ! test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 9350d0498d21 Author: ksrini Date: 2011-12-09 08:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/9350d0498d21 7119032: (javac) increase visibility of JavacParser methods to improve subtyping Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java Changeset: e7d5e1a7cde5 Author: ksrini Date: 2011-12-10 17:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e7d5e1a7cde5 7119487: JavacParserTest.java test fails on Windows platforms Reviewed-by: jjg + test/tools/javac/parser/JavacParserTest.java - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: e55270a7a022 Author: mcimadamore Date: 2011-12-11 17:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/e55270a7a022 7120266: javac fails to compile hotspot code Summary: Parser changes for method references cause bad intercation with method call syntax Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T7120266.java ! test/tools/javac/lambda/MethodReferenceParserTest.java Changeset: 1cbe86c11ba6 Author: lana Date: 2011-12-12 10:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/1cbe86c11ba6 Merge - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 55a49c399603 Author: katleman Date: 2011-12-15 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/55a49c399603 Added tag jdk8-b17 for changeset 1cbe86c11ba6 ! .hgtags Changeset: 29a512337b79 Author: katleman Date: 2011-12-15 15:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/29a512337b79 Added tag jdk8-b16 for changeset ec2c0973cc31 ! .hgtags Changeset: ab1b1cc78577 Author: katleman Date: 2011-12-15 15:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/ab1b1cc78577 Merge ! .hgtags - test/tools/javac/parser/netbeans/JavacParserTest.java Changeset: 3c71fcc22b99 Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/langtools/rev/3c71fcc22b99 Added tag jdk8-b18 for changeset ab1b1cc78577 ! .hgtags From tony.printezis at oracle.com Fri Dec 23 08:37:12 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 23 Dec 2011 03:37:12 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EF25CC1.6030105@oracle.com> References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> Message-ID: <4EF43DB8.1080104@oracle.com> Hi all, I have some bad news, it turns out that there's a subtle race in the code. I've been testing the marking changes for quite a while now (which rely on this patch) and I got a single failure. I'm pretty sure it's the race I describe below. BTW, there's a question at the end of the e-mail. :-) Let's assume two threads, A and B, are racing to forward the same object array X. Consider the following interleaving: Thread A: is X forwarded? no Thread B: is X forwarded? no size = X.size(); X' = allocate size try to forward X to X'? yes copy X to X' chunk X, X.length is negative Thread A: size = X.size(); -> BOOM, as size() just read a negative length Interesting this race exists today but it's benign due to either careful design or sheer luck. When A reads size = X.size() it will actually get a smaller size than the actual size of X and will allocate a chunk smaller than X (!!!). However, given that X is already forwarded it won't need to copy it and will undo the allocation. So, no harm done. Question: Is there a reason why we use the from-space length field to encode the next index instead of the to-space length field? If we used the latter we can simplify the code by quite a lot. I can't immediately think of any issues that this might cause. Tony On 12/21/2011 5:25 PM, Tony Printezis wrote: > Hi all, > > I have two code reviews (thanks to John and Ramki!). Can I push or is > anybody else still looking at this? > > Tony > > On 12/14/2011 05:17 PM, Tony Printezis wrote: >> Hi all, >> >> Can I have a couple of code review for this small change? >> >> http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ >> >> The CR has a bit more explanation. The short version is that I'm now >> encoding the "start index of the next chunk" in the from-space length >> field of a chunked array (say *that* quickly!) as a negative value to >> always be able to distinguish it from the real length. This will >> simplify the code for the CR John is currently working on (6484965) >> but it's a small, self-contained change so it's good to get it code >> reviewed and pushed separately. >> >> Tony >> >> From fancyerii at gmail.com Fri Dec 23 11:14:14 2011 From: fancyerii at gmail.com (Li Li) Date: Fri, 23 Dec 2011 19:14:14 +0800 Subject: question about Unsafe.allocateInstance Message-ID: hi all, I want to allocate and free memory as c/c++ language and I found the Unsafe in hotspot vm. I know the danger of using this class. But I still want to try it. allocateMemory and freeMemory are hard to use because I can't deal with primitive types such as int long and need convert them to byte arrays. And I also find a method named allocateInstance, which seems what I want. it just allocate space for this object. I don't know the memory is in heap or direct memory. if it's in direct memory, it should exist a method like freeInstance, but I don't find such one. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From fweimer at bfk.de Fri Dec 23 11:51:05 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 23 Dec 2011 11:51:05 +0000 Subject: question about Unsafe.allocateInstance In-Reply-To: (Li Li's message of "Fri, 23 Dec 2011 19:14:14 +0800") References: Message-ID: <82k45na4ly.fsf@mid.bfk.de> * Li Li: > And I also find a method named allocateInstance, which seems what I > want. allocateInstance() allocates objects on the Java heap, just like new. I'm pretty sure that there is no way at all to allocate instances which are not on the Java heap and subject to garbage collection. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From rednaxelafx at gmail.com Fri Dec 23 16:54:16 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sat, 24 Dec 2011 00:54:16 +0800 Subject: question about Unsafe.allocateInstance In-Reply-To: <82k45na4ly.fsf@mid.bfk.de> References: <82k45na4ly.fsf@mid.bfk.de> Message-ID: Unsafe.allocateInstance() is implemented in HotSpot VM by directly calling JNI's AllocObject() function [1]. An object instance is allocated in the Java heap, but no constructors are invoked for this instance. This method is mainly used to implement BootstrapConstructorAccessorImpl in the class library. Li, what is your original intent for doing explicit memory management in Java? - Kris [1]: http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp16337 On Fri, Dec 23, 2011 at 7:51 PM, Florian Weimer wrote: > * Li Li: > > > And I also find a method named allocateInstance, which seems what I > > want. > > allocateInstance() allocates objects on the Java heap, just like new. > I'm pretty sure that there is no way at all to allocate instances > which are not on the Java heap and subject to garbage collection. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From fancyerii at gmail.com Fri Dec 23 17:46:15 2011 From: fancyerii at gmail.com (Li Li) Date: Sat, 24 Dec 2011 01:46:15 +0800 Subject: question about Unsafe.allocateInstance In-Reply-To: References: <82k45na4ly.fsf@mid.bfk.de> Message-ID: Java's memory management is great. it reduce memory leak. But in some situation, I want to manage it by myself. On Sat, Dec 24, 2011 at 12:54 AM, Krystal Mok wrote: > Unsafe.allocateInstance() is implemented in HotSpot VM by directly calling > JNI's AllocObject() function [1]. > An object instance is allocated in the Java heap, but no constructors are > invoked for this instance. > This method is mainly used to implement BootstrapConstructorAccessorImpl > in the class library. > > Li, what is your original intent for doing explicit memory management in > Java? > > - Kris > > [1]: > http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/functions.html#wp16337 > > On Fri, Dec 23, 2011 at 7:51 PM, Florian Weimer wrote: > >> * Li Li: >> >> > And I also find a method named allocateInstance, which seems what I >> > want. >> >> allocateInstance() allocates objects on the Java heap, just like new. >> I'm pretty sure that there is no way at all to allocate instances >> which are not on the Java heap and subject to garbage collection. >> >> -- >> Florian Weimer >> BFK edv-consulting GmbH http://www.bfk.de/ >> Kriegsstra?e 100 tel: +49-721-96201-1 >> D-76133 Karlsruhe fax: +49-721-96201-99 >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.cuthbertson at oracle.com Fri Dec 23 19:29:44 2011 From: john.cuthbertson at oracle.com (John Cuthbertson) Date: Fri, 23 Dec 2011 11:29:44 -0800 Subject: RFR(S): 7121496: G1: do the per-region evacuation failure handling work in parallel Message-ID: <4EF4D6A8.2070301@oracle.com> Hi Everyone, Can I have a couple of volunteers look of this set of changes? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7121496/webrev.0/ Summary: The work that gets done for each heap region in the collection set, in the event of an evacuation failure, (e.g. removing self-forwarding pointers, updating the BOT etc.) was serial. I parallelized it by simply wrapping the work done for each region inside a HeapRegion closure, whose doHeapRegion method claims a region and does the work for that region. This HeapRegion closure is, in turn, wrapped in an AbstractGangTask. Testing: GC test suite with both deferred and immediate RSet updates (in some of the configurations - SPECjbb2000, SPECjbb2005, and GCBasher can experience a number of evacuation failures); Kitchensink with a forced evacuation failure mechanism. Thanks, JohnC From ysr1729 at gmail.com Fri Dec 23 21:52:09 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 23 Dec 2011 13:52:09 -0800 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EF43DB8.1080104@oracle.com> References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> Message-ID: >From sheer gut instinct (and nothing rational), it seems better to try and manage the race in the reading of the size in the from-space field (you know when you've read a negative size that you've lost a race; add appropriate asserts to see that the object is forwarded, use the size from the post-copy image, and bail out), than it is to mess with the length of the to-space image. Just sheer gut instinct -- the pre-image is something we can play with once we have copied it (or have safely won the race to copy it and know we are the only ones who will be modifying it). The post-copy image is the pristine thing that we typically don't want to mess with lest we screw up. OK, I am waving my hands wildly and this is not always true. But still, see if you can manage the race in the reading of the pre-image without undue cost. I'll think about it too at bed-time today :-) Happy Holidays! -- ramki On Fri, Dec 23, 2011 at 12:37 AM, Tony Printezis wrote: > Hi all, > > I have some bad news, it turns out that there's a subtle race in the code. > I've been testing the marking changes for quite a while now (which rely on > this patch) and I got a single failure. I'm pretty sure it's the race I > describe below. BTW, there's a question at the end of the e-mail. :-) > > Let's assume two threads, A and B, are racing to forward the same object > array X. Consider the following interleaving: > > Thread A: > is X forwarded? no > > Thread B: > is X forwarded? no > size = X.size(); > X' = allocate size > try to forward X to X'? yes > copy X to X' > chunk X, X.length is negative > > Thread A: > size = X.size(); -> BOOM, as size() just read a negative length > > Interesting this race exists today but it's benign due to either careful > design or sheer luck. When A reads size = X.size() it will actually get a > smaller size than the actual size of X and will allocate a chunk smaller > than X (!!!). However, given that X is already forwarded it won't need to > copy it and will undo the allocation. So, no harm done. > > Question: Is there a reason why we use the from-space length field to > encode the next index instead of the to-space length field? If we used the > latter we can simplify the code by quite a lot. I can't immediately think > of any issues that this might cause. > > Tony > > > On 12/21/2011 5:25 PM, Tony Printezis wrote: > >> Hi all, >> >> I have two code reviews (thanks to John and Ramki!). Can I push or is >> anybody else still looking at this? >> >> Tony >> >> On 12/14/2011 05:17 PM, Tony Printezis wrote: >> >>> Hi all, >>> >>> Can I have a couple of code review for this small change? >>> >>> http://cr.openjdk.java.net/~**tonyp/7121623/webrev.0/ >>> >>> The CR has a bit more explanation. The short version is that I'm now >>> encoding the "start index of the next chunk" in the from-space length field >>> of a chunked array (say *that* quickly!) as a negative value to always be >>> able to distinguish it from the real length. This will simplify the code >>> for the CR John is currently working on (6484965) but it's a small, >>> self-contained change so it's good to get it code reviewed and pushed >>> separately. >>> >>> Tony >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ysr1729 at gmail.com Fri Dec 23 22:05:31 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 23 Dec 2011 14:05:31 -0800 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> Message-ID: Tony, So if I understand yr proposal, you would switch the roles of the to and from copies' length fields (since you need both -- one to keep track of the original length and the other to keep track of the scan finger in the array). Of course there's a fwd'ing ptr from the the pre-image to the post-image, but not vice-versa. So you'd still push the pre-image reference on the work queue, but use the length field from the post-copy which you'd fetch and modify via the forwarding reference? It is probably true that the post-image's length is not used during GC once it's been copied, but it'd be good to check (I'm especially wary of CMS... but of course this is limited to G1 -- does G1 ever need to scan or iterate over regions that are subject to being copied into during an incremental pause?) -- ramki On Fri, Dec 23, 2011 at 1:52 PM, Srinivas Ramakrishna wrote: > From sheer gut instinct (and nothing rational), it seems better to try and > manage the race in the reading of the size in the from-space field (you know > when you've read a negative size that you've lost a race; add appropriate > asserts to see that the object is forwarded, > use the size from the post-copy image, and bail out), than it is to mess > with the length of the to-space image. Just sheer gut instinct -- the > pre-image is > something we can play with once we have copied it (or have safely won the > race to copy it and know we are the > only ones who will be modifying it). The post-copy image is the pristine > thing that we typically don't want to mess > with lest we screw up. OK, I am waving my hands wildly and this is not > always true. But still, see if you can manage the > race in the reading of the pre-image without undue cost. > > I'll think about it too at bed-time today :-) > > Happy Holidays! > -- ramki > > > On Fri, Dec 23, 2011 at 12:37 AM, Tony Printezis < > tony.printezis at oracle.com> wrote: > >> Hi all, >> >> I have some bad news, it turns out that there's a subtle race in the >> code. I've been testing the marking changes for quite a while now (which >> rely on this patch) and I got a single failure. I'm pretty sure it's the >> race I describe below. BTW, there's a question at the end of the e-mail. :-) >> >> Let's assume two threads, A and B, are racing to forward the same object >> array X. Consider the following interleaving: >> >> Thread A: >> is X forwarded? no >> >> Thread B: >> is X forwarded? no >> size = X.size(); >> X' = allocate size >> try to forward X to X'? yes >> copy X to X' >> chunk X, X.length is negative >> >> Thread A: >> size = X.size(); -> BOOM, as size() just read a negative length >> >> Interesting this race exists today but it's benign due to either careful >> design or sheer luck. When A reads size = X.size() it will actually get a >> smaller size than the actual size of X and will allocate a chunk smaller >> than X (!!!). However, given that X is already forwarded it won't need to >> copy it and will undo the allocation. So, no harm done. >> >> Question: Is there a reason why we use the from-space length field to >> encode the next index instead of the to-space length field? If we used the >> latter we can simplify the code by quite a lot. I can't immediately think >> of any issues that this might cause. >> >> Tony >> >> >> On 12/21/2011 5:25 PM, Tony Printezis wrote: >> >>> Hi all, >>> >>> I have two code reviews (thanks to John and Ramki!). Can I push or is >>> anybody else still looking at this? >>> >>> Tony >>> >>> On 12/14/2011 05:17 PM, Tony Printezis wrote: >>> >>>> Hi all, >>>> >>>> Can I have a couple of code review for this small change? >>>> >>>> http://cr.openjdk.java.net/~**tonyp/7121623/webrev.0/ >>>> >>>> The CR has a bit more explanation. The short version is that I'm now >>>> encoding the "start index of the next chunk" in the from-space length field >>>> of a chunked array (say *that* quickly!) as a negative value to always be >>>> able to distinguish it from the real length. This will simplify the code >>>> for the CR John is currently working on (6484965) but it's a small, >>>> self-contained change so it's good to get it code reviewed and pushed >>>> separately. >>>> >>>> Tony >>>> >>>> >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Sat Dec 24 08:21:02 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 24 Dec 2011 00:21:02 -0800 Subject: review(S): 7124829: NUMA: memory leak on Linux with large pages Message-ID: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> The issue is with os::free_memory() changes made in 7060842 when the ?madvise? call was replaced with ?mmap?. This is the reason of exhaustive memory consumption. Seems when we need to remap some memory we need to do it using the same flags as we mapped it initially, particularly with ?MAP_HUGETLB?. Otherwise system maps small pages instead of already reserved huge pages. Contributed by: Aleksey Ignatenko Webrev: http://cr.openjdk.java.net/~iveresov/7124829/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Tue Dec 27 14:08:39 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 27 Dec 2011 09:08:39 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> Message-ID: <4EF9D167.4010204@oracle.com> Ramki, On 12/23/2011 04:52 PM, Srinivas Ramakrishna wrote: > >From sheer gut instinct (and nothing rational), it seems better to > try and manage the race in the reading of the size in the from-space > field (you know > when you've read a negative size that you've lost a race; add > appropriate asserts to see that the object is forwarded, > use the size from the post-copy image, and bail out), than it is to > mess with the length of the to-space image. Just sheer gut instinct -- > the pre-image is > something we can play with once we have copied it (or have safely won > the race to copy it and know we are the > only ones who will be modifying it). The post-copy image is the > pristine thing that we typically don't want to mess > with lest we screw up. I understand what you're saying but I see this slightly differently. Currently, when we chunk arrays, we actually mutate both images: from-image: length field maintains the next index to-image: copy object, write mark word, and update ref fields as we process them and we find that they point to objects that have been / will be moved It'd be nice if one of the images was actually pristine / consistent and currently neither is: each of them might be inconsistent at different times and for different reasons. Using the length field of the to-space object to encode the "next index" ensures that at least the from-image is always consistent and not mutated (apart from the forwarding reference of course). So, we can always reliably read the size from the from-image and we won't have to have any special code to detect which image is consistent and where to read the length from. Regarding accidentally leaving the to-image length inconsistent: well, that'd be a bug and we'll have to fix it (heap verification will come across this sooner or later). If we don't update the length correctly that probably means that we also didn't process the last chunk on the array, which might leave some reference fields on it unprocessed, which is not a good situation anyway, length field being correct or not. :-) Tony > OK, I am waving my hands wildly and this is not always true. But > still, see if you can manage the > race in the reading of the pre-image without undue cost. > > I'll think about it too at bed-time today :-) > > Happy Holidays! > -- ramki > > On Fri, Dec 23, 2011 at 12:37 AM, Tony Printezis > > wrote: > > Hi all, > > I have some bad news, it turns out that there's a subtle race in > the code. I've been testing the marking changes for quite a while > now (which rely on this patch) and I got a single failure. I'm > pretty sure it's the race I describe below. BTW, there's a > question at the end of the e-mail. :-) > > Let's assume two threads, A and B, are racing to forward the same > object array X. Consider the following interleaving: > > Thread A: > is X forwarded? no > > Thread B: > is X forwarded? no > size = X.size(); > X' = allocate size > try to forward X to X'? yes > copy X to X' > chunk X, X.length is negative > > Thread A: > size = X.size(); -> BOOM, as size() just read a negative length > > Interesting this race exists today but it's benign due to either > careful design or sheer luck. When A reads size = X.size() it will > actually get a smaller size than the actual size of X and will > allocate a chunk smaller than X (!!!). However, given that X is > already forwarded it won't need to copy it and will undo the > allocation. So, no harm done. > > Question: Is there a reason why we use the from-space length field > to encode the next index instead of the to-space length field? If > we used the latter we can simplify the code by quite a lot. I > can't immediately think of any issues that this might cause. > > Tony > > > On 12/21/2011 5:25 PM, Tony Printezis wrote: > > Hi all, > > I have two code reviews (thanks to John and Ramki!). Can I > push or is anybody else still looking at this? > > Tony > > On 12/14/2011 05:17 PM, Tony Printezis wrote: > > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ > > > The CR has a bit more explanation. The short version is > that I'm now encoding the "start index of the next chunk" > in the from-space length field of a chunked array (say > *that* quickly!) as a negative value to always be able to > distinguish it from the real length. This will simplify > the code for the CR John is currently working on (6484965) > but it's a small, self-contained change so it's good to > get it code reviewed and pushed separately. > > Tony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Tue Dec 27 14:20:56 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 27 Dec 2011 09:20:56 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> Message-ID: <4EF9D448.80305@oracle.com> On 12/23/2011 05:05 PM, Srinivas Ramakrishna wrote: > Tony, So if I understand yr proposal, you would switch the roles of > the to and from copies' length fields (since you > need both -- one to keep track of the original length and the other to > keep track of the scan finger in the array). Correct. > Of course there's a fwd'ing ptr from the the pre-image to the > post-image, but not vice-versa. So you'd still > push the pre-image reference on the work queue, but use the length > field from the post-copy which you'd > fetch and modify via the forwarding reference? Correct. > It is probably true that the post-image's length is not used > during GC once it's been copied, but it'd be good to check (I'm > especially wary of CMS... but of course > this is limited to G1 -- does G1 ever need to scan or iterate over > regions that are subject to being copied > into during an incremental pause?) This is of course something I was also worried about. In G1 we should not be scanning to-space objects that are being copied during GC, not only because the length might be incorrect due to this change but also because there are no guarantees that the objects are well formed (another thread might be in the process of copying them). For all regions we copy objects into we call save_marks() so that we never go over saved_mark() during scanning. Tony > -- ramki > > On Fri, Dec 23, 2011 at 1:52 PM, Srinivas Ramakrishna > > wrote: > > From sheer gut instinct (and nothing rational), it seems better to > try and manage the race in the reading of the size in the > from-space field (you know > when you've read a negative size that you've lost a race; add > appropriate asserts to see that the object is forwarded, > use the size from the post-copy image, and bail out), than it is > to mess with the length of the to-space image. Just sheer gut > instinct -- the pre-image is > something we can play with once we have copied it (or have safely > won the race to copy it and know we are the > only ones who will be modifying it). The post-copy image is the > pristine thing that we typically don't want to mess > with lest we screw up. OK, I am waving my hands wildly and this is > not always true. But still, see if you can manage the > race in the reading of the pre-image without undue cost. > > I'll think about it too at bed-time today :-) > > Happy Holidays! > -- ramki > > > On Fri, Dec 23, 2011 at 12:37 AM, Tony Printezis > > wrote: > > Hi all, > > I have some bad news, it turns out that there's a subtle race > in the code. I've been testing the marking changes for quite a > while now (which rely on this patch) and I got a single > failure. I'm pretty sure it's the race I describe below. BTW, > there's a question at the end of the e-mail. :-) > > Let's assume two threads, A and B, are racing to forward the > same object array X. Consider the following interleaving: > > Thread A: > is X forwarded? no > > Thread B: > is X forwarded? no > size = X.size(); > X' = allocate size > try to forward X to X'? yes > copy X to X' > chunk X, X.length is negative > > Thread A: > size = X.size(); -> BOOM, as size() just read a negative length > > Interesting this race exists today but it's benign due to > either careful design or sheer luck. When A reads size = > X.size() it will actually get a smaller size than the actual > size of X and will allocate a chunk smaller than X (!!!). > However, given that X is already forwarded it won't need to > copy it and will undo the allocation. So, no harm done. > > Question: Is there a reason why we use the from-space length > field to encode the next index instead of the to-space length > field? If we used the latter we can simplify the code by quite > a lot. I can't immediately think of any issues that this might > cause. > > Tony > > > On 12/21/2011 5:25 PM, Tony Printezis wrote: > > Hi all, > > I have two code reviews (thanks to John and Ramki!). Can I > push or is anybody else still looking at this? > > Tony > > On 12/14/2011 05:17 PM, Tony Printezis wrote: > > Hi all, > > Can I have a couple of code review for this small change? > > http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ > > > The CR has a bit more explanation. The short version > is that I'm now encoding the "start index of the next > chunk" in the from-space length field of a chunked > array (say *that* quickly!) as a negative value to > always be able to distinguish it from the real length. > This will simplify the code for the CR John is > currently working on (6484965) but it's a small, > self-contained change so it's good to get it code > reviewed and pushed separately. > > Tony > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Tue Dec 27 17:13:16 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 27 Dec 2011 09:13:16 -0800 Subject: Promotion failures: indication of CMS fragmentation? In-Reply-To: References: Message-ID: <4EF9FCAC.3030208@oracle.com> Taras, PrintPromotionFailure seems like it would go a long way to identify the root of your promotion failures (or at least eliminating some possible causes). I think it would help focus the discussion if you could send the result of that experiment early. Jon On 12/27/2011 5:07 AM, Taras Tielkes wrote: > Hi, > > We're running an application with the CMS/ParNew collectors that is > experiencing occasional promotion failures. > Environment is Linux 2.6.18 (x64), JVM is 1.6.0_29 in server mode. > I've listed the specific JVM options used below (a). > > The application is deployed across a handful of machines, and the > promotion failures are fairly uniform across those. > > The first kind of failure we observe is a promotion failure during > ParNew collection, I've included a snipped from the gc log below (b). > The second kind of failure is a concurrrent mode failure (perhaps > triggered by the same cause), see (c) below. > The frequency (after running for a some weeks) is approximately once > per day. This is bearable, but obviously we'd like to improve on this. > > Apart from high-volume request handling (which allocates a lot of > small objects), the application also runs a few dozen background > threads that download and process XML documents, typically in the 5-30 > MB range. > A known deficiency in the existing code is that the XML content is > copied twice before processing (once to a byte[], and later again to a > String/char[]). > Given that a 30 MB XML stream will result in a 60 MB > java.lang.String/char[], my suspicion is that these big array > allocations are causing us to run into the CMS fragmentation issue. > > My questions are: > 1) Does the data from the GC logs provide sufficient evidence to > conclude that CMS fragmentation is the cause of the promotion failure? > 2) If not, what's the next step of investigating the cause? > 3) We're planning to at least add -XX:+PrintPromotionFailure to get a > feeling for the size of the objects that fail promotion. > Overall, it seem that -XX:PrintFLSStatistics=1 is actually the only > reliable approach to diagnose CMS fragmentation. Is this indeed the > case? > > Thanks in advance, > Taras > > a) Current JVM options: > -------------------------------- > -server > -Xms5g > -Xmx5g > -Xmn400m > -XX:PermSize=256m > -XX:MaxPermSize=256m > -XX:+PrintGCTimeStamps > -verbose:gc > -XX:+PrintGCDateStamps > -XX:+PrintGCDetails > -XX:SurvivorRatio=8 > -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC > -XX:+DisableExplicitGC > -XX:+UseCMSInitiatingOccupancyOnly > -XX:+CMSClassUnloadingEnabled > -XX:+CMSScavengeBeforeRemark > -XX:CMSInitiatingOccupancyFraction=68 > -Xloggc:gc.log > -------------------------------- > > b) Promotion failure during ParNew > -------------------------------- > 2011-12-08T18:14:40.966+0100: 219729.868: [GC 219729.868: [ParNew: > 368640K->40959K(368640K), 0.0693460 secs] > 3504917K->3195098K(5201920K), 0.0696500 secs] [Times: user=0.39 > sys=0.01, real=0.07 secs] > 2011-12-08T18:14:43.778+0100: 219732.679: [GC 219732.679: [ParNew: > 368639K->31321K(368640K), 0.0511400 secs] > 3522778K->3198316K(5201920K), 0.0514420 secs] [Times: user=0.28 > sys=0.00, real=0.05 secs] > 2011-12-08T18:14:46.945+0100: 219735.846: [GC 219735.846: [ParNew: > 359001K->18694K(368640K), 0.0272970 secs] > 3525996K->3185690K(5201920K), 0.0276080 secs] [Times: user=0.19 > sys=0.00, real=0.03 secs] > 2011-12-08T18:14:49.036+0100: 219737.938: [GC 219737.938: [ParNew > (promotion failed): 338813K->361078K(368640K), 0.1321200 > secs]219738.070: [CMS: 3167747K->434291K(4833280K), 4.8881570 secs] > 3505808K->434291K > (5201920K), [CMS Perm : 116893K->116883K(262144K)], 5.0206620 secs] > [Times: user=5.24 sys=0.00, real=5.02 secs] > 2011-12-08T18:14:54.721+0100: 219743.622: [GC 219743.623: [ParNew: > 327680K->40960K(368640K), 0.0949460 secs] 761971K->514584K(5201920K), > 0.0952820 secs] [Times: user=0.52 sys=0.04, real=0.10 secs] > 2011-12-08T18:14:55.580+0100: 219744.481: [GC 219744.482: [ParNew: > 368640K->40960K(368640K), 0.1299190 secs] 842264K->625681K(5201920K), > 0.1302190 secs] [Times: user=0.72 sys=0.01, real=0.13 secs] > 2011-12-08T18:14:58.050+0100: 219746.952: [GC 219746.952: [ParNew: > 368640K->40960K(368640K), 0.0870940 secs] 953361K->684121K(5201920K), > 0.0874110 secs] [Times: user=0.48 sys=0.01, real=0.09 secs] > -------------------------------- > > c) Promotion failure during CMS > -------------------------------- > 2011-12-14T08:29:26.628+0100: 703015.530: [GC 703015.530: [ParNew: > 357228K->40960K(368640K), 0.0525110 secs] > 3603068K->3312743K(5201920K), 0.0528120 secs] [Times: user=0.37 > sys=0.00, real=0.05 secs] > 2011-12-14T08:29:28.864+0100: 703017.766: [GC 703017.766: [ParNew: > 366075K->37119K(368640K), 0.0479780 secs] > 3637859K->3317662K(5201920K), 0.0483090 secs] [Times: user=0.24 > sys=0.01, real=0.05 secs] > 2011-12-14T08:29:29.553+0100: 703018.454: [GC 703018.455: [ParNew: > 364792K->40960K(368640K), 0.0421740 secs] > 3645334K->3334944K(5201920K), 0.0424810 secs] [Times: user=0.30 > sys=0.00, real=0.04 secs] > 2011-12-14T08:29:29.600+0100: 703018.502: [GC [1 CMS-initial-mark: > 3293984K(4833280K)] 3335025K(5201920K), 0.0272490 secs] [Times: > user=0.02 sys=0.00, real=0.03 secs] > 2011-12-14T08:29:29.628+0100: 703018.529: [CMS-concurrent-mark-start] > 2011-12-14T08:29:30.718+0100: 703019.620: [GC 703019.620: [ParNew: > 368640K->40960K(368640K), 0.0836690 secs] > 3662624K->3386039K(5201920K), 0.0839690 secs] [Times: user=0.50 > sys=0.01, real=0.08 secs] > 2011-12-14T08:29:30.827+0100: 703019.729: [CMS-concurrent-mark: > 1.108/1.200 secs] [Times: user=6.83 sys=0.23, real=1.20 secs] > 2011-12-14T08:29:30.827+0100: 703019.729: [CMS-concurrent-preclean-start] > 2011-12-14T08:29:30.938+0100: 703019.840: [CMS-concurrent-preclean: > 0.093/0.111 secs] [Times: user=0.48 sys=0.02, real=0.11 secs] > 2011-12-14T08:29:30.938+0100: 703019.840: > [CMS-concurrent-abortable-preclean-start] > 2011-12-14T08:29:32.337+0100: 703021.239: > [CMS-concurrent-abortable-preclean: 1.383/1.399 secs] [Times: > user=6.68 sys=0.27, real=1.40 secs] > 2011-12-14T08:29:32.343+0100: 703021.244: [GC[YG occupancy: 347750 K > (368640 K)]2011-12-14T08:29:32.343+0100: 703021.244: [GC 703021.244: > [ParNew (promotion failed): 347750K->347750K(368640K), 9.8729020 secs] > 3692829K->3718580K(5201920K), 9.8732380 secs] [Times: user=12.00 > sys=2.58, real=9.88 secs] > 703031.118: [Rescan (parallel) , 0.2826110 secs]703031.400: [weak refs > processing, 0.0014780 secs]703031.402: [class unloading, 0.0176610 > secs]703031.419: [scrub symbol& string tables, 0.0094960 secs] [1 CMS > -remark: 3370830K(4833280K)] 3718580K(5201920K), 10.1916910 secs] > [Times: user=13.73 sys=2.59, real=10.19 secs] > 2011-12-14T08:29:42.535+0100: 703031.436: [CMS-concurrent-sweep-start] > 2011-12-14T08:29:42.591+0100: 703031.493: [Full GC 703031.493: > [CMS2011-12-14T08:29:48.616+0100: 703037.518: [CMS-concurrent-sweep: > 6.046/6.082 secs] [Times: user=6.18 sys=0.01, real=6.09 secs] > (concurrent mode failure): 3370829K->433437K(4833280K), 10.9594300 > secs] 3739469K->433437K(5201920K), [CMS Perm : > 121702K->121690K(262144K)], 10.9597540 secs] [Times: user=10.95 > sys=0.00, real=10.96 secs] > 2011-12-14T08:29:53.997+0100: 703042.899: [GC 703042.899: [ParNew: > 327680K->40960K(368640K), 0.0799960 secs] 761117K->517836K(5201920K), > 0.0804100 secs] [Times: user=0.46 sys=0.00, real=0.08 secs] > 2011-12-14T08:29:54.649+0100: 703043.551: [GC 703043.551: [ParNew: > 368640K->40960K(368640K), 0.0784460 secs] 845516K->557872K(5201920K), > 0.0787920 secs] [Times: user=0.40 sys=0.01, real=0.08 secs] > 2011-12-14T08:29:56.418+0100: 703045.320: [GC 703045.320: [ParNew: > 368640K->40960K(368640K), 0.0784040 secs] 885552K->603017K(5201920K), > 0.0787630 secs] [Times: user=0.41 sys=0.01, real=0.07 secs] > -------------------------------- > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From tony.printezis at oracle.com Tue Dec 27 18:04:43 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 27 Dec 2011 13:04:43 -0500 Subject: CRR (S / version 2): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EF43DB8.1080104@oracle.com> References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> Message-ID: <4EFA08BB.2060508@oracle.com> Hi all, Here's version 2 of this fix: http://cr.openjdk.java.net/~tonyp/7121623/webrev.1/ I dropped the idea of using a negative value to encode the next index for the reasons I mentioned in previous e-mails. I now store the next index in the length field of the to-image, instead of the from-image, so that the from-image is always consistent and we can always calculate an object's size from it. I also renamed some variables to make the code a bit more readable: old / obj -> from_obj / to_obj. As this fix is now conceptually different compared to the first version I'd like two new code reviews for it (having said that, the new set of changes are minimal compared to the previous version). Thanks, Tony On 12/23/2011 03:37 AM, Tony Printezis wrote: > Hi all, > > I have some bad news, it turns out that there's a subtle race in the > code. I've been testing the marking changes for quite a while now > (which rely on this patch) and I got a single failure. I'm pretty sure > it's the race I describe below. BTW, there's a question at the end of > the e-mail. :-) > > Let's assume two threads, A and B, are racing to forward the same > object array X. Consider the following interleaving: > > Thread A: > is X forwarded? no > > Thread B: > is X forwarded? no > size = X.size(); > X' = allocate size > try to forward X to X'? yes > copy X to X' > chunk X, X.length is negative > > Thread A: > size = X.size(); -> BOOM, as size() just read a negative length > > Interesting this race exists today but it's benign due to either > careful design or sheer luck. When A reads size = X.size() it will > actually get a smaller size than the actual size of X and will > allocate a chunk smaller than X (!!!). However, given that X is > already forwarded it won't need to copy it and will undo the > allocation. So, no harm done. > > Question: Is there a reason why we use the from-space length field to > encode the next index instead of the to-space length field? If we used > the latter we can simplify the code by quite a lot. I can't > immediately think of any issues that this might cause. > > Tony > > On 12/21/2011 5:25 PM, Tony Printezis wrote: >> Hi all, >> >> I have two code reviews (thanks to John and Ramki!). Can I push or is >> anybody else still looking at this? >> >> Tony >> >> On 12/14/2011 05:17 PM, Tony Printezis wrote: >>> Hi all, >>> >>> Can I have a couple of code review for this small change? >>> >>> http://cr.openjdk.java.net/~tonyp/7121623/webrev.0/ >>> >>> The CR has a bit more explanation. The short version is that I'm now >>> encoding the "start index of the next chunk" in the from-space >>> length field of a chunked array (say *that* quickly!) as a negative >>> value to always be able to distinguish it from the real length. This >>> will simplify the code for the CR John is currently working on >>> (6484965) but it's a small, self-contained change so it's good to >>> get it code reviewed and pushed separately. >>> >>> Tony >>> >>> From tony.printezis at oracle.com Tue Dec 27 18:05:12 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Tue, 27 Dec 2011 13:05:12 -0500 Subject: CRR (L / updated): 6888336: G1: avoid explicitly marking and pushing objects in survivor spaces In-Reply-To: <4EF25FB8.5050507@oracle.com> References: <4EF25FB8.5050507@oracle.com> Message-ID: <4EFA08D8.8040009@oracle.com> Hi all, Here's an updated webrev for this change that takes into account the new approach of chunking object arrays (see previous e-mails on 7121623): http://cr.openjdk.java.net/~tonyp/6888336/webrev.1/ If anything else the new approach simplified the code a bit since now we can always read an object's size from its from-image instead of having to check one or the other depending on whether it's a chunked array or not. I also moved the body of some methods from heapRegion.hpp to the .inline.hpp and .cpp files (as they were getting a bit large to keep in the .hpp file). Tony On 12/21/2011 05:37 PM, Tony Printezis wrote: > Hi all, > > I'd like a couple of code reviews for the following non-trivial > changes (large, not necessary in lines of code modified but more due > to the fact that the evacuation pause / concurrent marking interaction > is changed quite dramatically): > > http://cr.openjdk.java.net/~tonyp/6888336/webrev.0/ > > Here's some background, motivation, and a summary of the changes (I > felt that it was important to write a longer then usual explanation): > > * Background / Motivation > > Each G1 heap region has a field top-at-mark-start (aka TAMS) which > denotes where the top of the region was when marking started. An > object is considered implicitly live if it's over TAMS (i.e., it was > allocated since marking started) or explicitly live if it's below TAMS > (i.e., it was allocated before marking started) and marked on the > bitmap. (It follows that it's unnecessary to explicitly mark objects > over TAMS.) > > In fact, we have two copies of the above marking information: "Next > TAMS / Next Bitmap" and "Prev TAMS / Prev Bitmap". Prev is the copy > that was obtained by the last marking cycle that was successfully > completed (so, it is consistent: all live objects should appear as > live in the prev marking information). Next is the copy that will be > obtained / is currently being obtained and it's not consistent because > it's not guaranteed to be complete. > > G1 uses SATB marking which has the advantage not to require objects > allocated since the start of marking to be visited at all by the > marking threads (they are implicitly live and they do not need to be > scanned). So, the active marking cycle can totally ignore objects over > NTAMS (since they have been allocated since marking started). > > The current interaction between evacuation pauses (let's call these > "GCs" from now on) and concurrent marking is very tricky. Even though > marking ignores all objects over NTAMS (currently: all objects in Eden > regions) it still has to visit and mark objects in the Survivors > regions. But those will be moved by subsequent GCs. So, a GC needs to > be aware that it's moving objects that have been marked by the marking > threads and not only propagate those marks but also notify the marking > threads that said objects have been moved. For that we use several > data structures: pushes to the global marking stack and also to what's > referred to as the "region stack" which is only used by the GC to push > a group of objects instead of pushing them individually ("region" > here is a mem region and smaller than a G1 region). > > Additionally, because the marking threads could come across objects > that could potentially move we have to make sure that we don't leave > references to regions that have been evacuated on any marking data > structure. To do that we treat as roots all entries on the taskqueues > / global stack and drained all SATB buffers (both active buffers and > also enqueued buffers). > > The first issue with the above interaction is that it has performance > issues. Draining all SATB buffers and scanning the mark stack and > taskqueues has been shown to be very time-consuming in some cases. > Also, having to check whether objects are marked and propagate the > marks appropriately during GC is an extra overhead. > > The second issue is that it has been shown to be very fragile. We have > discovered and fixed many issues over time which were subtle and hard > to reproduce. > > We really need to simplify the GC/marking interaction to both improve > performance of GCs during marking, as well as improve our reliability. > This changeset does exactly that. > > * Explanation of the changes > > The goal is to ensure that all the objects that are copied by the GC > do not need to be visited by the marking threads and as a result do > not need to be explicitly marked, pushed, etc. > > The first observation is that most objects copied during a GC are > allocated after marking starts and are therefore implicitly live. This > is the case for all objects on Eden regions, as well as most objects > on Survivor regions. The only exception are objects on the Survivor > regions during the initial-mark pause. Unfortunately, it's not easy to > track those separately as they will get mixed in with future > Survivors. The first decision to deal with this is to turn off > Survivors during the initial-mark pause. This ensures that all objects > copied during each subsequent GC will only visit objects that have > been allocated since marking started and are therefore implicitly live > (i.e., over NTAMS). This allows us to totally eliminate that code that > propagates marks during the GC. We just have to make sure that all > copied objects are over NTAMS. Turning off Survivors during an > initial-mark pause is a bit of a "big hammer" approach, but it will > suffice for now. We have ideas on how to re-enable them in the future > and we'll explore a couple of alternatives. > > Given that the GC only copies objects that are implicitly marked it > follows that none of the objects that are copied during any GC should > appear on either the taskqueues nor the global marking stack. Also > remember that we filter SATB buffers before enqueueing them which will > filter out all implicitly marked objects. It follows that no enqueued > SATB buffer should have references to objects that are being moved. > This leaves the currently active SATB buffers given that the code that > populates them is unconditional. But if we run the filtering on those > during each GC such "offending" references are also quickly > eliminated. So, instead of having to scan all stacks and all SATB > buffers we only have to filter the active SATB buffers, which should > be much, much faster. > > * Implementation Notes > > The actual changes are not too extensive as they basically mostly > disable functionality in the GC code. The tricky part was to get the > TAMS fields correct at various phases (start of copying, start of > marking, etc.) and especially when an evacuation failure occurs. I put > all that functionality in methods on HeapRegion which do the right > thing when a GC starts, a marking starts, etc. > > The most important changes are in the "main" GC code, i.e. > G1ParCopyHelper::do_oop_work() and > G1ParCopyHelper::copy_to_survivor_space(). Instead of having to > propagate marks we only now need to mark objects directly reachable > from roots during the initial-mark pause. The resulting code is much > simplified (and hopefully more performant!). > > I also added a method verify_no_cset_oops() which checks that indeed > all the marking data structures do not point to regions that are being > GCed at the start / end of each GC. (BTW, I'm considering adding a > develop flag to enable this on demand.) > > I should point out that this changeset will leave a lot of dead code. > However, I took the decision to keep the changes to a minimum in order > not overwhelm the code reviewers and make the important changes > clearer. (I also discussed this with a couple of potential code > reviewers and they agreed that this is a good approach.) I temporarily > added guarantees to ensure that methods that should not be called are > not called. I will remove all dead code with a future push. > > I also have to apologize to John Cuthbertson for removing a lot of > code he's added to deal with various bugs we had in the GC/marking > interaction. Hopefully the new code will be less fragile compared to > what we've had so far and John will be able to concentrate on more > interesting features than trying to track down hard-to-reproduce > failures! > > Tony > From vladimir.kozlov at oracle.com Tue Dec 27 18:40:30 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Dec 2011 10:40:30 -0800 Subject: review(S): 7124829: NUMA: memory leak on Linux with large pages In-Reply-To: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> References: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> Message-ID: <4EFA111E.3060600@oracle.com> You missed changes (additional parameter) in other OS files: bsd, solaris. Vladimir Igor Veresov wrote: > The issue is with os::free_memory() changes made in 7060842 when the > ?madvise? call was replaced with ?mmap?. This is the reason of > exhaustive memory consumption. Seems when we need to remap some memory > we need to do it using the same flags as we mapped it initially, > particularly with ?MAP_HUGETLB?. Otherwise system maps small pages > instead of already reserved huge pages. > > Contributed by: Aleksey Ignatenko > > Webrev: http://cr.openjdk.java.net/~iveresov/7124829/webrev.00/ > > igor > From jon.masamitsu at oracle.com Tue Dec 27 22:06:53 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 27 Dec 2011 14:06:53 -0800 Subject: Turning off generational GC In-Reply-To: References: Message-ID: <4EFA417D.4070009@oracle.com> For the hotspot garbage collectors the short answer is "no" there is no way to turn off generational GC. I think it's even pretty deeply entrenched in G1 which is only logically generational. If CMS were not generational, in the best cause you would see pauses on the order of 20ms. Maybe much larger although less frequent. More likely would be concurrent mode failures which would lead to full GC's. On 12/27/2011 1:20 PM, Guy Korland wrote: > Hi, > > I hope this is the right forum for this. > It seems like no matter how small we set the young generation, it take more > than 20ms. > Is there a way turn off generational GC, especially in CMS? > > Thanks, > Guy > > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From igor.veresov at oracle.com Tue Dec 27 23:09:39 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 27 Dec 2011 15:09:39 -0800 Subject: review(S): 7124829: NUMA: memory leak on Linux with large pages In-Reply-To: <4EFA111E.3060600@oracle.com> References: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> <4EFA111E.3060600@oracle.com> Message-ID: Right, thanks! I've updated the webrev. igor On Tuesday, December 27, 2011 at 10:40 AM, Vladimir Kozlov wrote: > You missed changes (additional parameter) in other OS files: bsd, solaris. > > Vladimir > > Igor Veresov wrote: > > The issue is with os::free_memory() changes made in 7060842 when the > > ?madvise? call was replaced with ?mmap?. This is the reason of > > exhaustive memory consumption. Seems when we need to remap some memory > > we need to do it using the same flags as we mapped it initially, > > particularly with ?MAP_HUGETLB?. Otherwise system maps small pages > > instead of already reserved huge pages. > > > > Contributed by: Aleksey Ignatenko > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7124829/webrev.00/ > > > > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 27 23:21:00 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Dec 2011 15:21:00 -0800 Subject: review(S): 7124829: NUMA: memory leak on Linux with large pages In-Reply-To: References: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> <4EFA111E.3060600@oracle.com> Message-ID: <4EFA52DC.1020000@oracle.com> Looks good. Thanks, Vladimir Igor Veresov wrote: > Right, thanks! I've updated the webrev. > > igor > > On Tuesday, December 27, 2011 at 10:40 AM, Vladimir Kozlov wrote: > >> You missed changes (additional parameter) in other OS files: bsd, solaris. >> >> Vladimir >> >> Igor Veresov wrote: >>> The issue is with os::free_memory() changes made in 7060842 when the >>> ?madvise? call was replaced with ?mmap?. This is the reason of >>> exhaustive memory consumption. Seems when we need to remap some memory >>> we need to do it using the same flags as we mapped it initially, >>> particularly with ?MAP_HUGETLB?. Otherwise system maps small pages >>> instead of already reserved huge pages. >>> >>> Contributed by: Aleksey Ignatenko >> > >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/7124829/webrev.00/ >>> >>> igor > From igor.veresov at oracle.com Tue Dec 27 23:22:00 2011 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 27 Dec 2011 15:22:00 -0800 Subject: review(S): 7124829: NUMA: memory leak on Linux with large pages In-Reply-To: <4EFA52DC.1020000@oracle.com> References: <5DDD1070C45F42BBA481FCA44BAE0A68@oracle.com> <4EFA111E.3060600@oracle.com> <4EFA52DC.1020000@oracle.com> Message-ID: Thank you! igor On Tuesday, December 27, 2011 at 3:21 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > Igor Veresov wrote: > > Right, thanks! I've updated the webrev. > > > > igor > > > > On Tuesday, December 27, 2011 at 10:40 AM, Vladimir Kozlov wrote: > > > > > You missed changes (additional parameter) in other OS files: bsd, solaris. > > > > > > Vladimir > > > > > > Igor Veresov wrote: > > > > The issue is with os::free_memory() changes made in 7060842 when the > > > > ?madvise? call was replaced with ?mmap?. This is the reason of > > > > exhaustive memory consumption. Seems when we need to remap some memory > > > > we need to do it using the same flags as we mapped it initially, > > > > particularly with ?MAP_HUGETLB?. Otherwise system maps small pages > > > > instead of already reserved huge pages. > > > > > > > > Contributed by: Aleksey Ignatenko > > > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~iveresov/7124829/webrev.00/ > > > > > > > > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.masamitsu at oracle.com Wed Dec 28 00:12:50 2011 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 28 Dec 2011 00:12:50 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 12 new changesets Message-ID: <20111228001319.B1E46477E5@hg.openjdk.java.net> Changeset: 96ce4c27112f Author: coleenp Date: 2011-12-19 15:34 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/96ce4c27112f 7122939: TraceBytecodes broken with UseCompressedOops Summary: Disable verify_heapbase on sparc if TraceBytecodes because the latter uses r12 as a temp register Reviewed-by: coleenp, phh Contributed-by: Volker Simonis ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 6c995c08526c Author: phh Date: 2011-12-19 15:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/6c995c08526c 7122880: Extend vendor-specific command interface to include manageable switches Summary: Add Flag::external_ext()/writable_ext(), both return false. Reviewed-by: coleenp, zgu ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_ext.hpp ! src/share/vm/services/management.cpp Changeset: 4502fd5c7698 Author: phh Date: 2011-12-19 21:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4502fd5c7698 Merge Changeset: 11c26bfcf8c7 Author: phh Date: 2011-12-21 15:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/11c26bfcf8c7 7091417: recvfrom's 6th input should be of type socklen_t Summary: Revamp class os's socket method formal args to match socket.h, insert casts in appropriate places, and copyin-copyout int*'s that s/b socklen_t*'s in jvm.cpp. Reviewed-by: coleenp, dholmes Contributed-by: erik.gahlin at oracle.com, rickard.backman at oracle.com, nils.loodin at oracle.com, markus.gronlund at oracle.com ! src/os/bsd/vm/jvm_bsd.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/jvm_linux.h ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/jvm_solaris.h ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/ostream.cpp Changeset: c01e115b095e Author: coleenp Date: 2011-12-21 16:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c01e115b095e 7064927: retransformClasses() does not pass in LocalVariableTable of a method Summary: Handle LVT attribute in the class file reconstitutor. Reviewed-by: phh, coleenp Contributed-by: thomaswue ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp Changeset: d532160c55f7 Author: coleenp Date: 2011-12-21 18:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d532160c55f7 Merge Changeset: 4b18532913c7 Author: vladidan Date: 2011-12-22 12:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4b18532913c7 Merge ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 7e075537835d Author: cl Date: 2011-12-22 19:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7e075537835d Added tag jdk8-b18 for changeset 61165f53f165 ! .hgtags Changeset: 4bcf61041217 Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/4bcf61041217 Merge Changeset: 9232e0ecbc2c Author: amurillo Date: 2011-12-23 15:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/9232e0ecbc2c Added tag hs23-b09 for changeset 4bcf61041217 ! .hgtags Changeset: 0841c0ec2ed6 Author: amurillo Date: 2011-12-23 15:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/0841c0ec2ed6 7123810: new hotspot build - hs23-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 7faca6dfa2ed Author: jmasa Date: 2011-12-27 12:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/7faca6dfa2ed Merge ! src/share/vm/runtime/globals.hpp From igor.veresov at oracle.com Wed Dec 28 03:44:32 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 28 Dec 2011 03:44:32 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7124829: NUMA: memory leak on Linux with large pages Message-ID: <20111228034435.0F7B6477EB@hg.openjdk.java.net> Changeset: 20bfb6d15a94 Author: iveresov Date: 2011-12-27 16:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/20bfb6d15a94 7124829: NUMA: memory leak on Linux with large pages Summary: In os::free_memory() use mmap with the same attributes as for the heap space Reviewed-by: kvn Contributed-by: Aleksey Ignatenko ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/runtime/os.hpp From tony.printezis at oracle.com Wed Dec 28 10:38:10 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 05:38:10 -0500 Subject: CRR (S): 7121623: G1: always be able to reliably calculate the length of a forwarded chunked array In-Reply-To: <4EF9D448.80305@oracle.com> References: <4EE9208B.5040203@oracle.com> <4EF25CC1.6030105@oracle.com> <4EF43DB8.1080104@oracle.com> <4EF9D448.80305@oracle.com> Message-ID: <4EFAF192.7080605@oracle.com> Ramki, Quick follow-up on this. See below. On 12/27/2011 09:20 AM, Tony Printezis wrote: > >> It is probably true that the post-image's length is not used >> during GC once it's been copied, but it'd be good to check (I'm >> especially wary of CMS... but of course >> this is limited to G1 -- does G1 ever need to scan or iterate over >> regions that are subject to being copied >> into during an incremental pause?) > > This is of course something I was also worried about. In G1 we should > not be scanning to-space objects that are being copied during GC, not > only because the length might be incorrect due to this change but also > because there are no guarantees that the objects are well formed > (another thread might be in the process of copying them). For all > regions we copy objects into we call save_marks() so that we never go > over saved_mark() during scanning. > The above is correct. However your observation made me think of something related: we do of course scan the to-image of an object after we copy it to identify what it points to. When the object is chunked we use oop_iterate_range() to scan each chunk. I checked the definition of that method and it does not use the object's size / length when doing the scanning, it relies only on the start / end parameters passed to it. So, we're safe. :-) I updated the latest webrev I posted: http://cr.openjdk.java.net/~tonyp/7121623/webrev.1/ to include the following comment: 4674 // Process indexes [start,end). It will also process the header 4675 // along with the first chunk (i.e., the chunk with start == 0). 4676 // Note that at this point the length field of to_obj_array is not 4677 // correct given that we are using it to keep track of the next 4678 // start index. oop_iterate_range() (thankfully!) ignores the length 4679 // field and only relies on the start / end parameters. It does 4680 // however return the size of the object which will be incorrect. So 4681 // we have to ignore it even if we wanted to use it. 4682 to_obj_array->oop_iterate_range(&_scanner, start, end); Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.printezis at oracle.com Wed Dec 28 12:03:22 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 07:03:22 -0500 Subject: RFR(S): 7121496: G1: do the per-region evacuation failure handling work in parallel In-Reply-To: <4EF4D6A8.2070301@oracle.com> References: <4EF4D6A8.2070301@oracle.com> Message-ID: <4EFB058A.4090304@oracle.com> John, Thanks for doing this, it looks good. A few comments: g1CollectedHeap.cpp: 4102 assert(_g1h->g1_policy()->assertMarkedBytesDataOK(), "Should be!"); Since this will now be executed concurrently with other workers doing the self-forward removal it might pick up inconsistent information (not 100% sure that this will be the case, but I'd like be careful!). Why don't you stop calling it per region and only call it once at the start of remove_self_forwarding_pointers() (it's already called at the end). 4192 // Now reset the claim values in the regions in the collection set. 4193 ResetClaimValuesClosure reset_cv_cl; 4194 collection_set_iterate(&reset_cv_cl); This is fine but we already have: reset_heap_region_claim_values() check_heap_region_claim_values() and check_cset_heap_region_claim_values() Can you maybe introduce reset_cset_heap_region_claim_values() for consistency? BTW, I liked that you declared the update_rset_cl once per task. Tony On 12/23/2011 02:29 PM, John Cuthbertson wrote: > Hi Everyone, > > Can I have a couple of volunteers look of this set of changes? The > webrev can be found at: > http://cr.openjdk.java.net/~johnc/7121496/webrev.0/ > > Summary: > The work that gets done for each heap region in the collection set, in > the event of an evacuation failure, (e.g. removing self-forwarding > pointers, updating the BOT etc.) was serial. I parallelized it by > simply wrapping the work done for each region inside a HeapRegion > closure, whose doHeapRegion method claims a region and does the work > for that region. This HeapRegion closure is, in turn, wrapped in an > AbstractGangTask. > > Testing: GC test suite with both deferred and immediate RSet updates > (in some of the configurations - SPECjbb2000, SPECjbb2005, and > GCBasher can experience a number of evacuation failures); Kitchensink > with a forced evacuation failure mechanism. > > Thanks, > > JohnC > > From tony.printezis at oracle.com Wed Dec 28 12:04:08 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 07:04:08 -0500 Subject: CRR (XS): 7113006: G1: excessive ergo output when an evac failure happens Message-ID: <4EFB05B8.2030902@oracle.com> Hi all, Can I have a couple of code review for this very small change? http://cr.openjdk.java.net/~tonyp/7113006/webrev.0/ The excessive ergo output was generated by repeated failed heap expansion attempts during a GC. I slightly expanded (pun unintended!) the scope of the CR to not only stop generating the ergo output after the first failed heap expansion but also to not re-attempt the heap expansion. If heap expansion fails once, it will probably fail again so it's pointless to keep trying. Without doing a careful and in-depth performance analysis I see a mild improvement in GC times when an alloc failure happens with this fix. Tony From stefan.karlsson at oracle.com Wed Dec 28 15:15:45 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 28 Dec 2011 16:15:45 +0100 Subject: Review request (XS): 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 Message-ID: <4EFB32A1.1080100@oracle.com> http://cr.openjdk.java.net/~stefank/7125503/webrev.00/ Compiling hotspot with g++ 4.6.1 on Ubuntu 11.10 fails when compiling collectedHeap.cpp. src/share/vm/gc_interface/collectedHeap.cpp: In static member function ?static void CollectedHeap::test_is_in()?: src/share/vm/gc_interface/collectedHeap.cpp:485:3: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] From jon.masamitsu at oracle.com Wed Dec 28 15:16:12 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 07:16:12 -0800 Subject: CRR (XS): 7113006: G1: excessive ergo output when an evac failure happens In-Reply-To: <4EFB05B8.2030902@oracle.com> References: <4EFB05B8.2030902@oracle.com> Message-ID: <4EFB32BC.8070602@oracle.com> Tony, Change looks fine. Is it possible for a second thread to come in and take the new region just created by the expand? Not part of your change, but is this comment warranted? > 601 // Even though the heap was expanded, it might not have reached > 602 // the desired size. So, we cannot assume that the allocation > 603 // will succeed. I like comments but this one confused me a bit. Where are we assuming that the allocation will succeed? Seems like we're just doing the necessary thing by getting a region off the freelist. Yes, the result might be null but we still need to try and get a region. Jon On 12/28/2011 4:04 AM, Tony Printezis wrote: > Hi all, > > Can I have a couple of code review for this very small change? > > http://cr.openjdk.java.net/~tonyp/7113006/webrev.0/ > > The excessive ergo output was generated by repeated failed heap > expansion attempts during a GC. I slightly expanded (pun unintended!) > the scope of the CR to not only stop generating the ergo output after > the first failed heap expansion but also to not re-attempt the heap > expansion. If heap expansion fails once, it will probably fail again > so it's pointless to keep trying. Without doing a careful and in-depth > performance analysis I see a mild improvement in GC times when an > alloc failure happens with this fix. > > Tony > From jon.masamitsu at oracle.com Wed Dec 28 15:44:18 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 07:44:18 -0800 Subject: Review request (XS): 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 In-Reply-To: <4EFB32A1.1080100@oracle.com> References: <4EFB32A1.1080100@oracle.com> Message-ID: <4EFB3952.7050601@oracle.com> Looks good. On 12/28/2011 7:15 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7125503/webrev.00/ > > Compiling hotspot with g++ 4.6.1 on Ubuntu 11.10 fails when compiling > collectedHeap.cpp. > > src/share/vm/gc_interface/collectedHeap.cpp: In static member function > ?static void CollectedHeap::test_is_in()?: > src/share/vm/gc_interface/collectedHeap.cpp:485:3: error: cast to > pointer from integer of different size [-Werror=int-to-pointer-cast] From stefan.karlsson at oracle.com Wed Dec 28 16:04:38 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 28 Dec 2011 17:04:38 +0100 Subject: Review request (XS): 7125516: G1: ~ConcurrentMark() frees incorrectly Message-ID: <4EFB3E16.2040004@oracle.com> http://cr.openjdk.java.net/~stefank/7125516/webrev.00/ The ConcurrentMark desctructor _max_task_num which is a size_t and not a pointer to allocated memory. However, the ConcurrentMark desctructor is never called, so the biggest problem right now is that newer g++ compilers complain about this. Removed the broken, unused ConcurrentMark desctructor code. From tony.printezis at oracle.com Wed Dec 28 16:06:22 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 11:06:22 -0500 Subject: CRR (XS): 7113006: G1: excessive ergo output when an evac failure happens In-Reply-To: <4EFB32BC.8070602@oracle.com> References: <4EFB05B8.2030902@oracle.com> <4EFB32BC.8070602@oracle.com> Message-ID: <4EFB3E7E.6080708@oracle.com> Hi Jon, Thanks for the prompt code review! Inline. On 12/28/2011 10:16 AM, Jon Masamitsu wrote: > Tony, > > Change looks fine. Is it possible for a second thread to come in and > take > the new region just created by the expand? No. When a to-space region is replaced during a GC (whether it's survivor or old) we take the FreeList_lock (which guards the region free list). In the case of survivors, new_region() will (eventually) be called from attempt_allocation_locked(): inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t word_size) { assert(!isHumongous(word_size), "we should not be seeing humongous-size allocations in this path"); HeapWord* result = _survivor_gc_alloc_region.attempt_allocation(word_size, false /* bot_updates */); if (result == NULL) { MutexLockerEx x(FreeList_lock, Mutex::_no_safepoint_check_flag); result = _survivor_gc_alloc_region.attempt_allocation_locked(word_size, false /* bot_updates */); } ... (for old regions, the code is similar to the above) Also note that the only time new_region() will try to expand the heap (i.e., do_expand == true) is when we allocate a to-space region during GC. That method is also used for mutator allocation regions but in that case do_expand == false. I'll actually put an extra assert to make sure that it's clear in the code. > Not part of your change, but is this comment warranted? > >> 601 // Even though the heap was expanded, it might not have >> reached >> 602 // the desired size. So, we cannot assume that the >> allocation >> 603 // will succeed. > > I like comments but this one confused me a bit. Where are we assuming > that the allocation will succeed? Apologies, the comment is clearly unclear. :-) After expansion succeeds we call: res = _free_list.remove_head_or_null(); which will do what you expect (return the head or NULL). We could have called: res = _free_list.remove_head(); which assumes the free list head is non-NULL. So "we cannot assume that the allocation will succeed" refers to the use of the remove_head_or_null() method, instead of remove_head(). (As I said, you're totally right that this was very obscure.) Having said that, I think that if expansion succeeds the free list is also guaranteed to be non-empty. new_region() will always allocate a single region and we always expand the heap by an amount aligned to the heap region size (AFAIK at least). So, I _think_ using remove_head() there is probably OK. But I don't like tempting fate :-) and we just expanded the heap, so the extra check whether head is NULL or not is unlikely to cause any performance issues. So I'll leave the code as is and update the comment. I'll send out a new webrev shortly. Tony > Seems like we're just doing the necessary > thing by getting a region off the freelist. Yes, the result might be > null but > we still need to try and get a region. > > Jon > > > On 12/28/2011 4:04 AM, Tony Printezis wrote: >> Hi all, >> >> Can I have a couple of code review for this very small change? >> >> http://cr.openjdk.java.net/~tonyp/7113006/webrev.0/ >> >> The excessive ergo output was generated by repeated failed heap >> expansion attempts during a GC. I slightly expanded (pun unintended!) >> the scope of the CR to not only stop generating the ergo output after >> the first failed heap expansion but also to not re-attempt the heap >> expansion. If heap expansion fails once, it will probably fail again >> so it's pointless to keep trying. Without doing a careful and >> in-depth performance analysis I see a mild improvement in GC times >> when an alloc failure happens with this fix. >> >> Tony >> From tony.printezis at oracle.com Wed Dec 28 16:13:17 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 11:13:17 -0500 Subject: Review request (XS): 7125516: G1: ~ConcurrentMark() frees incorrectly In-Reply-To: <4EFB3E16.2040004@oracle.com> References: <4EFB3E16.2040004@oracle.com> Message-ID: <4EFB401D.6030006@oracle.com> Stefan, Looks good. Tony On 12/28/2011 11:04 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7125516/webrev.00/ > > The ConcurrentMark desctructor _max_task_num which is a size_t and not > a pointer to allocated memory. However, the ConcurrentMark desctructor > is never called, so the biggest problem right now is that newer g++ > compilers complain about this. > > Removed the broken, unused ConcurrentMark desctructor code. From tony.printezis at oracle.com Wed Dec 28 16:49:09 2011 From: tony.printezis at oracle.com (Tony Printezis) Date: Wed, 28 Dec 2011 11:49:09 -0500 Subject: CRR (XS): 7113006: G1: excessive ergo output when an evac failure happens In-Reply-To: <4EFB3E7E.6080708@oracle.com> References: <4EFB05B8.2030902@oracle.com> <4EFB32BC.8070602@oracle.com> <4EFB3E7E.6080708@oracle.com> Message-ID: <4EFB4885.20302@oracle.com> Hi all, New webrev based on what I discussed with Jon below: http://cr.openjdk.java.net/~tonyp/7113006/webrev.1/ Tony On 12/28/2011 11:06 AM, Tony Printezis wrote: > Hi Jon, > > Thanks for the prompt code review! Inline. > > On 12/28/2011 10:16 AM, Jon Masamitsu wrote: >> Tony, >> >> Change looks fine. Is it possible for a second thread to come in >> and take >> the new region just created by the expand? > > No. When a to-space region is replaced during a GC (whether it's > survivor or old) we take the FreeList_lock (which guards the region > free list). In the case of survivors, new_region() will (eventually) > be called from attempt_allocation_locked(): > > inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t > > word_size) { > assert(!isHumongous(word_size), > "we should not be seeing humongous-size allocations in this > path"); > > HeapWord* result = > _survivor_gc_alloc_region.attempt_allocation(word_size, > false /* > bot_updates */); > if (result == NULL) { > MutexLockerEx x(FreeList_lock, Mutex::_no_safepoint_check_flag); > result = > _survivor_gc_alloc_region.attempt_allocation_locked(word_size, > false /* > bot_updates */); > } > ... > > (for old regions, the code is similar to the above) > > Also note that the only time new_region() will try to expand the heap > (i.e., do_expand == true) is when we allocate a to-space region during > GC. That method is also used for mutator allocation regions but in > that case do_expand == false. I'll actually put an extra assert to > make sure that it's clear in the code. > > >> Not part of your change, but is this comment warranted? >> >>> 601 // Even though the heap was expanded, it might not have >>> reached >>> 602 // the desired size. So, we cannot assume that the >>> allocation >>> 603 // will succeed. >> >> I like comments but this one confused me a bit. Where are we assuming >> that the allocation will succeed? > > Apologies, the comment is clearly unclear. :-) After expansion > succeeds we call: > > res = _free_list.remove_head_or_null(); > > which will do what you expect (return the head or NULL). We could have > called: > > res = _free_list.remove_head(); > > which assumes the free list head is non-NULL. So "we cannot assume > that the allocation will succeed" refers to the use of the > remove_head_or_null() method, instead of remove_head(). (As I said, > you're totally right that this was very obscure.) > > Having said that, I think that if expansion succeeds the free list is > also guaranteed to be non-empty. new_region() will always allocate a > single region and we always expand the heap by an amount aligned to > the heap region size (AFAIK at least). So, I _think_ using > remove_head() there is probably OK. But I don't like tempting fate :-) > and we just expanded the heap, so the extra check whether head is NULL > or not is unlikely to cause any performance issues. So I'll leave the > code as is and update the comment. > > I'll send out a new webrev shortly. > > Tony > >> Seems like we're just doing the necessary >> thing by getting a region off the freelist. Yes, the result might be >> null but >> we still need to try and get a region. >> >> Jon >> >> >> On 12/28/2011 4:04 AM, Tony Printezis wrote: >>> Hi all, >>> >>> Can I have a couple of code review for this very small change? >>> >>> http://cr.openjdk.java.net/~tonyp/7113006/webrev.0/ >>> >>> The excessive ergo output was generated by repeated failed heap >>> expansion attempts during a GC. I slightly expanded (pun >>> unintended!) the scope of the CR to not only stop generating the >>> ergo output after the first failed heap expansion but also to not >>> re-attempt the heap expansion. If heap expansion fails once, it will >>> probably fail again so it's pointless to keep trying. Without doing >>> a careful and in-depth performance analysis I see a mild improvement >>> in GC times when an alloc failure happens with this fix. >>> >>> Tony >>> From jon.masamitsu at oracle.com Wed Dec 28 17:38:59 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 09:38:59 -0800 Subject: CRR (XS): 7113006: G1: excessive ergo output when an evac failure happens In-Reply-To: <4EFB4885.20302@oracle.com> References: <4EFB05B8.2030902@oracle.com> <4EFB32BC.8070602@oracle.com> <4EFB3E7E.6080708@oracle.com> <4EFB4885.20302@oracle.com> Message-ID: <4EFB5433.5090205@oracle.com> Ship it! On 12/28/2011 8:49 AM, Tony Printezis wrote: > Hi all, > > New webrev based on what I discussed with Jon below: > > http://cr.openjdk.java.net/~tonyp/7113006/webrev.1/ > > Tony > > On 12/28/2011 11:06 AM, Tony Printezis wrote: >> Hi Jon, >> >> Thanks for the prompt code review! Inline. >> >> On 12/28/2011 10:16 AM, Jon Masamitsu wrote: >>> Tony, >>> >>> Change looks fine. Is it possible for a second thread to come in >>> and take >>> the new region just created by the expand? >> >> No. When a to-space region is replaced during a GC (whether it's >> survivor or old) we take the FreeList_lock (which guards the region >> free list). In the case of survivors, new_region() will (eventually) >> be called from attempt_allocation_locked(): >> >> inline HeapWord* G1CollectedHeap::survivor_attempt_allocation(size_t >> >> word_size) { >> assert(!isHumongous(word_size), >> "we should not be seeing humongous-size allocations in this >> path"); >> >> HeapWord* result = >> _survivor_gc_alloc_region.attempt_allocation(word_size, >> false /* >> bot_updates */); >> if (result == NULL) { >> MutexLockerEx x(FreeList_lock, Mutex::_no_safepoint_check_flag); >> result = >> _survivor_gc_alloc_region.attempt_allocation_locked(word_size, >> false /* >> bot_updates */); >> } >> ... >> >> (for old regions, the code is similar to the above) >> >> Also note that the only time new_region() will try to expand the heap >> (i.e., do_expand == true) is when we allocate a to-space region >> during GC. That method is also used for mutator allocation regions >> but in that case do_expand == false. I'll actually put an extra >> assert to make sure that it's clear in the code. >> >> >>> Not part of your change, but is this comment warranted? >>> >>>> 601 // Even though the heap was expanded, it might not have >>>> reached >>>> 602 // the desired size. So, we cannot assume that the >>>> allocation >>>> 603 // will succeed. >>> >>> I like comments but this one confused me a bit. Where are we assuming >>> that the allocation will succeed? >> >> Apologies, the comment is clearly unclear. :-) After expansion >> succeeds we call: >> >> res = _free_list.remove_head_or_null(); >> >> which will do what you expect (return the head or NULL). We could >> have called: >> >> res = _free_list.remove_head(); >> >> which assumes the free list head is non-NULL. So "we cannot assume >> that the allocation will succeed" refers to the use of the >> remove_head_or_null() method, instead of remove_head(). (As I said, >> you're totally right that this was very obscure.) >> >> Having said that, I think that if expansion succeeds the free list is >> also guaranteed to be non-empty. new_region() will always allocate a >> single region and we always expand the heap by an amount aligned to >> the heap region size (AFAIK at least). So, I _think_ using >> remove_head() there is probably OK. But I don't like tempting fate >> :-) and we just expanded the heap, so the extra check whether head is >> NULL or not is unlikely to cause any performance issues. So I'll >> leave the code as is and update the comment. >> >> I'll send out a new webrev shortly. >> >> Tony >> >>> Seems like we're just doing the necessary >>> thing by getting a region off the freelist. Yes, the result might >>> be null but >>> we still need to try and get a region. >>> >>> Jon >>> >>> >>> On 12/28/2011 4:04 AM, Tony Printezis wrote: >>>> Hi all, >>>> >>>> Can I have a couple of code review for this very small change? >>>> >>>> http://cr.openjdk.java.net/~tonyp/7113006/webrev.0/ >>>> >>>> The excessive ergo output was generated by repeated failed heap >>>> expansion attempts during a GC. I slightly expanded (pun >>>> unintended!) the scope of the CR to not only stop generating the >>>> ergo output after the first failed heap expansion but also to not >>>> re-attempt the heap expansion. If heap expansion fails once, it >>>> will probably fail again so it's pointless to keep trying. Without >>>> doing a careful and in-depth performance analysis I see a mild >>>> improvement in GC times when an alloc failure happens with this fix. >>>> >>>> Tony >>>> From stefan.karlsson at oracle.com Wed Dec 28 19:06:32 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 28 Dec 2011 20:06:32 +0100 Subject: Review request (XS): 7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1 In-Reply-To: <4EFB32A1.1080100@oracle.com> References: <4EFB32A1.1080100@oracle.com> Message-ID: <4EFB68B8.9010605@oracle.com> http://cr.openjdk.java.net/~stefank/7125503/webrev.01 Updated webrev after some offline comments from Tony. StefanK On 12/28/2011 04:15 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7125503/webrev.00/ > > Compiling hotspot with g++ 4.6.1 on Ubuntu 11.10 fails when compiling > collectedHeap.cpp. > > src/share/vm/gc_interface/collectedHeap.cpp: In static member function > ?static void CollectedHeap::test_is_in()?: > src/share/vm/gc_interface/collectedHeap.cpp:485:3: error: cast to > pointer from integer of different size [-Werror=int-to-pointer-cast] From jon.masamitsu at oracle.com Wed Dec 28 23:32:35 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 15:32:35 -0800 Subject: hotspot-gc-use Digest, Vol 46, Issue 9 In-Reply-To: References: Message-ID: <4EFBA713.8080407@oracle.com> On 12/28/2011 1:17 PM, Guy Korland wrote: > Thanks for the answer, is there any chance you can also help with my other > question? > Is there a way with as with cms to control the "occupancy"? If you mean the occupancy at which CMS starts a collection, try -XX:CMSInitiatingOccupancyFraction=NN where NN is the percentage of the tenured generation at which a CMS collection will start. If you mean something else, please ask again. > Thanks, > Guy > > >> --- >> Date: Tue, 27 Dec 2011 14:06:53 -0800 >> From: Jon Masamitsu >> Subject: Re: Turning off generational GC >> To: hotspot-gc-use at openjdk.java.net >> Message-ID:<4EFA417D.4070009 at oracle.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> For the hotspot garbage collectors the short answer is "no" there is no >> way to >> turn off generational GC. I think it's even pretty deeply entrenched in >> G1 which >> is only logically generational. >> >> If CMS were not generational, in the best cause you would see pauses >> on the order of 20ms. Maybe much larger although less frequent. >> More likely would be concurrent mode failures which would lead to >> full GC's. >> >> >> On 12/27/2011 1:20 PM, Guy Korland wrote: >>> Hi, >>> >>> I hope this is the right forum for this. >>> It seems like no matter how small we set the young generation, it take > more >>> than 20ms. >>> Is there a way turn off generational GC, especially in CMS? >>> >>> Thanks, >>> Guy >>> >>> >>> >>> _______________________________________________ >>> hotspot-gc-use mailing list >>> hotspot-gc-use at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111227/99fc1a6a/attachment-0001.html >> ------------------------------ >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> >> >> End of hotspot-gc-use Digest, Vol 46, Issue 9 >> ********************************************* >> _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From jon.masamitsu at oracle.com Thu Dec 29 03:54:05 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 28 Dec 2011 19:54:05 -0800 Subject: Review request (XS): 7125516: G1: ~ConcurrentMark() frees incorrectly In-Reply-To: <4EFB3E16.2040004@oracle.com> References: <4EFB3E16.2040004@oracle.com> Message-ID: <4EFBE45D.3080602@oracle.com> Looks fine. On 12/28/2011 8:04 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/7125516/webrev.00/ > > The ConcurrentMark desctructor _max_task_num which is a size_t and not > a pointer to allocated memory. However, the ConcurrentMark desctructor > is never called, so the biggest problem right now is that newer g++ > compilers complain about this. > > Removed the broken, unused ConcurrentMark desctructor code. From stefan.karlsson at oracle.com Thu Dec 29 08:15:40 2011 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Thu, 29 Dec 2011 08:15:40 +0000 Subject: hg: hsx/hotspot-gc/hotspot: 7125516: G1: ~ConcurrentMark() frees incorrectly Message-ID: <20111229081544.628C94781F@hg.openjdk.java.net> Changeset: 776173fc2df9 Author: stefank Date: 2011-12-29 07:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/776173fc2df9 7125516: G1: ~ConcurrentMark() frees incorrectly Summary: Replaced the code with a ShouldNotReachHere Reviewed-by: tonyp, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp From jon.masamitsu at oracle.com Thu Dec 29 14:28:24 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 29 Dec 2011 06:28:24 -0800 Subject: hotspot-gc-use Digest, Vol 46, Issue 9 In-Reply-To: References: <4EFBA713.8080407@oracle.com> Message-ID: <4EFC7908.2010504@oracle.com> This is close to the CMS flag but is a percent of the entire heap (as opposed to the tenured generation for CMS). -XX:InitiatingHeapOccupancyPercent=NN On 12/29/11 01:45, Guy Korland wrote: > Yes, I'm familiar with this configuration for CMS. > Is there a similar configuration for G1? > > Thanks, > Guy > > > On Thu, Dec 29, 2011 at 1:32 AM, Jon Masamitsu > > wrote: > > > > On 12/28/2011 1:17 PM, Guy Korland wrote: > > Thanks for the answer, is there any chance you can also help > with my other > question? > Is there a way with as with cms to control the "occupancy"? > > > If you mean the occupancy at which CMS starts a collection, try > -XX:CMSInitiatingOccupancyFraction=NN where NN is the > percentage of the tenured generation at which a CMS collection > will start. > > If you mean something else, please ask again. > > > Thanks, > Guy > > > --- > Date: Tue, 27 Dec 2011 14:06:53 -0800 > From: Jon Masamitsu > > Subject: Re: Turning off generational GC > To: hotspot-gc-use at openjdk.java.net > > Message-ID:<4EFA417D.4070009 at oracle.com > > > Content-Type: text/plain; charset="iso-8859-1" > > For the hotspot garbage collectors the short answer is > "no" there is no > way to > turn off generational GC. I think it's even pretty deeply > entrenched in > G1 which > is only logically generational. > > If CMS were not generational, in the best cause you would > see pauses > on the order of 20ms. Maybe much larger although less > frequent. > More likely would be concurrent mode failures which would > lead to > full GC's. > > > On 12/27/2011 1:20 PM, Guy Korland wrote: > > Hi, > > I hope this is the right forum for this. > It seems like no matter how small we set the young > generation, it take > > more > > than 20ms. > Is there a way turn off generational GC, especially in > CMS? > > Thanks, > Guy > > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111227/99fc1a6a/attachment-0001.html > > ------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > > End of hotspot-gc-use Digest, Vol 46, Issue 9 > ********************************************* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From john.coomes at oracle.com Fri Dec 30 04:53:08 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:53:08 +0000 Subject: hg: hsx/hotspot-gc: 4 new changesets Message-ID: <20111230045308.ED2D147843@hg.openjdk.java.net> Changeset: 9acd7374ff8a Author: ohair Date: 2011-12-12 08:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/9acd7374ff8a 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: 00d13c40d7a7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/00d13c40d7a7 Merge Changeset: 237bc29afbfc Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/237bc29afbfc Merge Changeset: 5a5eaf6374bc Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/rev/5a5eaf6374bc Added tag jdk8-b19 for changeset 237bc29afbfc ! .hgtags From john.coomes at oracle.com Fri Dec 30 04:53:18 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:53:18 +0000 Subject: hg: hsx/hotspot-gc/corba: 5 new changesets Message-ID: <20111230045322.BE55647844@hg.openjdk.java.net> Changeset: 75529c21094f Author: ohair Date: 2011-12-12 08:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/75529c21094f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: 0289a94d653b Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/0289a94d653b Merge Changeset: 052dda3b5ce3 Author: dmeetry Date: 2011-12-18 22:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/052dda3b5ce3 7046238: new InitialContext(); hangs Summary: Synchronization on a single monitor for contactInfo parameters with identical hashCode() Reviewed-by: robm, skoppar ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java Changeset: e1366c5d84ef Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/e1366c5d84ef Merge Changeset: 51d8b6cb18c0 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/corba/rev/51d8b6cb18c0 Added tag jdk8-b19 for changeset e1366c5d84ef ! .hgtags From john.coomes at oracle.com Fri Dec 30 04:53:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:53:35 +0000 Subject: hg: hsx/hotspot-gc/jaxp: 5 new changesets Message-ID: <20111230045335.F094847845@hg.openjdk.java.net> Changeset: a482d45c93e9 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/a482d45c93e9 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: a49db7c01db7 Author: ohair Date: 2011-12-12 08:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/a49db7c01db7 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: f26e2ab2c2c7 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f26e2ab2c2c7 Merge Changeset: dffeb62b1a7f Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/dffeb62b1a7f Merge Changeset: f052abb8f374 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxp/rev/f052abb8f374 Added tag jdk8-b19 for changeset dffeb62b1a7f ! .hgtags From john.coomes at oracle.com Fri Dec 30 04:53:43 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:53:43 +0000 Subject: hg: hsx/hotspot-gc/jaxws: 5 new changesets Message-ID: <20111230045343.73A8947846@hg.openjdk.java.net> Changeset: 6d622b1b4db0 Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/6d622b1b4db0 7117110: Remove target 1.5 from jaxp and jaxws repo builds for mac Reviewed-by: alanb ! build.xml Changeset: 6d2030eacdac Author: ohair Date: 2011-12-12 08:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/6d2030eacdac 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties Changeset: b2e4ab8b5fa3 Author: lana Date: 2011-12-15 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b2e4ab8b5fa3 Merge Changeset: b73b733214aa Author: lana Date: 2011-12-23 16:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/b73b733214aa Merge Changeset: 2b2818e3386f Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jaxws/rev/2b2818e3386f Added tag jdk8-b19 for changeset b73b733214aa ! .hgtags From john.coomes at oracle.com Fri Dec 30 04:54:38 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Dec 2011 04:54:38 +0000 Subject: hg: hsx/hotspot-gc/jdk: 30 new changesets Message-ID: <20111230050012.C5B9A4784C@hg.openjdk.java.net> Changeset: 7dbc53242c2a Author: art Date: 2011-12-07 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/7dbc53242c2a 7117008: Warnings cleanup day: reduce number of javac warnings in the sun.awt package Reviewed-by: anthony, denis, bagiras ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/CausedFocusEvent.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/EventListenerAggregate.java - src/share/classes/sun/awt/FocusingTextField.java ! src/share/classes/sun/awt/HeadlessToolkit.java - src/share/classes/sun/awt/HorizBagLayout.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ModalityEvent.java - src/share/classes/sun/awt/OrientableFlowLayout.java ! src/share/classes/sun/awt/PaintEventDispatcher.java ! src/share/classes/sun/awt/PeerEvent.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 18925904efc2 Author: alexsch Date: 2011-12-12 15:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/18925904efc2 7105890: closed/javax/swing/JScrollBar/4708809/bug4708809.java deadlocks on MacOS Reviewed-by: alexp + test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 44b26d6a55a6 Author: alexsch Date: 2011-12-13 15:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/44b26d6a55a6 7112931: closed/javax/swing/JTabbedPane/6416920/bug6416920.java fails on MacOS Reviewed-by: alexp + test/javax/swing/JTabbedPane/6416920/bug6416920.java Changeset: 70233f5e909c Author: alexsch Date: 2011-12-13 17:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/70233f5e909c 7120869: javax/swing/JScrollBar/4708809/bug4708809.java fails on Windows Summary: The robot auto-delay is increased to fix the test failing on Windows. Reviewed-by: alexp ! test/javax/swing/JScrollBar/4708809/bug4708809.java Changeset: 032a91abc540 Author: alexsch Date: 2011-12-13 18:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/032a91abc540 7116950: Reduce number of warnings in swing Reviewed-by: art ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/ActionPropertyChangeListener.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/Box.java ! src/share/classes/javax/swing/BoxLayout.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/ComponentInputMap.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/MenuSelectionManager.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/border/AbstractBorder.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/border/EmptyBorder.java ! src/share/classes/javax/swing/border/MatteBorder.java ! src/share/classes/javax/swing/border/TitledBorder.java ! src/share/classes/javax/swing/event/AncestorEvent.java ! src/share/classes/javax/swing/event/ChangeEvent.java ! src/share/classes/javax/swing/event/EventListenerList.java ! src/share/classes/javax/swing/event/ListDataEvent.java ! src/share/classes/javax/swing/event/MenuDragMouseEvent.java ! src/share/classes/javax/swing/event/MenuEvent.java ! src/share/classes/javax/swing/event/MenuKeyEvent.java ! src/share/classes/javax/swing/event/PopupMenuEvent.java ! src/share/classes/javax/swing/plaf/ComponentUI.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java Changeset: 282b2ce90afe Author: lana Date: 2011-12-16 12:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/282b2ce90afe Merge ! src/share/classes/java/beans/PropertyDescriptor.java - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh Changeset: 75bd7295c706 Author: bagiras Date: 2011-12-19 15:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/75bd7295c706 7117334: Warnings cleanup day: reduce number of javac warnings in the java.awt package Reviewed-by: art, denis, alexsch ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AWTEventMulticaster.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/image/ColorModel.java Changeset: d15f38f08ce9 Author: denis Date: 2011-12-19 16:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d15f38f08ce9 7117011: Reduce number of warnings in sun/awt/windows and sun/awt/datatransfer Reviewed-by: art ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/windows/classes/sun/awt/windows/TranslucentWindowPainter.java ! src/windows/classes/sun/awt/windows/WBufferStrategy.java ! src/windows/classes/sun/awt/windows/WChoicePeer.java ! src/windows/classes/sun/awt/windows/WClipboard.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WDialogPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPageDialog.java ! src/windows/classes/sun/awt/windows/WPageDialogPeer.java ! src/windows/classes/sun/awt/windows/WPrintDialog.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: cded2429cdbf Author: anthony Date: 2011-12-20 12:48 +0300 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cded2429cdbf 7122796: SunToolkit constructor should create the EventQueue for the Main AppContext Summary: Always create an EQ for the main AppContext in SunToolkit constructor Reviewed-by: art ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/SunToolkit.java + test/java/awt/EventQueue/MainAppContext/MainAppContext.java Changeset: 94d7051cca13 Author: lana Date: 2011-12-20 15:26 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/94d7051cca13 Merge - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 4f0f9f9c4892 Author: smarks Date: 2011-12-07 12:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/4f0f9f9c4892 7117249: fix warnings in java.util.jar, .logging, .prefs, .zip Reviewed-by: alanb, dholmes, forax, sherman, smarks Contributed-by: Prasannaa , Martijn Verburg , Goerge_Albrecht , Graham Allan , Michael Barker ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/Manifest.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/zip/ZipEntry.java Changeset: f8897baf40ea Author: omajid Date: 2011-12-08 13:48 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/f8897baf40ea 7117612: Miscellaneous warnings in java.lang Reviewed-by: smarks, dholmes, alanb, darcy ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Void.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/ProcessEnvironment.java Changeset: 9bb7c3b97384 Author: smarks Date: 2011-12-08 14:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9bb7c3b97384 7118546: fix warnings in javax.xml.crypto, javax.script Reviewed-by: mullan ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java Changeset: 77d41c0e4ffc Author: jjh Date: 2011-12-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/77d41c0e4ffc 7117053: Fix build warnings in com/sun/tools/jdi/* Summary: Warnings fixed. Also reviewed by serguei.spitsyn at oracle.com, who is not yet an openjdk reviewer Reviewed-by: ksrini ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/jdwpgen/OutNode.java ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: c508f38245f8 Author: ngmr Date: 2011-12-12 11:41 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c508f38245f8 7118907: InetAddress.isReachable() should return false if sendto fails with EHOSTUNREACH Reviewed-by: alanb, chegar Contributed-by: Charles Lee ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c Changeset: 3216717f96f5 Author: dl Date: 2011-12-12 10:45 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3216717f96f5 7118066: Warnings in java.util.concurrent package Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/Exchanger.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! test/java/util/Collections/EmptyIterator.java Changeset: d4f9d7e86a92 Author: chegar Date: 2011-12-12 03:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/d4f9d7e86a92 Merge Changeset: 9c0a6185188f Author: ohair Date: 2011-12-12 08:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/9c0a6185188f 7119829: Adjust default jprt testing configuration Reviewed-by: alanb ! make/jprt.properties ! test/Makefile Changeset: c647ebb3c4f7 Author: naoto Date: 2011-12-13 15:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/c647ebb3c4f7 4808233: "Locale" not thread-safe Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java Changeset: e446c7d24d6c Author: lana Date: 2011-12-15 19:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/e446c7d24d6c Merge - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h Changeset: 33ac7a057b9c Author: chegar Date: 2011-12-16 16:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/33ac7a057b9c 7095980: Ensure HttpURLConnection (and supporting APIs) don't expose HttpOnly cookies Reviewed-by: michaelm ! src/share/classes/java/net/HttpCookie.java + src/share/classes/sun/misc/JavaNetHttpCookieAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/sun/net/www/protocol/http/HttpOnly.java Changeset: abbca81a98a7 Author: smarks Date: 2011-12-17 08:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/abbca81a98a7 7122235: stop the build if javac fails Reviewed-by: chegar, dholmes, mcimadamore, ohair ! make/common/Rules.gmk Changeset: 528eb0d43e3a Author: alanb Date: 2011-12-17 20:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/528eb0d43e3a 7087549: (fs) Files.newInputStream throws UOE for custom provider options Reviewed-by: alanb Contributed-by: brandon.passanisi at oracle.com ! src/share/classes/java/nio/file/spi/FileSystemProvider.java + test/java/nio/file/Files/CustomOptions.java Changeset: 5b27b978ed42 Author: sherman Date: 2011-12-19 14:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/5b27b978ed42 6990617: Regular expression doesn't match if unicode character next to a digit. Summary: updated RemoveQEQuotation() to deal with this case correctly Reviewed-by: sherman Contributed-by: stephen.flores at oracle.com ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 570f3d893596 Author: lana Date: 2011-12-20 15:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/570f3d893596 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java Changeset: 6f19ff39cff4 Author: lana Date: 2011-12-23 16:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/6f19ff39cff4 Merge - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java Changeset: 60dd940eb58e Author: yhuang Date: 2011-12-12 18:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/60dd940eb58e 7003124: In Bulgarian Locale DateFormat is wrong Reviewed-by: naoto, peytoia ! src/share/classes/sun/text/resources/FormatData_bg.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cd03cd0e0965 Author: mfang Date: 2011-12-15 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/cd03cd0e0965 Merge Changeset: 3778f8577305 Author: katleman Date: 2011-12-28 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/3778f8577305 Merge Changeset: 80350ee39fa8 Author: katleman Date: 2011-12-29 15:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/jdk/rev/80350ee39fa8 Added tag jdk8-b19 for changeset 3778f8577305 ! .hgtags From jon.masamitsu at oracle.com Fri Dec 30 16:08:37 2011 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 30 Dec 2011 08:08:37 -0800 Subject: hotspot-gc-use Digest, Vol 46, Issue 9 In-Reply-To: References: <4EFBA713.8080407@oracle.com> <4EFC7908.2010504@oracle.com> Message-ID: <4EFDE205.6010207@oracle.com> Not certain but I don't think there is an equivalent. On 12/30/2011 7:32 AM, Guy Korland wrote: > Thanks, I'll test it. Is there also something similar to - > UseCMSInitiatingOccupancyOnly ? > > Thanks, > Guy > > > > On Thu, Dec 29, 2011 at 4:28 PM, Jon Masamitsuwrote: > >> This is close to the CMS flag but is a percent of >> the entire heap (as opposed to the tenured >> generation for CMS). >> >> -XX:InitiatingHeapOccupancyPercent=NN >> >> >> On 12/29/11 01:45, Guy Korland wrote: >> >> Yes, I'm familiar with this configuration for CMS. >> Is there a similar configuration for G1? >> >> Thanks, >> Guy >> >> >> On Thu, Dec 29, 2011 at 1:32 AM, Jon Masamitsuwrote: >> >>> >>> On 12/28/2011 1:17 PM, Guy Korland wrote: >>> >>>> Thanks for the answer, is there any chance you can also help with my >>>> other >>>> question? >>>> Is there a way with as with cms to control the "occupancy"? >>>> >>> If you mean the occupancy at which CMS starts a collection, try >>> -XX:CMSInitiatingOccupancyFraction=NN where NN is the >>> percentage of the tenured generation at which a CMS collection >>> will start. >>> >>> If you mean something else, please ask again. >>> >>> >>> Thanks, >>>> Guy >>>> >>>> >>>> --- >>>>> Date: Tue, 27 Dec 2011 14:06:53 -0800 >>>>> From: Jon Masamitsu >>>>> Subject: Re: Turning off generational GC >>>>> To: hotspot-gc-use at openjdk.java.net >>>>> Message-ID:<4EFA417D.4070009 at oracle.com> >>>>> Content-Type: text/plain; charset="iso-8859-1" >>>>> >>>>> For the hotspot garbage collectors the short answer is "no" there is no >>>>> way to >>>>> turn off generational GC. I think it's even pretty deeply entrenched in >>>>> G1 which >>>>> is only logically generational. >>>>> >>>>> If CMS were not generational, in the best cause you would see pauses >>>>> on the order of 20ms. Maybe much larger although less frequent. >>>>> More likely would be concurrent mode failures which would lead to >>>>> full GC's. >>>>> >>>>> >>>>> On 12/27/2011 1:20 PM, Guy Korland wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I hope this is the right forum for this. >>>>>> It seems like no matter how small we set the young generation, it take >>>>>> >>>>> more >>>>> than 20ms. >>>>>> Is there a way turn off generational GC, especially in CMS? >>>>>> >>>>>> Thanks, >>>>>> Guy >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> hotspot-gc-use mailing list >>>>>> hotspot-gc-use at openjdk.java.net >>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>>>> >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: >>>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111227/99fc1a6a/attachment-0001.html >>>> >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> hotspot-gc-use mailing list >>>>> hotspot-gc-use at openjdk.java.net >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >>>>> >>>>> >>>>> End of hotspot-gc-use Digest, Vol 46, Issue 9 >>>>> ********************************************* >>>>> >>>>> _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From ysr1729 at gmail.com Fri Dec 30 21:26:43 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 30 Dec 2011 13:26:43 -0800 Subject: hotspot-gc-use Digest, Vol 46, Issue 9 In-Reply-To: <4EFDE205.6010207@oracle.com> References: <4EFBA713.8080407@oracle.com> <4EFC7908.2010504@oracle.com> <4EFDE205.6010207@oracle.com> Message-ID: As of sometime ago the only way to control G1 initiation was indeed via this flag, and in fact G1 did not ergonomically kick off a collection based on other factors (such as promotion rate) like CMS does. This may or may not have changed in the last two months, but someone like John Cuthbertson or Tony Printezis would know for sure. -- ramki On Fri, Dec 30, 2011 at 8:08 AM, Jon Masamitsu wrote: > Not certain but I don't think there is an equivalent. > > On 12/30/2011 7:32 AM, Guy Korland wrote: > > Thanks, I'll test it. Is there also something similar to - > > UseCMSInitiatingOccupancyOnly ? > > > > Thanks, > > Guy > > > > > > > > On Thu, Dec 29, 2011 at 4:28 PM, Jon Masamitsu >wrote: > > > >> This is close to the CMS flag but is a percent of > >> the entire heap (as opposed to the tenured > >> generation for CMS). > >> > >> -XX:InitiatingHeapOccupancyPercent=NN > >> > >> > >> On 12/29/11 01:45, Guy Korland wrote: > >> > >> Yes, I'm familiar with this configuration for CMS. > >> Is there a similar configuration for G1? > >> > >> Thanks, > >> Guy > >> > >> > >> On Thu, Dec 29, 2011 at 1:32 AM, Jon Masamitsu >wrote: > >> > >>> > >>> On 12/28/2011 1:17 PM, Guy Korland wrote: > >>> > >>>> Thanks for the answer, is there any chance you can also help with my > >>>> other > >>>> question? > >>>> Is there a way with as with cms to control the "occupancy"? > >>>> > >>> If you mean the occupancy at which CMS starts a collection, try > >>> -XX:CMSInitiatingOccupancyFraction=NN where NN is the > >>> percentage of the tenured generation at which a CMS collection > >>> will start. > >>> > >>> If you mean something else, please ask again. > >>> > >>> > >>> Thanks, > >>>> Guy > >>>> > >>>> > >>>> --- > >>>>> Date: Tue, 27 Dec 2011 14:06:53 -0800 > >>>>> From: Jon Masamitsu > >>>>> Subject: Re: Turning off generational GC > >>>>> To: hotspot-gc-use at openjdk.java.net > >>>>> Message-ID:<4EFA417D.4070009 at oracle.com> > >>>>> Content-Type: text/plain; charset="iso-8859-1" > >>>>> > >>>>> For the hotspot garbage collectors the short answer is "no" there is > no > >>>>> way to > >>>>> turn off generational GC. I think it's even pretty deeply > entrenched in > >>>>> G1 which > >>>>> is only logically generational. > >>>>> > >>>>> If CMS were not generational, in the best cause you would see pauses > >>>>> on the order of 20ms. Maybe much larger although less frequent. > >>>>> More likely would be concurrent mode failures which would lead to > >>>>> full GC's. > >>>>> > >>>>> > >>>>> On 12/27/2011 1:20 PM, Guy Korland wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I hope this is the right forum for this. > >>>>>> It seems like no matter how small we set the young generation, it > take > >>>>>> > >>>>> more > >>>>> than 20ms. > >>>>>> Is there a way turn off generational GC, especially in CMS? > >>>>>> > >>>>>> Thanks, > >>>>>> Guy > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> hotspot-gc-use mailing list > >>>>>> hotspot-gc-use at openjdk.java.net > >>>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > >>>>>> > >>>>> -------------- next part -------------- > >>>>> An HTML attachment was scrubbed... > >>>>> URL: > >>>>> > >>>> > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20111227/99fc1a6a/attachment-0001.html > >>>> > >>>>> ------------------------------ > >>>>> > >>>>> _______________________________________________ > >>>>> hotspot-gc-use mailing list > >>>>> hotspot-gc-use at openjdk.java.net > >>>>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > >>>>> > >>>>> > >>>>> End of hotspot-gc-use Digest, Vol 46, Issue 9 > >>>>> ********************************************* > >>>>> > >>>>> > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From ysr1729 at gmail.com Fri Dec 30 21:31:34 2011 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 30 Dec 2011 13:31:34 -0800 Subject: Review request (XS): 7125516: G1: ~ConcurrentMark() frees incorrectly In-Reply-To: <4EFB3E16.2040004@oracle.com> References: <4EFB3E16.2040004@oracle.com> Message-ID: Looks like that should have taken _tasks. -- ramki On Wed, Dec 28, 2011 at 8:04 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~**stefank/7125516/webrev.00/ > > The ConcurrentMark desctructor _max_task_num which is a size_t and not a > pointer to allocated memory. However, the ConcurrentMark desctructor is > never called, so the biggest problem right now is that newer g++ compilers > complain about this. > > Removed the broken, unused ConcurrentMark desctructor code. > -------------- next part -------------- An HTML attachment was scrubbed... URL: