From John.Coomes at oracle.com Mon May 3 14:59:23 2010 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 3 May 2010 14:59:23 -0700 Subject: heads-up - argument formatting for assert and friends Message-ID: <19423.18235.730930.640489@oracle.com> I recently pushed 6888954: argument formatting for assert() and friends to the hotspot-gc repo; it should make it to the main hotspot repo (http://hg.openjdk.java.net/jdk7/hotspot/hotspot) later today. The change allows assert(), guarantee(), fatal(), etc., to accept printf-like format strings in addition to string literals. The format strings and arguments are passed to a utility class that does the formatting; sample usage is: int num = foo(); assert(num == 0, err_msg("expected 0; num = %d", num)); where err_msg() constructs a temporary object with a buffer on the stack and returns a pointer to the formatted string. If you use this feature, be careful to avoid null pointer derefs, as you'll get less information from the assert, rather than more :-(. -John From john.r.rose at oracle.com Mon May 3 15:18:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 3 May 2010 15:18:50 -0700 Subject: heads-up - argument formatting for assert and friends In-Reply-To: <19423.18235.730930.640489@oracle.com> References: <19423.18235.730930.640489@oracle.com> Message-ID: <7EE710E9-A4EE-4B92-94BE-1707CADFBB97@oracle.com> Thanks for working on that. I know it took a long time. It's going to make fastdebug even more useful. -- John On May 3, 2010, at 2:59 PM, John Coomes wrote: > 6888954: argument formatting for assert() and friends From tony.printezis at oracle.com Mon May 3 17:03:08 2010 From: tony.printezis at oracle.com (tony.printezis at oracle.com) Date: Tue, 04 May 2010 00:03:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20100504000317.175D244CFD@hg.openjdk.java.net> Changeset: 615a9d95d265 Author: johnc Date: 2010-04-27 18:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/615a9d95d265 6946056: assert((intptr_t) sp()<=(intptr_t) result,"result must>=than stack pointer"), frame_x86.cpp:295 Summary: frame::interpreter_frame_monitor_end() will spuriously assert for a frame that spans 0x80000000. Cast values to intptr_t* (rather than intptr_t) so that an unsigned pointer compare is performed. Reviewed-by: never, jcoomes, pbk ! src/cpu/x86/vm/frame_x86.cpp Changeset: cff162798819 Author: jcoomes Date: 2009-10-11 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cff162798819 6888953: some calls to function-like macros are missing semicolons Reviewed-by: pbk, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/memory/blockOffsetTable.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/xmlstream.cpp Changeset: f03d0a26bf83 Author: jcoomes Date: 2010-04-22 13:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f03d0a26bf83 6888954: argument formatting for assert() and friends Reviewed-by: kvn, twisti, apetrusenko, never, dcubed ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp + test/runtime/6888954/vmerrors.sh Changeset: befdf73d6b82 Author: tonyp Date: 2010-05-03 16:31 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/befdf73d6b82 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp From Christian.Thalinger at Sun.COM Tue May 4 02:30:51 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 04 May 2010 11:30:51 +0200 Subject: Request for reviews (XXL): 6943304: remove tagged stack interpreter In-Reply-To: <20100428160208.GB9441@redhat.com> References: <1272389909.19839.158.camel@macbook> <20100428160208.GB9441@redhat.com> Message-ID: <1272965451.4703.60.camel@macbook> On Wed, 2010-04-28 at 17:02 +0100, Gary Benson wrote: > Works for me with the attached changes. Gary just pinged me on IRC and asked why I didn't push his additional changes? Honestly, I didn't see them and thought "with the attached changes" means "with the changes in the webrev". I should read the emails more thoroughly, sorry. I created: 6949423: remove tagged stack interpreter for Zero and push it in a minute. -- Christian From erik.trimble at oracle.com Tue May 4 20:20:05 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Wed, 05 May 2010 03:20:05 +0000 Subject: hg: hsx/hsx17/master: 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Message-ID: <20100505032007.50E7344052@hg.openjdk.java.net> Changeset: 9d9e74a1628e Author: iveresov Date: 2010-04-29 17:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/9d9e74a1628e 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Summary: Disable the use of pcmpestri until it can be guaranteed that the load doesn't cross in to the uncommited space. See 6942326. Reviewed-by: never, kvn ! src/share/vm/opto/library_call.cpp From eric.caspole at amd.com Wed May 5 18:03:21 2010 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 5 May 2010 18:03:21 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently Message-ID: In the current JVM, the nmethod sweeper runs during each safepoint, and may return early if there is no work to do. It periodically scans the thread stacks to determine if not-entrant nmethods have no lingering active stack frames and can be converted to zombies. It then walks the code cache promoting not-entrant nmethods to zombies if possible and deleting the zombies. It walks a fraction of the code cache in each turn, set by NmethodSweepFraction, which is 4 by default. When the whole code cache is traversed and no progress can be made, the sweeper will go idle until another nmethod becomes not- entrant, starting the process over again. In applications with a lot of compiled code, walking the code cache can take many milliseconds, contributing to long safepoint pause times, reducing application throughput. This change makes part of the sweeper work concurrent to reduce the safepoint pause time. In this webrev, the stack scans continue to happen at safepoint time but the code cache traversal is concurrent with the application. The traversal work runs on the compiler threads where they will check to sweep each time passing through the compile queue. They may take the code cache and stub related locks as necessary to do the sweeping safely. Only one thread will sweep at a time and it preserves the existing way of traversing in chunks by NmethodSweepFraction. There are a few adjustments to the checks regarding the code cache unloading feature to accommodate these changes. Also I added new convenience methods such as CodeCache::next_nmethod() for simple traversal. I worked out this design with Tom Rodriguez over the last month or so. We'd like some other eyes on it. The webrev is at http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ Thanks, Eric From vladimir.kozlov at oracle.com Wed May 5 23:51:46 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 05 May 2010 23:51:46 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently In-Reply-To: References: Message-ID: <4BE26702.3080804@oracle.com> Eric, It looks good. Just minor notes. Extend comment for your additional conditions: ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing && !CompileBroker::should_compile_new_jobs())) { Put first call javaTimeMillis under flag: + jlong sweep_start; + if(PrintMethodFlushing) + sweep_start = os::javaTimeMillis(); Thanks, Vladimir On 5/5/10 6:03 PM, Eric Caspole wrote: > In the current JVM, the nmethod sweeper runs during each safepoint, > and may return early if there is no work to do. It periodically scans > the thread stacks to determine if not-entrant nmethods have no > lingering active stack frames and can be converted to zombies. It > then walks the code cache promoting not-entrant nmethods to zombies > if possible and deleting the zombies. It walks a fraction of the code > cache in each turn, set by NmethodSweepFraction, which is 4 by > default. When the whole code cache is traversed and no progress can > be made, the sweeper will go idle until another nmethod becomes not- > entrant, starting the process over again. > > In applications with a lot of compiled code, walking the code cache > can take many milliseconds, contributing to long safepoint pause > times, reducing application throughput. This change makes part of the > sweeper work concurrent to reduce the safepoint pause time. > > In this webrev, the stack scans continue to happen at safepoint time > but the code cache traversal is concurrent with the application. The > traversal work runs on the compiler threads where they will check to > sweep each time passing through the compile queue. They may take the > code cache and stub related locks as necessary to do the sweeping > safely. Only one thread will sweep at a time and it preserves the > existing way of traversing in chunks by NmethodSweepFraction. > > There are a few adjustments to the checks regarding the code cache > unloading feature to accommodate these changes. Also I added new > convenience methods such as CodeCache::next_nmethod() for simple > traversal. > > I worked out this design with Tom Rodriguez over the last month or so. > We'd like some other eyes on it. > > The webrev is at > http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ > > Thanks, > Eric > > From erik.trimble at oracle.com Thu May 6 13:03:42 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Thu, 06 May 2010 20:03:42 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20100506200358.C22F54461D@hg.openjdk.java.net> Changeset: e0a1a502e402 Author: mikejwre Date: 2010-04-22 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e0a1a502e402 Added tag jdk7-b90 for changeset 605c9707a766 ! .hgtags Changeset: 7b03170e1fcb Author: trims Date: 2010-04-29 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7b03170e1fcb Merge Changeset: 310cdbc35535 Author: trims Date: 2010-04-29 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/310cdbc35535 6948636: Bump the HS18 build number to 04 Summary: Update the HS18 build number to 04 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 03a8443caa4b Author: mikejwre Date: 2010-04-29 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/03a8443caa4b Added tag jdk7-b91 for changeset e0a1a502e402 ! .hgtags Changeset: e3fa0cc77f74 Author: trims Date: 2010-05-04 12:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e3fa0cc77f74 Merge Changeset: 3221d1887d30 Author: trims Date: 2010-05-04 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3221d1887d30 Added tag hs18-b03 for changeset 25f53b53aaa3 ! .hgtags Changeset: 731bcbe3c9c4 Author: trims Date: 2010-05-06 12:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/731bcbe3c9c4 6950438: Add 6u18 and 6u20 release values explicitly to jprt.properties file Summary: modify jprt.properties to allow JPRT to use 6u18 and 6u18 targets Reviewed-by: ohair ! make/jprt.properties Changeset: 5dabb4e73380 Author: trims Date: 2010-05-06 13:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5dabb4e73380 Merge From Eric.Caspole at amd.com Fri May 7 09:27:19 2010 From: Eric.Caspole at amd.com (Eric Caspole) Date: Fri, 7 May 2010 09:27:19 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently In-Reply-To: <4BE26702.3080804@oracle.com> References: <4BE26702.3080804@oracle.com> Message-ID: <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> Thanks Vladimir, see rev 10: http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.10/ Eric On May 5, 2010, at 11:51 PM, Vladimir Kozlov wrote: > Eric, > > It looks good. Just minor notes. > > > Extend comment for your additional conditions: > > ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing > && !CompileBroker::should_compile_new_jobs())) { > > > Put first call javaTimeMillis under flag: > > + jlong sweep_start; > + if(PrintMethodFlushing) > + sweep_start = os::javaTimeMillis(); > > Thanks, > Vladimir > > > On 5/5/10 6:03 PM, Eric Caspole wrote: >> In the current JVM, the nmethod sweeper runs during each safepoint, >> and may return early if there is no work to do. It periodically scans >> the thread stacks to determine if not-entrant nmethods have no >> lingering active stack frames and can be converted to zombies. It >> then walks the code cache promoting not-entrant nmethods to zombies >> if possible and deleting the zombies. It walks a fraction of the code >> cache in each turn, set by NmethodSweepFraction, which is 4 by >> default. When the whole code cache is traversed and no progress can >> be made, the sweeper will go idle until another nmethod becomes not- >> entrant, starting the process over again. >> >> In applications with a lot of compiled code, walking the code cache >> can take many milliseconds, contributing to long safepoint pause >> times, reducing application throughput. This change makes part of the >> sweeper work concurrent to reduce the safepoint pause time. >> >> In this webrev, the stack scans continue to happen at safepoint time >> but the code cache traversal is concurrent with the application. The >> traversal work runs on the compiler threads where they will check to >> sweep each time passing through the compile queue. They may take the >> code cache and stub related locks as necessary to do the sweeping >> safely. Only one thread will sweep at a time and it preserves the >> existing way of traversing in chunks by NmethodSweepFraction. >> >> There are a few adjustments to the checks regarding the code cache >> unloading feature to accommodate these changes. Also I added new >> convenience methods such as CodeCache::next_nmethod() for simple >> traversal. >> >> I worked out this design with Tom Rodriguez over the last month or >> so. >> We'd like some other eyes on it. >> >> The webrev is at >> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ >> >> Thanks, >> Eric >> >> > From vladimir.kozlov at oracle.com Fri May 7 09:35:12 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 07 May 2010 09:35:12 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently In-Reply-To: <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> References: <4BE26702.3080804@oracle.com> <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> Message-ID: <4BE44140.3000709@oracle.com> Looks good. Vladimir On 5/7/10 9:27 AM, Eric Caspole wrote: > Thanks Vladimir, see rev 10: > > http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.10/ > > Eric > > > On May 5, 2010, at 11:51 PM, Vladimir Kozlov wrote: > >> Eric, >> >> It looks good. Just minor notes. >> >> >> Extend comment for your additional conditions: >> >> ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing && >> !CompileBroker::should_compile_new_jobs())) { >> >> >> Put first call javaTimeMillis under flag: >> >> + jlong sweep_start; >> + if(PrintMethodFlushing) >> + sweep_start = os::javaTimeMillis(); >> >> Thanks, >> Vladimir >> >> >> On 5/5/10 6:03 PM, Eric Caspole wrote: >>> In the current JVM, the nmethod sweeper runs during each safepoint, >>> and may return early if there is no work to do. It periodically scans >>> the thread stacks to determine if not-entrant nmethods have no >>> lingering active stack frames and can be converted to zombies. It >>> then walks the code cache promoting not-entrant nmethods to zombies >>> if possible and deleting the zombies. It walks a fraction of the code >>> cache in each turn, set by NmethodSweepFraction, which is 4 by >>> default. When the whole code cache is traversed and no progress can >>> be made, the sweeper will go idle until another nmethod becomes not- >>> entrant, starting the process over again. >>> >>> In applications with a lot of compiled code, walking the code cache >>> can take many milliseconds, contributing to long safepoint pause >>> times, reducing application throughput. This change makes part of the >>> sweeper work concurrent to reduce the safepoint pause time. >>> >>> In this webrev, the stack scans continue to happen at safepoint time >>> but the code cache traversal is concurrent with the application. The >>> traversal work runs on the compiler threads where they will check to >>> sweep each time passing through the compile queue. They may take the >>> code cache and stub related locks as necessary to do the sweeping >>> safely. Only one thread will sweep at a time and it preserves the >>> existing way of traversing in chunks by NmethodSweepFraction. >>> >>> There are a few adjustments to the checks regarding the code cache >>> unloading feature to accommodate these changes. Also I added new >>> convenience methods such as CodeCache::next_nmethod() for simple >>> traversal. >>> >>> I worked out this design with Tom Rodriguez over the last month or so. >>> We'd like some other eyes on it. >>> >>> The webrev is at >>> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ >>> >>> Thanks, >>> Eric >>> >>> >> > > From tom.rodriguez at oracle.com Fri May 7 11:23:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 7 May 2010 11:23:46 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently In-Reply-To: <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> References: <4BE26702.3080804@oracle.com> <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> Message-ID: <1E2D21C5-FCF7-485C-90E8-4BA354A55A83@oracle.com> There's still some language in sweeper.cpp about running at a safepoint. I know scan_stacks still does but the other parts don't. In particular this comment: // long time we don't want to keep rescanning at every safepoint. should lose the "at every safepoint" part. This needs updating: // Shut off compiler. Sweeper will run exiting from this safepoint // and turn it back on if it clears enough space and this: if (UseCodeCacheFlushing) { if (!CodeCache::needs_flushing()) { // In a safepoint, no race with setters _advise_to_sweep = 0; } probably needs some sort of fix. Otherwise this looks good. tom On May 7, 2010, at 9:27 AM, Eric Caspole wrote: > Thanks Vladimir, see rev 10: > > http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.10/ > > Eric > > > On May 5, 2010, at 11:51 PM, Vladimir Kozlov wrote: > >> Eric, >> >> It looks good. Just minor notes. >> >> >> Extend comment for your additional conditions: >> >> ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing && !CompileBroker::should_compile_new_jobs())) { >> >> >> Put first call javaTimeMillis under flag: >> >> + jlong sweep_start; >> + if(PrintMethodFlushing) >> + sweep_start = os::javaTimeMillis(); >> >> Thanks, >> Vladimir >> >> >> On 5/5/10 6:03 PM, Eric Caspole wrote: >>> In the current JVM, the nmethod sweeper runs during each safepoint, >>> and may return early if there is no work to do. It periodically scans >>> the thread stacks to determine if not-entrant nmethods have no >>> lingering active stack frames and can be converted to zombies. It >>> then walks the code cache promoting not-entrant nmethods to zombies >>> if possible and deleting the zombies. It walks a fraction of the code >>> cache in each turn, set by NmethodSweepFraction, which is 4 by >>> default. When the whole code cache is traversed and no progress can >>> be made, the sweeper will go idle until another nmethod becomes not- >>> entrant, starting the process over again. >>> >>> In applications with a lot of compiled code, walking the code cache >>> can take many milliseconds, contributing to long safepoint pause >>> times, reducing application throughput. This change makes part of the >>> sweeper work concurrent to reduce the safepoint pause time. >>> >>> In this webrev, the stack scans continue to happen at safepoint time >>> but the code cache traversal is concurrent with the application. The >>> traversal work runs on the compiler threads where they will check to >>> sweep each time passing through the compile queue. They may take the >>> code cache and stub related locks as necessary to do the sweeping >>> safely. Only one thread will sweep at a time and it preserves the >>> existing way of traversing in chunks by NmethodSweepFraction. >>> >>> There are a few adjustments to the checks regarding the code cache >>> unloading feature to accommodate these changes. Also I added new >>> convenience methods such as CodeCache::next_nmethod() for simple >>> traversal. >>> >>> I worked out this design with Tom Rodriguez over the last month or so. >>> We'd like some other eyes on it. >>> >>> The webrev is at >>> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ >>> >>> Thanks, >>> Eric >>> >>> >> > > From john.coomes at oracle.com Fri May 7 11:36:43 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:36:43 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b92 for changeset 5f5c33d417f3 Message-ID: <20100507183644.03C29448E8@hg.openjdk.java.net> Changeset: b7b4797303cb Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/b7b4797303cb Added tag jdk7-b92 for changeset 5f5c33d417f3 ! .hgtags From john.coomes at oracle.com Fri May 7 11:36:47 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:36:47 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b92 for changeset 930582f667a1 Message-ID: <20100507183648.E827D448E9@hg.openjdk.java.net> Changeset: ae18df0d4767 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ae18df0d4767 Added tag jdk7-b92 for changeset 930582f667a1 ! .hgtags From john.coomes at oracle.com Fri May 7 11:39:24 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:39:24 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b92 for changeset e6a40e4bb104 Message-ID: <20100507183924.EBD8A448EA@hg.openjdk.java.net> Changeset: c725ca829c5a Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/c725ca829c5a Added tag jdk7-b92 for changeset e6a40e4bb104 ! .hgtags From john.coomes at oracle.com Fri May 7 11:39:27 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:39:27 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b92 for changeset df7c033f6a11 Message-ID: <20100507183928.0EB1F448EB@hg.openjdk.java.net> Changeset: 797bef191975 Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/797bef191975 Added tag jdk7-b92 for changeset df7c033f6a11 ! .hgtags From john.coomes at oracle.com Fri May 7 11:39:33 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:39:33 +0000 Subject: hg: jdk7/hotspot/jdk: Added tag jdk7-b92 for changeset f2dce7210cc0 Message-ID: <20100507184000.B264D448ED@hg.openjdk.java.net> Changeset: fa09af0e5b7c Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fa09af0e5b7c Added tag jdk7-b92 for changeset f2dce7210cc0 ! .hgtags From john.coomes at oracle.com Fri May 7 11:41:58 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 07 May 2010 18:41:58 +0000 Subject: hg: jdk7/hotspot/langtools: Added tag jdk7-b92 for changeset 98cba5876cb5 Message-ID: <20100507184203.4D093448EE@hg.openjdk.java.net> Changeset: 683cd1f6bc4b Author: mikejwre Date: 2010-05-06 18:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/683cd1f6bc4b Added tag jdk7-b92 for changeset 98cba5876cb5 ! .hgtags From erik.trimble at oracle.com Fri May 7 15:13:49 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 07 May 2010 22:13:49 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20100507221355.EA5A944967@hg.openjdk.java.net> Changeset: fd3de7134574 Author: mikejwre Date: 2010-05-06 18:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fd3de7134574 Added tag jdk7-b92 for changeset 3221d1887d30 ! .hgtags Changeset: 80ccc94456b2 Author: trims Date: 2010-05-07 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/80ccc94456b2 Merge Changeset: 359375cb7de6 Author: trims Date: 2010-05-07 15:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/359375cb7de6 Added tag hs18-b04 for changeset 310cdbc35535 ! .hgtags From tom.rodriguez at oracle.com Mon May 10 11:01:52 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 11:01:52 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK Message-ID: http://cr.openjdk.java.net/~never/6951190 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK Reviewed-by: This looks to be a long standing issue with the String.equals intrinsic. The code checks that the argument is a String but it never actually casts it to be a String. Later on when we're processing types for the AddP for the String.count field we're looking for a field at +20 in Object which of course doesn't exist so we hit that assert. The fix is to perform a real checkcast which includes to required cast to String. I also added an assert to check the contract with gen_checkcast that it always returns non-null failure_control. Tested by hand with failing JDK build. From vladimir.kozlov at oracle.com Mon May 10 11:25:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 May 2010 11:25:44 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: References: Message-ID: <4BE84FA8.3000307@oracle.com> No. It will not handle situation when statically we don't know if argument is NULL. And it will no work for NULL stopped() situation since 'failure' node will be NULL so merge region will not have valid paths. Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? Vladimir Tom Rodriguez wrote: > The !stopped() logic should handle that. > > tom > > On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: > >> Tom, >> >> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >> >> Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6951190 > > 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK > Reviewed-by: > > This looks to be a long standing issue with the String.equals > intrinsic. The code checks that the argument is a String but it never > actually casts it to be a String. Later on when we're processing > types for the AddP for the String.count field we're looking for a > field at +20 in Object which of course doesn't exist so we hit that > assert. The fix is to perform a real checkcast which includes to > required cast to String. I also added an assert to check the contract > with gen_checkcast that it always returns non-null failure_control. > Tested by hand with failing JDK build. From tom.rodriguez at oracle.com Mon May 10 11:51:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 11:51:46 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <4BE84FA8.3000307@oracle.com> References: <4BE84FA8.3000307@oracle.com> Message-ID: On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: > No. It will not handle situation when statically we don't know if argument is NULL. > And it will no work for NULL stopped() situation since 'failure' node will be NULL > so merge region will not have valid paths. You're right that I'm not handling the argument == null case properly. > > Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal ciInstanceKlass* klass = env()->String_klass(); if (!stopped()) { - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); - - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); - //instanceOf == true, fallthrough - - if (inst_false != NULL) { - phi->init_req(3, intcon(0)); - region->init_req(3, inst_false); + Node* inst_false = NULL; + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); + phi->init_req(3, intcon(0)); + region->init_req(3, inst_false ? inst_false : top()); + if (argument == null()) { + set_control(top()); } } tom > > Vladimir > > Tom Rodriguez wrote: > > The !stopped() logic should handle that. > > > > tom > > > > On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: > > > >> Tom, > >> > >> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. > >> > >> Vladimir > > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6951190 >> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >> Reviewed-by: >> This looks to be a long standing issue with the String.equals >> intrinsic. The code checks that the argument is a String but it never >> actually casts it to be a String. Later on when we're processing >> types for the AddP for the String.count field we're looking for a >> field at +20 in Object which of course doesn't exist so we hit that >> assert. The fix is to perform a real checkcast which includes to >> required cast to String. I also added an assert to check the contract >> with gen_checkcast that it always returns non-null failure_control. >> Tested by hand with failing JDK build. From tom.rodriguez at oracle.com Mon May 10 11:58:21 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 11:58:21 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: References: <4BE84FA8.3000307@oracle.com> Message-ID: That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. tom On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: > > On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: > >> No. It will not handle situation when statically we don't know if argument is NULL. >> And it will no work for NULL stopped() situation since 'failure' node will be NULL >> so merge region will not have valid paths. > > You're right that I'm not handling the argument == null case properly. > >> >> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? > > I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: > > diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp > --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 > +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 > @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal > ciInstanceKlass* klass = env()->String_klass(); > > if (!stopped()) { > - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); > - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); > - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); > - > - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); > - //instanceOf == true, fallthrough > - > - if (inst_false != NULL) { > - phi->init_req(3, intcon(0)); > - region->init_req(3, inst_false); > + Node* inst_false = NULL; > + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); > + phi->init_req(3, intcon(0)); > + region->init_req(3, inst_false ? inst_false : top()); > + if (argument == null()) { > + set_control(top()); > } > } > > tom > >> >> Vladimir >> >> Tom Rodriguez wrote: >>> The !stopped() logic should handle that. >>> >>> tom >>> >>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>> >>>> Tom, >>>> >>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>> >>>> Vladimir >> >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6951190 >>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>> Reviewed-by: >>> This looks to be a long standing issue with the String.equals >>> intrinsic. The code checks that the argument is a String but it never >>> actually casts it to be a String. Later on when we're processing >>> types for the AddP for the String.count field we're looking for a >>> field at +20 in Object which of course doesn't exist so we hit that >>> assert. The fix is to perform a real checkcast which includes to >>> required cast to String. I also added an assert to check the contract >>> with gen_checkcast that it always returns non-null failure_control. >>> Tested by hand with failing JDK build. > From tom.rodriguez at Oracle.com Mon May 10 12:18:19 2010 From: tom.rodriguez at Oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 12:18:19 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: References: <4BE84FA8.3000307@oracle.com> Message-ID: <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? const TypeInstPtr* string_type = TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. tom On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: > That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. > > tom > > On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: > >> >> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >> >>> No. It will not handle situation when statically we don't know if argument is NULL. >>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>> so merge region will not have valid paths. >> >> You're right that I'm not handling the argument == null case properly. >> >>> >>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >> >> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >> >> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp >> --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 >> +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 >> @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >> ciInstanceKlass* klass = env()->String_klass(); >> >> if (!stopped()) { >> - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); >> - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); >> - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); >> - >> - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); >> - //instanceOf == true, fallthrough >> - >> - if (inst_false != NULL) { >> - phi->init_req(3, intcon(0)); >> - region->init_req(3, inst_false); >> + Node* inst_false = NULL; >> + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); >> + phi->init_req(3, intcon(0)); >> + region->init_req(3, inst_false ? inst_false : top()); >> + if (argument == null()) { >> + set_control(top()); >> } >> } >> >> tom >> >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> The !stopped() logic should handle that. >>>> >>>> tom >>>> >>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>> >>>>> Tom, >>>>> >>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>> >>>>> Vladimir >>> >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6951190 >>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>> Reviewed-by: >>>> This looks to be a long standing issue with the String.equals >>>> intrinsic. The code checks that the argument is a String but it never >>>> actually casts it to be a String. Later on when we're processing >>>> types for the AddP for the String.count field we're looking for a >>>> field at +20 in Object which of course doesn't exist so we hit that >>>> assert. The fix is to perform a real checkcast which includes to >>>> required cast to String. I also added an assert to check the contract >>>> with gen_checkcast that it always returns non-null failure_control. >>>> Tested by hand with failing JDK build. >> > From vladimir.kozlov at oracle.com Mon May 10 12:44:50 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 May 2010 12:44:50 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> References: <4BE84FA8.3000307@oracle.com> <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> Message-ID: <4BE86232.6070007@oracle.com> It could be just historical. I looked on the original code and it starts with TypeOopPtr::make(TypePtr::BotPTR, klass, NULL, 0) in inline_string_compareTo(). Then it was changed to TypeInstPtr::make(), added false for xk. And later it was copy/past into other intrinsic methods. I agree that we can use TypeOopPtr::make(klass) here. Your changes with CheckCastPPNode are good. Vladimir Tom Rodriguez wrote: > I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? > > const TypeInstPtr* string_type = > TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); > > TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. > > tom > > On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: > >> That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. >> >> tom >> >> On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: >> >>> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >>> >>>> No. It will not handle situation when statically we don't know if argument is NULL. >>>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>>> so merge region will not have valid paths. >>> You're right that I'm not handling the argument == null case properly. >>> >>>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >>> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >>> >>> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp >>> --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 >>> +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 >>> @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >>> ciInstanceKlass* klass = env()->String_klass(); >>> >>> if (!stopped()) { >>> - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); >>> - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); >>> - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); >>> - >>> - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); >>> - //instanceOf == true, fallthrough >>> - >>> - if (inst_false != NULL) { >>> - phi->init_req(3, intcon(0)); >>> - region->init_req(3, inst_false); >>> + Node* inst_false = NULL; >>> + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); >>> + phi->init_req(3, intcon(0)); >>> + region->init_req(3, inst_false ? inst_false : top()); >>> + if (argument == null()) { >>> + set_control(top()); >>> } >>> } >>> >>> tom >>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> The !stopped() logic should handle that. >>>>> >>>>> tom >>>>> >>>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>>> >>>>>> Tom, >>>>>> >>>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>>> >>>>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6951190 >>>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>>> Reviewed-by: >>>>> This looks to be a long standing issue with the String.equals >>>>> intrinsic. The code checks that the argument is a String but it never >>>>> actually casts it to be a String. Later on when we're processing >>>>> types for the AddP for the String.count field we're looking for a >>>>> field at +20 in Object which of course doesn't exist so we hit that >>>>> assert. The fix is to perform a real checkcast which includes to >>>>> required cast to String. I also added an assert to check the contract >>>>> with gen_checkcast that it always returns non-null failure_control. >>>>> Tested by hand with failing JDK build. > From tom.rodriguez at oracle.com Mon May 10 13:12:17 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 13:12:17 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <4BE86232.6070007@oracle.com> References: <4BE84FA8.3000307@oracle.com> <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> <4BE86232.6070007@oracle.com> Message-ID: <3FA0D103-769B-4FBE-8AB1-0CDF81B4F0D8@oracle.com> Do you mind if I change them to TypeOopPtr::make_from_klass? I'd added an assert to confirm that they produce the same thing when I was testing this. tom On May 10, 2010, at 12:44 PM, Vladimir Kozlov wrote: > It could be just historical. > I looked on the original code and it starts with TypeOopPtr::make(TypePtr::BotPTR, klass, NULL, 0) in inline_string_compareTo(). > Then it was changed to TypeInstPtr::make(), added false for xk. And later it was copy/past into other intrinsic methods. > > I agree that we can use TypeOopPtr::make(klass) here. > > Your changes with CheckCastPPNode are good. > > Vladimir > > Tom Rodriguez wrote: >> I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? >> const TypeInstPtr* string_type = >> TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); >> TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. >> tom >> On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: >>> That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. >>> >>> tom >>> >>> On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: >>> >>>> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >>>> >>>>> No. It will not handle situation when statically we don't know if argument is NULL. >>>>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>>>> so merge region will not have valid paths. >>>> You're right that I'm not handling the argument == null case properly. >>>> >>>>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >>>> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >>>> >>>> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >>>> ciInstanceKlass* klass = env()->String_klass(); >>>> if (!stopped()) { - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); - - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); - //instanceOf == true, fallthrough - - if (inst_false != NULL) { - phi->init_req(3, intcon(0)); - region->init_req(3, inst_false); + Node* inst_false = NULL; + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); + phi->init_req(3, intcon(0)); + region->init_req(3, inst_false ? inst_false : top()); + if (argument == null()) { + set_control(top()); } } >>>> >>>> tom >>>> >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> The !stopped() logic should handle that. >>>>>> >>>>>> tom >>>>>> >>>>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Tom, >>>>>>> >>>>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>>>> >>>>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6951190 >>>>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>>>> Reviewed-by: >>>>>> This looks to be a long standing issue with the String.equals >>>>>> intrinsic. The code checks that the argument is a String but it never >>>>>> actually casts it to be a String. Later on when we're processing >>>>>> types for the AddP for the String.count field we're looking for a >>>>>> field at +20 in Object which of course doesn't exist so we hit that >>>>>> assert. The fix is to perform a real checkcast which includes to >>>>>> required cast to String. I also added an assert to check the contract >>>>>> with gen_checkcast that it always returns non-null failure_control. >>>>>> Tested by hand with failing JDK build. From vladimir.kozlov at oracle.com Mon May 10 13:36:19 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 May 2010 13:36:19 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <3FA0D103-769B-4FBE-8AB1-0CDF81B4F0D8@oracle.com> References: <4BE84FA8.3000307@oracle.com> <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> <4BE86232.6070007@oracle.com> <3FA0D103-769B-4FBE-8AB1-0CDF81B4F0D8@oracle.com> Message-ID: <4BE86E43.5070503@oracle.com> I agree to change them. Vladimir Tom Rodriguez wrote: > Do you mind if I change them to TypeOopPtr::make_from_klass? I'd added an assert to confirm that they produce the same thing when I was testing this. > > tom > > On May 10, 2010, at 12:44 PM, Vladimir Kozlov wrote: > >> It could be just historical. >> I looked on the original code and it starts with TypeOopPtr::make(TypePtr::BotPTR, klass, NULL, 0) in inline_string_compareTo(). >> Then it was changed to TypeInstPtr::make(), added false for xk. And later it was copy/past into other intrinsic methods. >> >> I agree that we can use TypeOopPtr::make(klass) here. >> >> Your changes with CheckCastPPNode are good. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? >>> const TypeInstPtr* string_type = >>> TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); >>> TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. >>> tom >>> On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: >>>> That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. >>>> >>>> tom >>>> >>>> On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: >>>> >>>>> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >>>>> >>>>>> No. It will not handle situation when statically we don't know if argument is NULL. >>>>>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>>>>> so merge region will not have valid paths. >>>>> You're right that I'm not handling the argument == null case properly. >>>>> >>>>>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >>>>> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >>>>> >>>>> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >>>>> ciInstanceKlass* klass = env()->String_klass(); >>>>> if (!stopped()) { - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); - - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); - //instanceOf == true, fallthrough - - if (inst_false != NULL) { - phi->init_req(3, intcon(0)); - region->init_req(3, inst_false); + Node* inst_false = NULL; + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); + phi->init_req(3, intcon(0) ); + region->init_req(3, inst_false ? inst_false : top()); + if (argument == null()) { + set_control(top()); } } >>>>> >>>>> tom >>>>> >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> The !stopped() logic should handle that. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Tom, >>>>>>>> >>>>>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>>>>> >>>>>>>> Vladimir >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/6951190 >>>>>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>>>>> Reviewed-by: >>>>>>> This looks to be a long standing issue with the String.equals >>>>>>> intrinsic. The code checks that the argument is a String but it never >>>>>>> actually casts it to be a String. Later on when we're processing >>>>>>> types for the AddP for the String.count field we're looking for a >>>>>>> field at +20 in Object which of course doesn't exist so we hit that >>>>>>> assert. The fix is to perform a real checkcast which includes to >>>>>>> required cast to String. I also added an assert to check the contract >>>>>>> with gen_checkcast that it always returns non-null failure_control. >>>>>>> Tested by hand with failing JDK build. > From tom.rodriguez at oracle.com Mon May 10 14:43:30 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 10 May 2010 14:43:30 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <4BE86E43.5070503@oracle.com> References: <4BE84FA8.3000307@oracle.com> <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> <4BE86232.6070007@oracle.com> <3FA0D103-769B-4FBE-8AB1-0CDF81B4F0D8@oracle.com> <4BE86E43.5070503@oracle.com> Message-ID: <811E37D7-8B98-4BEC-AC30-270EA4B9C935@oracle.com> I've corrected all the copies and updated the webrev. tom On May 10, 2010, at 1:36 PM, Vladimir Kozlov wrote: > I agree to change them. > > Vladimir > > Tom Rodriguez wrote: >> Do you mind if I change them to TypeOopPtr::make_from_klass? I'd added an assert to confirm that they produce the same thing when I was testing this. >> tom >> On May 10, 2010, at 12:44 PM, Vladimir Kozlov wrote: >>> It could be just historical. >>> I looked on the original code and it starts with TypeOopPtr::make(TypePtr::BotPTR, klass, NULL, 0) in inline_string_compareTo(). >>> Then it was changed to TypeInstPtr::make(), added false for xk. And later it was copy/past into other intrinsic methods. >>> >>> I agree that we can use TypeOopPtr::make(klass) here. >>> >>> Your changes with CheckCastPPNode are good. >>> >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? >>>> const TypeInstPtr* string_type = >>>> TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); >>>> TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. >>>> tom >>>> On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: >>>>> That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. >>>>> >>>>> tom >>>>> >>>>> On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: >>>>> >>>>>> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >>>>>> >>>>>>> No. It will not handle situation when statically we don't know if argument is NULL. >>>>>>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>>>>>> so merge region will not have valid paths. >>>>>> You're right that I'm not handling the argument == null case properly. >>>>>> >>>>>>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >>>>>> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >>>>>> >>>>>> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >>>>>> ciInstanceKlass* klass = env()->String_klass(); if (!stopped()) { - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); - - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); - //instanceOf == true, fallthrough > - - if (inst_false != NULL) { - phi->init_req(3, intcon(0)); - region->init_req(3, inst_false); + Node* inst_false = NULL; + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); + phi->init_req(3, intcon(0) > ); + region->init_req(3, inst_false ? inst_false : top()); + if (argument == null()) { + set_control(top()); } } >>>>>> >>>>>> tom >>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> The !stopped() logic should handle that. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Tom, >>>>>>>>> >>>>>>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>> Tom Rodriguez wrote: >>>>>>>> http://cr.openjdk.java.net/~never/6951190 >>>>>>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>>>>>> Reviewed-by: >>>>>>>> This looks to be a long standing issue with the String.equals >>>>>>>> intrinsic. The code checks that the argument is a String but it never >>>>>>>> actually casts it to be a String. Later on when we're processing >>>>>>>> types for the AddP for the String.count field we're looking for a >>>>>>>> field at +20 in Object which of course doesn't exist so we hit that >>>>>>>> assert. The fix is to perform a real checkcast which includes to >>>>>>>> required cast to String. I also added an assert to check the contract >>>>>>>> with gen_checkcast that it always returns non-null failure_control. >>>>>>>> Tested by hand with failing JDK build. From vladimir.kozlov at oracle.com Mon May 10 14:44:32 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 May 2010 14:44:32 -0700 Subject: review (S) for 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK In-Reply-To: <811E37D7-8B98-4BEC-AC30-270EA4B9C935@oracle.com> References: <4BE84FA8.3000307@oracle.com> <7454DA69-D8CB-41D5-BCE9-AF025E25B2BF@oracle.com> <4BE86232.6070007@oracle.com> <3FA0D103-769B-4FBE-8AB1-0CDF81B4F0D8@oracle.com> <4BE86E43.5070503@oracle.com> <811E37D7-8B98-4BEC-AC30-270EA4B9C935@oracle.com> Message-ID: <4BE87E40.3030000@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > I've corrected all the copies and updated the webrev. > > tom > > On May 10, 2010, at 1:36 PM, Vladimir Kozlov wrote: > >> I agree to change them. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> Do you mind if I change them to TypeOopPtr::make_from_klass? I'd added an assert to confirm that they produce the same thing when I was testing this. >>> tom >>> On May 10, 2010, at 12:44 PM, Vladimir Kozlov wrote: >>>> It could be just historical. >>>> I looked on the original code and it starts with TypeOopPtr::make(TypePtr::BotPTR, klass, NULL, 0) in inline_string_compareTo(). >>>> Then it was changed to TypeInstPtr::make(), added false for xk. And later it was copy/past into other intrinsic methods. >>>> >>>> I agree that we can use TypeOopPtr::make(klass) here. >>>> >>>> Your changes with CheckCastPPNode are good. >>>> >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> I've updated it to just use a CheckCastPPNode as the checkcast logic would. Do you know why all the logic for building the String type passes false for klass_is_exact? >>>>> const TypeInstPtr* string_type = >>>>> TypeInstPtr::make(TypePtr::BotPTR, klass, false, NULL, 0); >>>>> TypeInstPtr::make corrects it to true for final classes but it just seems weird. gen_checkcast would simply use TypeOopPtr::make(klass) and let it take care of supplying the rest of the arguments. >>>>> tom >>>>> On May 10, 2010, at 11:58 AM, Tom Rodriguez wrote: >>>>>> That's still not right. I think my brain hasn't fully kicked in yet. I'll just go with a CheckCastPP as you've suggested. >>>>>> >>>>>> tom >>>>>> >>>>>> On May 10, 2010, at 11:51 AM, Tom Rodriguez wrote: >>>>>> >>>>>>> On May 10, 2010, at 11:25 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> No. It will not handle situation when statically we don't know if argument is NULL. >>>>>>>> And it will no work for NULL stopped() situation since 'failure' node will be NULL >>>>>>>> so merge region will not have valid paths. >>>>>>> You're right that I'm not handling the argument == null case properly. >>>>>>> >>>>>>>> Can we just use existing code and add CheckCastPPNode cast after gen_instanceof() ? >>>>>>> I was trying to get rid of the use of gen_instanceof since it generates quite a rats nest of tests that can require split_if to simplify. What about this: >>>>>>> >>>>>>> diff -r 359375cb7de6 src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp Fri May 07 15:13:00 2010 -0700 +++ b/src/share/vm/opto/library_call.cpp Mon May 10 11:50:19 2010 -0700 @@ -945,16 +945,12 @@ bool LibraryCallKit::inline_string_equal >>>>>>> ciInstanceKlass* klass = env()->String_klass(); if (!stopped()) { - Node* inst = gen_instanceof(argument, makecon(TypeKlassPtr::make(klass))); - Node* cmp = _gvn.transform(new (C, 3) CmpINode(inst, intcon(1))); - Node* bol = _gvn.transform(new (C, 2) BoolNode(cmp, BoolTest::ne)); - - Node* inst_false = generate_guard(bol, NULL, PROB_MIN); - //instanceOf == true, fallthrough >> - - if (inst_false != NULL) { - phi->init_req(3, intcon(0)); - region->init_req(3, inst_false); + Node* inst_false = NULL; + argument = gen_checkcast(argument, makecon(TypeKlassPtr::make(klass)), &inst_false); + phi->init_req(3, intcon(0 ) >> ); + region->init_req(3, inst_false ? inst_false : top()); + if (argument == null()) { + set_control(top()); } } >>>>>>> tom >>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> The !stopped() logic should handle that. >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>> On May 10, 2010, at 11:01 AM, Vladimir Kozlov wrote: >>>>>>>>> >>>>>>>>>> Tom, >>>>>>>>>> >>>>>>>>>> You need to add check for argument==null in inline_string_equal() after gen_checkcast() since it is false case. >>>>>>>>>> >>>>>>>>>> Vladimir >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> http://cr.openjdk.java.net/~never/6951190 >>>>>>>>> 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK >>>>>>>>> Reviewed-by: >>>>>>>>> This looks to be a long standing issue with the String.equals >>>>>>>>> intrinsic. The code checks that the argument is a String but it never >>>>>>>>> actually casts it to be a String. Later on when we're processing >>>>>>>>> types for the AddP for the String.count field we're looking for a >>>>>>>>> field at +20 in Object which of course doesn't exist so we hit that >>>>>>>>> assert. The fix is to perform a real checkcast which includes to >>>>>>>>> required cast to String. I also added an assert to check the contract >>>>>>>>> with gen_checkcast that it always returns non-null failure_control. >>>>>>>>> Tested by hand with failing JDK build. > From tom.rodriguez at oracle.com Mon May 10 18:24:17 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 11 May 2010 01:24:17 +0000 Subject: hg: jdk7/hotspot/hotspot: 6951190: assert(!klass_is_exact(), "only non-exact klass") while building JDK Message-ID: <20100511012419.F2DAB4420D@hg.openjdk.java.net> Changeset: e8e83be27dd7 Author: never Date: 2010-05-10 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e8e83be27dd7 6951190: assert(!klass_is_exact(),"only non-exact klass") while building JDK Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp From John.Coomes at oracle.com Tue May 11 15:39:06 2010 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 11 May 2010 15:39:06 -0700 Subject: review request (S/M): 6951319 enable Sun Studio 12 update 1 Message-ID: <19433.56458.364490.615128@oracle.com> I'd appreciate reviews for the changes to enable builds using Sun Studio 12 update 1 on solaris. The webrev includes some comments describing the various changes. http://cr.openjdk.java.net/~jcoomes/6951319-ss12u1/ -John From keith.mcguigan at oracle.com Tue May 11 18:17:26 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 11 May 2010 21:17:26 -0400 Subject: review request (S/M): 6951319 enable Sun Studio 12 update 1 In-Reply-To: <19433.56458.364490.615128@oracle.com> References: <19433.56458.364490.615128@oracle.com> Message-ID: <4BEA01A6.6090609@oracle.com> John Coomes wrote: > I'd appreciate reviews for the changes to enable builds using Sun > Studio 12 update 1 on solaris. The webrev includes some comments > describing the various changes. > > http://cr.openjdk.java.net/~jcoomes/6951319-ss12u1/ > > -John > Thumbs up from me. -- - Keith From daniel.daugherty at oracle.com Tue May 11 20:52:13 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 12 May 2010 03:52:13 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20100512035225.5F7CE4440C@hg.openjdk.java.net> Changeset: 96d554193f72 Author: coleenp Date: 2010-04-19 18:58 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/96d554193f72 6944822: Fix for 6938627 exposes problem with hard-coded buffer sizes Summary: Make tmpdir buffer sizes MAX_PATH+1 Reviewed-by: dholmes, coleenp Contributed-by: andreas.kohn at fredhopper.com ! src/os/linux/vm/attachListener_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp Changeset: 77261afdc5f2 Author: coleenp Date: 2010-05-04 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/77261afdc5f2 6935118: UseCompressedOops modification in methodOopDesc::sort_methods() causes JCK timeout Summary: Add comparison functions for compressed oops to use bubblesort. Reviewed-by: never, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/oops/methodOop.cpp + test/runtime/6925573/SortMethodsTest.java Changeset: f43b5e9f7881 Author: kamg Date: 2010-05-05 09:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f43b5e9f7881 6949118: jvm.dll shows the company name as Sun Microsystems Summary: Changed to "Oracle Corporation" Reviewed-by: coleenp, dcubed ! make/hotspot_distro Changeset: 3fca8e9cd36a Author: dcubed Date: 2010-05-05 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3fca8e9cd36a Merge ! src/os/linux/vm/os_linux.cpp Changeset: 4ad4e0ee3779 Author: dcubed Date: 2010-05-10 13:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4ad4e0ee3779 Merge Changeset: 2ad074ba8456 Author: dcubed Date: 2010-05-11 17:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2ad074ba8456 Merge From John.Coomes at oracle.com Tue May 11 23:43:04 2010 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 11 May 2010 23:43:04 -0700 Subject: review request (S/M): 6951319 enable Sun Studio 12 update 1 In-Reply-To: <4BEA01A6.6090609@oracle.com> References: <19433.56458.364490.615128@oracle.com> <4BEA01A6.6090609@oracle.com> Message-ID: <19434.19960.882791.995481@oracle.com> Keith McGuigan (keith.mcguigan at oracle.com) wrote: > John Coomes wrote: > > I'd appreciate reviews for the changes to enable builds using Sun > > Studio 12 update 1 on solaris. The webrev includes some comments > > describing the various changes. > > > > http://cr.openjdk.java.net/~jcoomes/6951319-ss12u1/ > > > > Thumbs up from me. Thanks! -John From David.Holmes at oracle.com Tue May 11 23:55:23 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 12 May 2010 16:55:23 +1000 Subject: review request (S/M): 6951319 enable Sun Studio 12 update 1 In-Reply-To: <19433.56458.364490.615128@oracle.com> References: <19433.56458.364490.615128@oracle.com> Message-ID: <4BEA50DB.4070002@oracle.com> John, First a dumb question :) Are the .il files only used with SunStudio? For the dtrace tail-call problem won't this: + // Work around dtrace tail call bug 6672627 until it is fixed in solaris 10. + #define HS_DTRACE_WORKAROUND_TAIL_CALL_BUG() \ + do { volatile size_t dtrace_workaround_tail_call_bug = 1; } while (0) be elided by any decent compiler - even though volatile it is a local and so the assignment is vacuous ? David John Coomes said the following on 05/12/10 08:39: > I'd appreciate reviews for the changes to enable builds using Sun > Studio 12 update 1 on solaris. The webrev includes some comments > describing the various changes. > > http://cr.openjdk.java.net/~jcoomes/6951319-ss12u1/ > > -John > From John.Coomes at oracle.com Wed May 12 00:49:57 2010 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 12 May 2010 00:49:57 -0700 Subject: review request (S/M): 6951319 enable Sun Studio 12 update 1 In-Reply-To: <4BEA50DB.4070002@oracle.com> References: <19433.56458.364490.615128@oracle.com> <4BEA50DB.4070002@oracle.com> Message-ID: <19434.23973.365281.748276@oracle.com> David Holmes (David.Holmes at oracle.com) wrote: > John, > > First a dumb question :) Are the .il files only used with SunStudio? Hi David, Not dumb, and the answer is yes. > For the dtrace tail-call problem won't this: > > + // Work around dtrace tail call bug 6672627 until it is fixed in > solaris 10. > + #define HS_DTRACE_WORKAROUND_TAIL_CALL_BUG() \ > + do { volatile size_t dtrace_workaround_tail_call_bug = 1; } while (0) > > be elided by any decent compiler - even though volatile it is a local > and so the assignment is vacuous ? Sun Studio 12 and 12u1 respect volatile enough to leave it alone (thankfully). FWIW, here's part of vmGCOperations.s from a product build; the 'mov $1,-12(%ebp)' corresponds to the HS_DTRACE_WORKAROUND_TAIL_CALL_BUG() on line 40: void VM_GC_Operation::notify_gc_end(): push %ebp ;/ line : 38 movl %esp,%ebp ;/ line : 38 push %ebx ;/ line : 38 subl $20,%esp ;/ line : 38 call .CG1.2806 ;/ line : 38 .CG1.2806: pop %ebx ;/ line : 38 addl $_GLOBAL_OFFSET_TABLE_+0x1,%ebx ;/ line : 38 call __dtrace_hotspot___gc__end at PLT ;/ line : 39 movl $1,-12(%ebp) ;/ line : 40 addl $20,%esp ;/ line : 40 pop %ebx ;/ line : 40 leave ;/ line : 40 ret ;/ line : 40 .size void VM_GC_Operation::notify_gc_end(), . - void VM_GC_Operation::notify_gc_end() -John > John Coomes said the following on 05/12/10 08:39: > > I'd appreciate reviews for the changes to enable builds using Sun > > Studio 12 update 1 on solaris. The webrev includes some comments > > describing the various changes. > > > > http://cr.openjdk.java.net/~jcoomes/6951319-ss12u1/ > > > > -John > > From Eric.Caspole at amd.com Wed May 12 10:10:33 2010 From: Eric.Caspole at amd.com (Eric Caspole) Date: Wed, 12 May 2010 10:10:33 -0700 Subject: Request Review: 6950075: nmethod sweeper should operate concurrently In-Reply-To: <1E2D21C5-FCF7-485C-90E8-4BA354A55A83@oracle.com> References: <4BE26702.3080804@oracle.com> <066E2B6A-529A-4137-AC13-E836A9137034@amd.com> <1E2D21C5-FCF7-485C-90E8-4BA354A55A83@oracle.com> Message-ID: <0890D664-3E3B-456C-B07D-D1E7429A0D29@amd.com> Hi Tom, I updated the comments in rev 11, let me know what you think. http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.11/webrev/ Thanks, Eric On May 7, 2010, at 11:23 AM, Tom Rodriguez wrote: > There's still some language in sweeper.cpp about running at a > safepoint. I know scan_stacks still does but the other parts > don't. In particular this comment: > > // long time we don't want to keep rescanning at every > safepoint. > > should lose the "at every safepoint" part. This needs updating: > > // Shut off compiler. Sweeper will run exiting from this safepoint > // and turn it back on if it clears enough space > > and this: > > if (UseCodeCacheFlushing) { > if (!CodeCache::needs_flushing()) { > // In a safepoint, no race with setters > _advise_to_sweep = 0; > } > > probably needs some sort of fix. > > Otherwise this looks good. > > tom > > On May 7, 2010, at 9:27 AM, Eric Caspole wrote: > >> Thanks Vladimir, see rev 10: >> >> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.10/ >> >> Eric >> >> >> On May 5, 2010, at 11:51 PM, Vladimir Kozlov wrote: >> >>> Eric, >>> >>> It looks good. Just minor notes. >>> >>> >>> Extend comment for your additional conditions: >>> >>> ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing >>> && !CompileBroker::should_compile_new_jobs())) { >>> >>> >>> Put first call javaTimeMillis under flag: >>> >>> + jlong sweep_start; >>> + if(PrintMethodFlushing) >>> + sweep_start = os::javaTimeMillis(); >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 5/5/10 6:03 PM, Eric Caspole wrote: >>>> In the current JVM, the nmethod sweeper runs during each safepoint, >>>> and may return early if there is no work to do. It periodically >>>> scans >>>> the thread stacks to determine if not-entrant nmethods have no >>>> lingering active stack frames and can be converted to zombies. It >>>> then walks the code cache promoting not-entrant nmethods to zombies >>>> if possible and deleting the zombies. It walks a fraction of the >>>> code >>>> cache in each turn, set by NmethodSweepFraction, which is 4 by >>>> default. When the whole code cache is traversed and no progress can >>>> be made, the sweeper will go idle until another nmethod becomes >>>> not- >>>> entrant, starting the process over again. >>>> >>>> In applications with a lot of compiled code, walking the code cache >>>> can take many milliseconds, contributing to long safepoint pause >>>> times, reducing application throughput. This change makes part >>>> of the >>>> sweeper work concurrent to reduce the safepoint pause time. >>>> >>>> In this webrev, the stack scans continue to happen at safepoint >>>> time >>>> but the code cache traversal is concurrent with the application. >>>> The >>>> traversal work runs on the compiler threads where they will >>>> check to >>>> sweep each time passing through the compile queue. They may take >>>> the >>>> code cache and stub related locks as necessary to do the sweeping >>>> safely. Only one thread will sweep at a time and it preserves the >>>> existing way of traversing in chunks by NmethodSweepFraction. >>>> >>>> There are a few adjustments to the checks regarding the code cache >>>> unloading feature to accommodate these changes. Also I added new >>>> convenience methods such as CodeCache::next_nmethod() for simple >>>> traversal. >>>> >>>> I worked out this design with Tom Rodriguez over the last month >>>> or so. >>>> We'd like some other eyes on it. >>>> >>>> The webrev is at >>>> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ >>>> >>>> Thanks, >>>> Eric >>>> >>>> >>> >> >> > > From keith.mcguigan at oracle.com Wed May 12 21:10:39 2010 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Thu, 13 May 2010 04:10:39 +0000 Subject: hg: hsx/hsx17/baseline: 6949118: jvm.dll shows the company name as Sun Microsystems Message-ID: <20100513041042.362D3445F1@hg.openjdk.java.net> Changeset: e3b128efead1 Author: kamg Date: 2010-05-05 09:28 -0400 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/e3b128efead1 6949118: jvm.dll shows the company name as Sun Microsystems Summary: Changed to "Oracle Corporation" Reviewed-by: coleenp, dcubed ! make/hotspot_distro From john.r.rose at oracle.com Thu May 13 02:40:45 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 13 May 2010 09:40:45 +0000 Subject: hg: jdk7/hotspot/hotspot: 13 new changesets Message-ID: <20100513094119.7F8294467C@hg.openjdk.java.net> Changeset: c640000b7cc1 Author: twisti Date: 2010-04-29 06:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c640000b7cc1 6829193: JSR 292 needs to support SPARC Summary: There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to SPARC. Reviewed-by: kvn, never, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: ae8f909e5fc7 Author: iveresov Date: 2010-04-29 17:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ae8f909e5fc7 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed Summary: Disable the use of pcmpestri until it can be guaranteed that the load doesn't cross in to the uncommited space. See 6942326. Reviewed-by: never, kvn ! src/share/vm/opto/library_call.cpp Changeset: 0c5b3cf3c1f5 Author: twisti Date: 2010-04-30 04:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0c5b3cf3c1f5 6939182: Zero JNI handles fix Summary: Zero will exit with an error when invoked with -Xcheck:jni. Reviewed-by: twisti, kamg Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp Changeset: 2338d41fbd81 Author: twisti Date: 2010-04-30 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2338d41fbd81 6943304: remove tagged stack interpreter Reviewed-by: coleenp, never, gbenson ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/interpreter_zero.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: cd5dbf694d45 Author: jrose Date: 2010-05-01 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cd5dbf694d45 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 2ffde6cfe049 Author: jrose Date: 2010-05-01 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2ffde6cfe049 6939196: method handle signatures off the boot class path get linkage errors Summary: Adjust MethodType lookup logic to search off the BCP, but not to cache those results Reviewed-by: twisti ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp Changeset: 68d6683eaef7 Author: twisti Date: 2010-05-04 02:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/68d6683eaef7 6949423: remove tagged stack interpreter for Zero Summary: Missed Zero changes for 6943304. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreter_zero.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: d6e880569997 Author: twisti Date: 2010-05-05 05:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d6e880569997 6949830: 6939134 broke Zero Summary: The commit for 6939134 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/methodHandles_zero.cpp Changeset: 348346af6676 Author: twisti Date: 2010-05-06 02:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/348346af6676 6950178: Zero stack improvements Summary: Moves the logic for determining the size of the Zero stack into the ZeroStack class. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/stack_zero.cpp ! src/cpu/zero/vm/stack_zero.hpp ! src/cpu/zero/vm/stack_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/share/vm/includeDB_zero Changeset: 6cfbdb113e52 Author: twisti Date: 2010-05-07 04:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/6cfbdb113e52 6950617: Zero/Shark interface updates Summary: Zero needs a couple of new methods to allow Shark to access the new frame anchor field. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.hpp ! src/cpu/zero/vm/javaFrameAnchor_zero.hpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.hpp Changeset: df736661d0c8 Author: jrose Date: 2010-05-11 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/df736661d0c8 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/signature.cpp Changeset: 22af4ce8dba1 Author: twisti Date: 2010-05-12 03:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/22af4ce8dba1 6951784: Zero deoptimizer changes Summary: The way Zero currently handles deoptimization can lead to methods being freed while they are still being executed. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/entry_zero.hpp Changeset: ef1a1d051971 Author: jrose Date: 2010-05-12 22:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ef1a1d051971 Merge ! src/share/vm/oops/methodOop.cpp From john.coomes at oracle.com Thu May 13 16:45:59 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 13 May 2010 23:45:59 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20100513234612.2571444773@hg.openjdk.java.net> Changeset: 3bfae429e2cf Author: ysr Date: 2010-05-03 10:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3bfae429e2cf 6948537: CMS: BOT walkers observe out-of-thin-air zeros on sun4v sparc/CMT Summary: On sun4v/CMT avoid use of memset() in BOT updates so as to prevent concurrent BOT readers from seeing the phantom zeros arising from memset()'s use of BIS. Reviewed-by: jmasa, johnc, minqi, poonam, tonyp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/globals.hpp Changeset: 7145628c2fa2 Author: tonyp Date: 2010-05-03 17:23 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7145628c2fa2 Merge Changeset: bb843ebc7c55 Author: ysr Date: 2010-05-03 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bb843ebc7c55 6919638: CMS: ExplicitGCInvokesConcurrent misinteracts with gc locker Summary: GC-locker induced concurrent full gc should be asynchronous; policy now controlled by a separate flag, which defaults to false. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: a8127dc669ba Author: ysr Date: 2010-05-10 12:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a8127dc669ba 6951188: CMS: move PromotionInfo into its own file Summary: Moved PromotionInfo and friends into new files promotionInfo.{h,c}pp from their previous compactibleFreeListSpace.{h,c}pp home. Reviewed-by: apetrusenko ! 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/concurrentMarkSweep/promotionInfo.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/promotionInfo.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep Changeset: 67d74f7a15d9 Author: jcoomes Date: 2010-05-12 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/67d74f7a15d9 6951923: some uses of fatal1 were missed by 6888954 Reviewed-by: jcoomes Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 8bfe9058ca46 Author: jcoomes Date: 2010-05-13 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8bfe9058ca46 Merge ! src/share/vm/runtime/globals.hpp From john.r.rose at oracle.com Thu May 13 20:02:14 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 14 May 2010 03:02:14 +0000 Subject: hg: jdk7/hotspot/jdk: 3 new changesets Message-ID: <20100514030310.8334B447B2@hg.openjdk.java.net> Changeset: 0cd764a1c809 Author: jrose Date: 2010-04-30 23:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0cd764a1c809 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: twisti ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/InvokeDynamicBootstrapError.java ! src/share/classes/java/dyn/JavaMethodHandle.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/NoAccessException.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/MemberName.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! test/java/dyn/MethodHandlesTest.java Changeset: 4a28a204b726 Author: jrose Date: 2010-05-03 23:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4a28a204b726 6939196: method handle signatures off the boot class path get linkage errors Summary: Remove workaround from MethodHandleImpl lookup code; add JUnit regression test to MethodHandlesTest. Reviewed-by: twisti ! src/share/classes/sun/dyn/MethodHandleImpl.java ! test/java/dyn/MethodHandlesTest.java Changeset: 3cf85945abef Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3cf85945abef Merge From john.r.rose at oracle.com Thu May 13 20:03:16 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 14 May 2010 03:03:16 +0000 Subject: hg: jdk7/hotspot/langtools: 2 new changesets Message-ID: <20100514030322.9C4AF447B3@hg.openjdk.java.net> Changeset: f0e3ec1f9d9f Author: jrose Date: 2010-05-01 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f0e3ec1f9d9f 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric Reviewed-by: twisti ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.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/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/meth/InvokeDyn.java ! test/tools/javac/meth/InvokeMH.java Changeset: 2a28dcbef3a7 Author: jrose Date: 2010-05-13 20:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/2a28dcbef3a7 Merge From erik.trimble at oracle.com Thu May 13 21:39:41 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 14 May 2010 04:39:41 +0000 Subject: hg: jdk7/hotspot/hotspot: 5 new changesets Message-ID: <20100514043951.95D2F447D9@hg.openjdk.java.net> Changeset: fb57d4cf76c2 Author: prr Date: 2010-05-11 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fb57d4cf76c2 6931180: Migration to recent versions of MS Platform SDK 6951582: Build problems on win64 Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/windows/build_vm_def.sh ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sanity.make ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/runtime/sharedRuntimeTrig.cpp Changeset: 9d865fc2f644 Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d865fc2f644 Merge Changeset: 2fb8834f4446 Author: trims Date: 2010-05-13 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2fb8834f4446 Merge Changeset: eefa1a6f1582 Author: trims Date: 2010-05-13 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eefa1a6f1582 6952178: Fork HS18 to HS19 - renumber Major and build numbers of JVM Summary: Update the Major and build numbers for HS19 fork Reviewed-by: jcoomes ! make/hotspot_version Changeset: 093432aa7573 Author: trims Date: 2010-05-13 17:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/093432aa7573 Merge From ahughes at redhat.com Fri May 14 07:21:00 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 14 May 2010 15:21:00 +0100 Subject: hs16 and hs17 differences Message-ID: I've noticed a difference between the hs16 and hs17 (b13) master trees: 6827605: new String intrinsics may prevent EA scalar replacement Summary: don't use SSE42 string indexOf intrinsic if it is called for new object which could be scalar replaced. Reviewed-by: never http://hg.openjdk.java.net/hsx/hsx16/master/rev/e502d7524e3a is only in hs16 but not hs17. Was this deliberate and is this fix no longer needed? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From vladimir.kozlov at oracle.com Fri May 14 08:57:32 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 14 May 2010 08:57:32 -0700 Subject: hs16 and hs17 differences In-Reply-To: References: Message-ID: <4BED72EC.6030201@oracle.com> HS17 has different (full) implementation of the fix (array pointer instead of object pointer is passed to intrinsics). The next changeset fixed it and an other bug: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62001a362ce9 6827605: new String intrinsics may prevent EA scalar replacement 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Vladimir Andrew John Hughes wrote: > I've noticed a difference between the hs16 and hs17 (b13) master trees: > > 6827605: new String intrinsics may prevent EA scalar replacement > Summary: don't use SSE42 string indexOf intrinsic if it is called for > new object which could be scalar replaced. > Reviewed-by: never > http://hg.openjdk.java.net/hsx/hsx16/master/rev/e502d7524e3a > > is only in hs16 but not hs17. Was this deliberate and is this fix no > longer needed? > From john.coomes at oracle.com Fri May 14 11:32:01 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:32:01 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20100514183201.E2373448F8@hg.openjdk.java.net> Changeset: aa4f995fb65e Author: prr Date: 2010-05-11 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/aa4f995fb65e 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! README-builds.html Changeset: 5fc102ff48f0 Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/5fc102ff48f0 Merge Changeset: ec423e5e725d Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ec423e5e725d Added tag jdk7-b93 for changeset 5fc102ff48f0 ! .hgtags From john.coomes at oracle.com Fri May 14 11:32:05 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:32:05 +0000 Subject: hg: jdk7/hotspot/corba: 3 new changesets Message-ID: <20100514183209.72C5F448F9@hg.openjdk.java.net> Changeset: ee2d8f1bef5b Author: prr Date: 2010-05-11 14:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/ee2d8f1bef5b 6931180: Migration to recent versions of MS Platform SDK Summary: Changes to enable building JDK7 with Microsoft Visual Studio 2010 Reviewed-by: ohair, art, ccheung, dcubed ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Platform.gmk Changeset: 9718d624864c Author: mikejwre Date: 2010-05-12 17:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/9718d624864c Merge Changeset: f2ff4938cecd Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/f2ff4938cecd Added tag jdk7-b93 for changeset 9718d624864c ! .hgtags From john.coomes at oracle.com Fri May 14 11:35:13 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:35:13 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b93 for changeset c725ca829c5a Message-ID: <20100514183513.6CCE2448FA@hg.openjdk.java.net> Changeset: 2de307cd3b4e Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/2de307cd3b4e Added tag jdk7-b93 for changeset c725ca829c5a ! .hgtags From john.coomes at oracle.com Fri May 14 11:35:16 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 14 May 2010 18:35:16 +0000 Subject: hg: jdk7/hotspot/jaxws: Added tag jdk7-b93 for changeset 797bef191975 Message-ID: <20100514183517.116FC448FB@hg.openjdk.java.net> Changeset: 8515e093efd1 Author: mikejwre Date: 2010-05-13 13:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/8515e093efd1 Added tag jdk7-b93 for changeset 797bef191975 ! .hgtags From ahughes at redhat.com Sun May 16 08:56:16 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Sun, 16 May 2010 16:56:16 +0100 Subject: hs16 and hs17 differences In-Reply-To: <4BED72EC.6030201@oracle.com> References: <4BED72EC.6030201@oracle.com> Message-ID: On 14 May 2010 16:57, Vladimir Kozlov wrote: > HS17 has different (full) implementation of the fix (array pointer instead > of object pointer is passed to intrinsics). > The next changeset fixed it and an other bug: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62001a362ce9 > > 6827605: new String intrinsics may prevent EA scalar replacement > 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 > > Vladimir > > Andrew John Hughes wrote: >> >> I've noticed a difference between the hs16 and hs17 (b13) master trees: >> >> 6827605: new String intrinsics may prevent EA scalar replacement >> Summary: don't use SSE42 string indexOf intrinsic if it is called for >> new object which could be scalar replaced. >> Reviewed-by: never >> http://hg.openjdk.java.net/hsx/hsx16/master/rev/e502d7524e3a >> >> is only in hs16 but not hs17. ?Was this deliberate and is this fix no >> longer needed? >> > Ok, both those are in the merged OpenJDK6 repository. In the hs17 master, there seems to be something odd going on. The version has been bumped to b14 (but not tagged) and this changeset has been added: http://hg.openjdk.java.net/hsx/hsx17/master/rev/9d9e74a1628e which changes this code again. Should we be include this fix? For now, I've only merged to the last tag (hs17-b13). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From vladimir.kozlov at oracle.com Sun May 16 10:17:26 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 16 May 2010 10:17:26 -0700 Subject: hs16 and hs17 differences In-Reply-To: References: <4BED72EC.6030201@oracle.com> Message-ID: <4BF028A6.6010306@oracle.com> > In the hs17 master, there seems to be something odd going on. The > version has been bumped to b14 (but not tagged) and this changeset has > been added: > > http://hg.openjdk.java.net/hsx/hsx17/master/rev/9d9e74a1628e > > which changes this code again. Should we be include this fix? For > now, I've only merged to the last tag (hs17-b13). Yes, it is an other bug 6948602 and you need this fix. Vladimir On 5/16/10 8:56 AM, Andrew John Hughes wrote: > On 14 May 2010 16:57, Vladimir Kozlov wrote: >> HS17 has different (full) implementation of the fix (array pointer instead >> of object pointer is passed to intrinsics). >> The next changeset fixed it and an other bug: >> >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/62001a362ce9 >> >> 6827605: new String intrinsics may prevent EA scalar replacement >> 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 >> >> Vladimir >> >> Andrew John Hughes wrote: >>> >>> I've noticed a difference between the hs16 and hs17 (b13) master trees: >>> >>> 6827605: new String intrinsics may prevent EA scalar replacement >>> Summary: don't use SSE42 string indexOf intrinsic if it is called for >>> new object which could be scalar replaced. >>> Reviewed-by: never >>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/e502d7524e3a >>> >>> is only in hs16 but not hs17. Was this deliberate and is this fix no >>> longer needed? >>> >> > > Ok, both those are in the merged OpenJDK6 repository. > > In the hs17 master, there seems to be something odd going on. The > version has been bumped to b14 (but not tagged) and this changeset has > been added: > > http://hg.openjdk.java.net/hsx/hsx17/master/rev/9d9e74a1628e > > which changes this code again. Should we be include this fix? For > now, I've only merged to the last tag (hs17-b13). From ahughes at redhat.com Mon May 17 01:22:43 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 17 May 2010 09:22:43 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF029BE.8010607@redhat.com> References: <4BF029BE.8010607@redhat.com> Message-ID: On 16 May 2010 18:22, Andrew Haley wrote: > On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >> The webrev is here: >> >> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >> >> I'd also like to revert: >> >> 6909480: Disable Escape Analysis in jdk 6u18 >> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >> >> which isn't present in hs17 (and so remains a difference between jdk6 >> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >> tree rather than the hs16 master. ?I didn't include this in the merge >> because it's clearer what's going on if it appears as a separate >> change. > > Ahh, good catch. > > Do we have any idea why escape analysis is disabled? > > Andrew. > I assume it wasn't stable enough in hs16, but the bug isn't visible. Can someone from the HotSpot team shed more light on this? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From erik.trimble at oracle.com Mon May 17 04:44:11 2010 From: erik.trimble at oracle.com (Erik Trimble) Date: Mon, 17 May 2010 04:44:11 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF029BE.8010607@redhat.com> Message-ID: <4BF12C0B.7030108@oracle.com> Andrew John Hughes wrote: > On 16 May 2010 18:22, Andrew Haley wrote: > >> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >> >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>> >>> I'd also like to revert: >>> >>> 6909480: Disable Escape Analysis in jdk 6u18 >>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>> >>> which isn't present in hs17 (and so remains a difference between jdk6 >>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>> tree rather than the hs16 master. I didn't include this in the merge >>> because it's clearer what's going on if it appears as a separate >>> change. >>> >> Ahh, good catch. >> >> Do we have any idea why escape analysis is disabled? >> >> Andrew. >> >> > > I assume it wasn't stable enough in hs16, but the bug isn't visible. > Can someone from the HotSpot team shed more light on this? > http://hg.openjdk.java.net/hsx/hsx17/master/rev/357d4e2eb4dd this changeset turns EA on. It was putback at hs17-b01, so it's never been enabled in HS16 or before. EA was on for all of HS17 testing, and we've been working on it, but it's /just/ not quite production-ready, and the decision was made to not spend the effort to try and fix it in HS17. We're hoping to get it fully fixed in the current HS. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From aph at redhat.com Mon May 17 04:51:08 2010 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 May 2010 12:51:08 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF12C0B.7030108@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF12C0B.7030108@oracle.com> Message-ID: <4BF12DAC.20207@redhat.com> On 05/17/2010 12:44 PM, Erik Trimble wrote: > Andrew John Hughes wrote: >> On 16 May 2010 18:22, Andrew Haley wrote: >> >>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>> >>>> The webrev is here: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>> >>>> I'd also like to revert: >>>> >>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>> >>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>> tree rather than the hs16 master. I didn't include this in the merge >>>> because it's clearer what's going on if it appears as a separate >>>> change. >>>> >>> Ahh, good catch. >>> >>> Do we have any idea why escape analysis is disabled? >> >> I assume it wasn't stable enough in hs16, but the bug isn't visible. >> Can someone from the HotSpot team shed more light on this? >> > http://hg.openjdk.java.net/hsx/hsx17/master/rev/357d4e2eb4dd > > this changeset turns EA on. It was putback at hs17-b01, so it's never > been enabled in HS16 or before. > > EA was on for all of HS17 testing, and we've been working on it, but > it's /just/ not quite production-ready, and the decision was made to not > spend the effort to try and fix it in HS17. We're hoping to get it fully > fixed in the current HS. One other thing: if I apply a patch to enable EA in an earlier HotSpot, will it probably work well enough for me to do some benchmarking? I'm interested to know how much EA will help, even though we can't ship it. Andrew. From vladimir.kozlov at oracle.com Mon May 17 09:29:22 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 09:29:22 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF029BE.8010607@redhat.com> Message-ID: <4BF16EE2.6040801@oracle.com> When we released jdk6u18 (hs16) there were 2 EA critical bugs for which we did not have time to fix in 6u18: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 In short, with escape analysis the generated code produces NULL(0) instead of expected (stored) values. There was no enough time for full testing in 6u18 and changes were too big. I would advice to not use EA with HS16. In hs17 we enabled EA again and tested it until 6u21 release in which the default flag's value is set to false but you can specify the flag on command line to enable EA. There are few problems which needs to be fixed before we enable EA by default. Andrew, you are right to not merge changes from hs16. And you can use the flag on command line for HS17 instead of patch to enable EA. It would be easier for benchmarking. Vladimir Andrew John Hughes wrote: > On 16 May 2010 18:22, Andrew Haley wrote: >> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>> The webrev is here: >>> >>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>> >>> I'd also like to revert: >>> >>> 6909480: Disable Escape Analysis in jdk 6u18 >>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>> >>> which isn't present in hs17 (and so remains a difference between jdk6 >>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>> tree rather than the hs16 master. I didn't include this in the merge >>> because it's clearer what's going on if it appears as a separate >>> change. >> Ahh, good catch. >> >> Do we have any idea why escape analysis is disabled? >> >> Andrew. >> > > I assume it wasn't stable enough in hs16, but the bug isn't visible. > Can someone from the HotSpot team shed more light on this? From ahughes at redhat.com Mon May 17 09:58:42 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 17 May 2010 17:58:42 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF12C0B.7030108@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF12C0B.7030108@oracle.com> Message-ID: On 17 May 2010 12:44, Erik Trimble wrote: > Andrew John Hughes wrote: >> >> On 16 May 2010 18:22, Andrew Haley wrote: >> >>> >>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>> >>>> >>>> The webrev is here: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>> >>>> I'd also like to revert: >>>> >>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>> >>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>> tree rather than the hs16 master. ?I didn't include this in the merge >>>> because it's clearer what's going on if it appears as a separate >>>> change. >>>> >>> >>> Ahh, good catch. >>> >>> Do we have any idea why escape analysis is disabled? >>> >>> Andrew. >>> >>> >> >> I assume it wasn't stable enough in hs16, but the bug isn't visible. >> Can someone from the HotSpot team shed more light on this? >> > > http://hg.openjdk.java.net/hsx/hsx17/master/rev/357d4e2eb4dd > > this changeset turns EA on. ?It was putback at hs17-b01, so it's never been > enabled in HS16 or before. > I didn't say it had, and I can see it's now false in c2_globals. I'm talking about an additional change which was added to the hs16 branch: if (DoEscapeAnalysis) { if (FLAG_IS_CMDLINE(DoEscapeAnalysis)) { warning("Escape Analysis is disabled in this release."); } FLAG_SET_DEFAULT(DoEscapeAnalysis, false); } which prevents -XX:+DoEscapeAnalysis being used to enable it. $ /home/andrew/build/icedtea6/bin/java -version java version "1.6.0_19" OpenJDK Runtime Environment (IcedTea6 1.9pre+r727bee274d9e) (Gentoo build 1.6.0_19-b19) OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) $ /home/andrew/build/icedtea6/bin/java -XX:+DoEscapeAnalysis HelloWorld OpenJDK 64-Bit Server VM warning: Escape Analysis is disabled in this release. Hello World! This is not present in hs17 so I think it should be removed from OpenJDK6 as part of the merge. AFAICS, hs17 does turn on EscapeAnalysis as part of aggressive optimisations: if (AggressiveOpts) { // Switch on optimizations with AggressiveOpts. if (FLAG_IS_DEFAULT(DoEscapeAnalysis)) { FLAG_SET_DEFAULT(DoEscapeAnalysis, true); } but turns it off when InvokeDynamic is used (hardly relevant for OpenJDK6) #ifdef COMPILER2 if (EnableInvokeDynamic && DoEscapeAnalysis) { // TODO: We need to find rules for invokedynamic and EA. For now, // simply disable EA by default. if (FLAG_IS_DEFAULT(DoEscapeAnalysis)) { DoEscapeAnalysis = false; } } #endif It also allows the user to turn it on, whereas if we leave the change from hs16 in OpenJDK6, that won't be possible in OpenJDK6: $ /mnt/builder/jdk6/bin/java -version openjdk version "1.6.0-internal" OpenJDK Runtime Environment (build 1.6.0-internal-andrew_17_may_2010_17_45-b00) OpenJDK 64-Bit Server VM (build 17.0-b13, mixed mode) $ /mnt/builder/jdk6/bin/java -XX:+DoEscapeAnalysis HelloWorld OpenJDK 64-Bit Server VM warning: Escape Analysis is disabled in this release. Hello World! Hence the request to reverse it and bring OpenJDK6's version closer to the hs17 tree. > EA was on for all of HS17 testing, and we've been working on it, but it's > /just/ not quite production-ready, and the decision was made to not spend > the effort to try and fix it in HS17. We're hoping to get it fully fixed in > the current HS. > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Mon May 17 10:02:33 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 17 May 2010 18:02:33 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF16EE2.6040801@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> Message-ID: On 17 May 2010 17:29, Vladimir Kozlov wrote: > When we released jdk6u18 (hs16) there were 2 EA critical bugs > for which we did not have time to fix in 6u18: > > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 > > In short, with escape analysis the generated code produces NULL(0) > instead of expected (stored) values. > > There was no enough time for full testing in 6u18 and changes were too big. > I would advice to not use EA with HS16. > > In hs17 we enabled EA again and tested it until 6u21 release in which > the default flag's value is set to false but you can specify the flag > on command line to enable EA. There are few problems which needs to be > fixed before we enable EA by default. > > Andrew, you are right to not merge changes from hs16. And you can use > the flag on command line for HS17 instead of patch to enable EA. > It would be easier for benchmarking. > Unfortunately it's not a matter of choosing not to merge the change, but having to revert it as it's already part of OpenJDK6 from the earlier hs16 merge (currently showing up as a difference between OpenJDK6's HotSpot and the hs17 branch). See the results and discussion in the mail I just posted. > Vladimir > > Andrew John Hughes wrote: >> >> On 16 May 2010 18:22, Andrew Haley wrote: >>> >>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>> >>>> The webrev is here: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>> >>>> I'd also like to revert: >>>> >>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>> >>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>> tree rather than the hs16 master. ?I didn't include this in the merge >>>> because it's clearer what's going on if it appears as a separate >>>> change. >>> >>> Ahh, good catch. >>> >>> Do we have any idea why escape analysis is disabled? >>> >>> Andrew. >>> >> >> I assume it wasn't stable enough in hs16, but the bug isn't visible. >> Can someone from the HotSpot team shed more light on this? > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From vladimir.kozlov at oracle.com Mon May 17 10:08:57 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 May 2010 10:08:57 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> Message-ID: <4BF17829.7040202@oracle.com> Andrew, yes, you should revert/remove the 6909480 changeset in OpenJDK6 after merge with hs17 Vladimir Andrew John Hughes wrote: > On 17 May 2010 17:29, Vladimir Kozlov wrote: >> When we released jdk6u18 (hs16) there were 2 EA critical bugs >> for which we did not have time to fix in 6u18: >> >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b >> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 >> >> In short, with escape analysis the generated code produces NULL(0) >> instead of expected (stored) values. >> >> There was no enough time for full testing in 6u18 and changes were too big. >> I would advice to not use EA with HS16. >> >> In hs17 we enabled EA again and tested it until 6u21 release in which >> the default flag's value is set to false but you can specify the flag >> on command line to enable EA. There are few problems which needs to be >> fixed before we enable EA by default. >> >> Andrew, you are right to not merge changes from hs16. And you can use >> the flag on command line for HS17 instead of patch to enable EA. >> It would be easier for benchmarking. >> > > Unfortunately it's not a matter of choosing not to merge the change, > but having to revert it as it's already part of OpenJDK6 from the > earlier hs16 merge (currently showing up as a difference between > OpenJDK6's HotSpot and the hs17 branch). See the results and > discussion in the mail I just posted. > >> Vladimir >> >> Andrew John Hughes wrote: >>> On 16 May 2010 18:22, Andrew Haley wrote: >>>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>>> The webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>>> >>>>> I'd also like to revert: >>>>> >>>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>>> >>>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>>> tree rather than the hs16 master. I didn't include this in the merge >>>>> because it's clearer what's going on if it appears as a separate >>>>> change. >>>> Ahh, good catch. >>>> >>>> Do we have any idea why escape analysis is disabled? >>>> >>>> Andrew. >>>> >>> I assume it wasn't stable enough in hs16, but the bug isn't visible. >>> Can someone from the HotSpot team shed more light on this? > > > From ahughes at redhat.com Mon May 17 11:48:15 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 17 May 2010 19:48:15 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF17829.7040202@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> Message-ID: On 17 May 2010 18:08, Vladimir Kozlov wrote: > Andrew, > > yes, you should revert/remove the 6909480 changeset in OpenJDK6 after merge > with hs17 > > Vladimir > > Andrew John Hughes wrote: >> >> On 17 May 2010 17:29, Vladimir Kozlov wrote: >>> >>> When we released jdk6u18 (hs16) there were 2 EA critical bugs >>> for which we did not have time to fix in 6u18: >>> >>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b >>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 >>> >>> In short, with escape analysis the generated code produces NULL(0) >>> instead of expected (stored) values. >>> >>> There was no enough time for full testing in 6u18 and changes were too >>> big. >>> I would advice to not use EA with HS16. >>> >>> In hs17 we enabled EA again and tested it until 6u21 release in which >>> the default flag's value is set to false but you can specify the flag >>> on command line to enable EA. There are few problems which needs to be >>> fixed before we enable EA by default. >>> >>> Andrew, you are right to not merge changes from hs16. And you can use >>> the flag on command line for HS17 instead of patch to enable EA. >>> It would be easier for benchmarking. >>> >> >> Unfortunately it's not a matter of choosing not to merge the change, >> but having to revert it as it's already part of OpenJDK6 from the >> earlier hs16 merge (currently showing up as a difference between >> OpenJDK6's HotSpot and the hs17 branch). ?See the results and >> discussion in the mail I just posted. >> >>> Vladimir >>> >>> Andrew John Hughes wrote: >>>> >>>> On 16 May 2010 18:22, Andrew Haley wrote: >>>>> >>>>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>>>> >>>>>> The webrev is here: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>>>> >>>>>> I'd also like to revert: >>>>>> >>>>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>>>> >>>>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>>>> tree rather than the hs16 master. ?I didn't include this in the merge >>>>>> because it's clearer what's going on if it appears as a separate >>>>>> change. >>>>> >>>>> Ahh, good catch. >>>>> >>>>> Do we have any idea why escape analysis is disabled? >>>>> >>>>> Andrew. >>>>> >>>> I assume it wasn't stable enough in hs16, but the bug isn't visible. >>>> Can someone from the HotSpot team shed more light on this? >> >> >> > Yeah :-) Just waiting for the go-ahead from Joe now... -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon May 17 12:54:33 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 17 May 2010 12:54:33 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> Message-ID: <4BF19EF9.60201@oracle.com> Andrew John Hughes wrote: > On 17 May 2010 18:08, Vladimir Kozlov wrote: > >> Andrew, >> >> yes, you should revert/remove the 6909480 changeset in OpenJDK6 after merge >> with hs17 >> >> Vladimir >> >> Andrew John Hughes wrote: >> >>> On 17 May 2010 17:29, Vladimir Kozlov wrote: >>> >>>> When we released jdk6u18 (hs16) there were 2 EA critical bugs >>>> for which we did not have time to fix in 6u18: >>>> >>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b >>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 >>>> >>>> In short, with escape analysis the generated code produces NULL(0) >>>> instead of expected (stored) values. >>>> >>>> There was no enough time for full testing in 6u18 and changes were too >>>> big. >>>> I would advice to not use EA with HS16. >>>> >>>> In hs17 we enabled EA again and tested it until 6u21 release in which >>>> the default flag's value is set to false but you can specify the flag >>>> on command line to enable EA. There are few problems which needs to be >>>> fixed before we enable EA by default. >>>> >>>> Andrew, you are right to not merge changes from hs16. And you can use >>>> the flag on command line for HS17 instead of patch to enable EA. >>>> It would be easier for benchmarking. >>>> >>>> >>> Unfortunately it's not a matter of choosing not to merge the change, >>> but having to revert it as it's already part of OpenJDK6 from the >>> earlier hs16 merge (currently showing up as a difference between >>> OpenJDK6's HotSpot and the hs17 branch). See the results and >>> discussion in the mail I just posted. >>> >>> >>>> Vladimir >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> On 16 May 2010 18:22, Andrew Haley wrote: >>>>> >>>>>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>>>> >>>>>>> The webrev is here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>>>>> >>>>>>> I'd also like to revert: >>>>>>> >>>>>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>>>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>>>>> >>>>>>> which isn't present in hs17 (and so remains a difference between jdk6 >>>>>>> and hs17) as, unlike jdk6's version, hs17 is based on the main HotSpot >>>>>>> tree rather than the hs16 master. I didn't include this in the merge >>>>>>> because it's clearer what's going on if it appears as a separate >>>>>>> change. >>>>>>> >>>>>> Ahh, good catch. >>>>>> >>>>>> Do we have any idea why escape analysis is disabled? >>>>>> >>>>>> Andrew. >>>>>> >>>>>> >>>>> I assume it wasn't stable enough in hs16, but the bug isn't visible. >>>>> Can someone from the HotSpot team shed more light on this? >>>>> >>> >>> > > Yeah :-) > > Just waiting for the go-ahead from Joe now... > Hello. I just finished looking over the lengthy patch. I approve the patch to update OpenJDK 6 to HS17 going back along with the subsequence reverting of 6909480. Thanks, -Joe From ahughes at redhat.com Mon May 17 14:14:18 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 17 May 2010 22:14:18 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF19EF9.60201@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> Message-ID: On 17 May 2010 20:54, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 17 May 2010 18:08, Vladimir Kozlov wrote: >> >>> >>> Andrew, >>> >>> yes, you should revert/remove the 6909480 changeset in OpenJDK6 after >>> merge >>> with hs17 >>> >>> Vladimir >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> On 17 May 2010 17:29, Vladimir Kozlov >>>> wrote: >>>> >>>>> >>>>> When we released jdk6u18 (hs16) there were 2 EA critical bugs >>>>> for which we did not have time to fix in 6u18: >>>>> >>>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b >>>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 >>>>> >>>>> In short, with escape analysis the generated code produces NULL(0) >>>>> instead of expected (stored) values. >>>>> >>>>> There was no enough time for full testing in 6u18 and changes were too >>>>> big. >>>>> I would advice to not use EA with HS16. >>>>> >>>>> In hs17 we enabled EA again and tested it until 6u21 release in which >>>>> the default flag's value is set to false but you can specify the flag >>>>> on command line to enable EA. There are few problems which needs to be >>>>> fixed before we enable EA by default. >>>>> >>>>> Andrew, you are right to not merge changes from hs16. And you can use >>>>> the flag on command line for HS17 instead of patch to enable EA. >>>>> It would be easier for benchmarking. >>>>> >>>>> >>>> >>>> Unfortunately it's not a matter of choosing not to merge the change, >>>> but having to revert it as it's already part of OpenJDK6 from the >>>> earlier hs16 merge (currently showing up as a difference between >>>> OpenJDK6's HotSpot and the hs17 branch). ?See the results and >>>> discussion in the mail I just posted. >>>> >>>> >>>>> >>>>> Vladimir >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> >>>>>> On 16 May 2010 18:22, Andrew Haley wrote: >>>>>> >>>>>>> >>>>>>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>>>>> >>>>>>>> >>>>>>>> The webrev is here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>>>>>> >>>>>>>> I'd also like to revert: >>>>>>>> >>>>>>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>>>>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>>>>>> >>>>>>>> which isn't present in hs17 (and so remains a difference between >>>>>>>> jdk6 >>>>>>>> and hs17) as, unlike jdk6's version, hs17 is based on the main >>>>>>>> HotSpot >>>>>>>> tree rather than the hs16 master. ?I didn't include this in the >>>>>>>> merge >>>>>>>> because it's clearer what's going on if it appears as a separate >>>>>>>> change. >>>>>>>> >>>>>>> >>>>>>> Ahh, good catch. >>>>>>> >>>>>>> Do we have any idea why escape analysis is disabled? >>>>>>> >>>>>>> Andrew. >>>>>>> >>>>>>> >>>>>> >>>>>> I assume it wasn't stable enough in hs16, but the bug isn't visible. >>>>>> Can someone from the HotSpot team shed more light on this? >>>>>> >>>> >>>> >> >> Yeah :-) >> >> Just waiting for the go-ahead from Joe now... >> > > Hello. > > I just finished looking over the lengthy patch. > > I approve the patch to update OpenJDK 6 to HS17 going back along with the > subsequence reverting of 6909480. > > Thanks, > > -Joe > I've pushed the merge. I guess I'll need a bug ID to push the reversion. Can you provide me with one? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon May 17 14:45:25 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 17 May 2010 14:45:25 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> Message-ID: <4BF1B8F5.4010802@oracle.com> Andrew John Hughes wrote: > On 17 May 2010 20:54, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 17 May 2010 18:08, Vladimir Kozlov wrote: >>> >>> >>>> Andrew, >>>> >>>> yes, you should revert/remove the 6909480 changeset in OpenJDK6 after >>>> merge >>>> with hs17 >>>> >>>> Vladimir >>>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> On 17 May 2010 17:29, Vladimir Kozlov >>>>> wrote: >>>>> >>>>> >>>>>> When we released jdk6u18 (hs16) there were 2 EA critical bugs >>>>>> for which we did not have time to fix in 6u18: >>>>>> >>>>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f96a1a986f7b >>>>>> http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7fee0a6cc6d4 >>>>>> >>>>>> In short, with escape analysis the generated code produces NULL(0) >>>>>> instead of expected (stored) values. >>>>>> >>>>>> There was no enough time for full testing in 6u18 and changes were too >>>>>> big. >>>>>> I would advice to not use EA with HS16. >>>>>> >>>>>> In hs17 we enabled EA again and tested it until 6u21 release in which >>>>>> the default flag's value is set to false but you can specify the flag >>>>>> on command line to enable EA. There are few problems which needs to be >>>>>> fixed before we enable EA by default. >>>>>> >>>>>> Andrew, you are right to not merge changes from hs16. And you can use >>>>>> the flag on command line for HS17 instead of patch to enable EA. >>>>>> It would be easier for benchmarking. >>>>>> >>>>>> >>>>>> >>>>> Unfortunately it's not a matter of choosing not to merge the change, >>>>> but having to revert it as it's already part of OpenJDK6 from the >>>>> earlier hs16 merge (currently showing up as a difference between >>>>> OpenJDK6's HotSpot and the hs17 branch). See the results and >>>>> discussion in the mail I just posted. >>>>> >>>>> >>>>> >>>>>> Vladimir >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> On 16 May 2010 18:22, Andrew Haley wrote: >>>>>>> >>>>>>> >>>>>>>> On 05/16/2010 05:14 PM, Andrew John Hughes wrote: >>>>>>>> >>>>>>>> >>>>>>>>> The webrev is here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/jdk6-hs17-merge/ >>>>>>>>> >>>>>>>>> I'd also like to revert: >>>>>>>>> >>>>>>>>> 6909480: Disable Escape Analysis in jdk 6u18 >>>>>>>>> http://hg.openjdk.java.net/hsx/hsx16/master/rev/4ebd3f8407eb >>>>>>>>> >>>>>>>>> which isn't present in hs17 (and so remains a difference between >>>>>>>>> jdk6 >>>>>>>>> and hs17) as, unlike jdk6's version, hs17 is based on the main >>>>>>>>> HotSpot >>>>>>>>> tree rather than the hs16 master. I didn't include this in the >>>>>>>>> merge >>>>>>>>> because it's clearer what's going on if it appears as a separate >>>>>>>>> change. >>>>>>>>> >>>>>>>>> >>>>>>>> Ahh, good catch. >>>>>>>> >>>>>>>> Do we have any idea why escape analysis is disabled? >>>>>>>> >>>>>>>> Andrew. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I assume it wasn't stable enough in hs16, but the bug isn't visible. >>>>>>> Can someone from the HotSpot team shed more light on this? >>>>>>> >>>>>>> >>>>> >>> Yeah :-) >>> >>> Just waiting for the go-ahead from Joe now... >>> >>> >> Hello. >> >> I just finished looking over the lengthy patch. >> >> I approve the patch to update OpenJDK 6 to HS17 going back along with the >> subsequence reverting of 6909480. >> >> Thanks, >> >> -Joe >> >> > > I've pushed the merge. I guess I'll need a bug ID to push the > reversion. Can you provide me with one? > > 6953222 Revert change for 6909480 in OpenJDK 6 Cheers, -Joe From erik.trimble at oracle.com Mon May 17 14:57:25 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Mon, 17 May 2010 21:57:25 +0000 Subject: hg: hsx/hsx17/master: Added tag hs17-b14 for changeset 9d9e74a1628e Message-ID: <20100517215727.6CAFC44ED5@hg.openjdk.java.net> Changeset: e776591addb0 Author: trims Date: 2010-05-17 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/e776591addb0 Added tag hs17-b14 for changeset 9d9e74a1628e ! .hgtags From erik.trimble at oracle.com Mon May 17 15:03:37 2010 From: erik.trimble at oracle.com (Erik Trimble) Date: Mon, 17 May 2010 15:03:37 -0700 Subject: HotSpot 17 merge In-Reply-To: <4BF1B8F5.4010802@oracle.com> References: <4BF029BE.8010607@redhat.com> <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> <4BF1B8F5.4010802@oracle.com> Message-ID: <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> Back on another note in this thread: hs17-b14 was completed awhile ago (May 4th or so), and I just forgot to push the Hg tag for it onto the hsx17/[baseline,master] repos. I'm doing so now. Andrew - you can take this change: 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 is fixed and merge it into OpenJDK6. It's the only changeset for hs17-b14. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From erik.trimble at oracle.com Mon May 17 15:13:35 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Mon, 17 May 2010 22:13:35 +0000 Subject: hg: hsx/hsx17/baseline: 2 new changesets Message-ID: <20100517221338.CA2E444EDC@hg.openjdk.java.net> Changeset: e776591addb0 Author: trims Date: 2010-05-17 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/e776591addb0 Added tag hs17-b14 for changeset 9d9e74a1628e ! .hgtags Changeset: 6a47e8c8eccf Author: trims Date: 2010-05-17 15:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/6a47e8c8eccf Merge From daniel.daugherty at oracle.com Tue May 18 05:39:54 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 18 May 2010 12:39:54 +0000 Subject: hg: hsx/hsx17/baseline: 3 new changesets Message-ID: <20100518124004.3A15D44FCF@hg.openjdk.java.net> Changeset: d3562366cbfd Author: dcubed Date: 2010-05-17 06:35 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/d3562366cbfd 6949515: 3/3 VM crash when calling GetMethodDeclaringClass Summary: Use resolve_external_guard() instead of resolve_non_null(). Reviewed-by: thurka, kamg, acorn ! src/share/vm/runtime/jniHandles.hpp Changeset: 2b971d302bbe Author: dcubed Date: 2010-05-17 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/2b971d302bbe Merge ! src/share/vm/runtime/jniHandles.hpp Changeset: 8bc86dd08b8a Author: dcubed Date: 2010-05-17 19:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/8bc86dd08b8a Merge From tom.rodriguez at oracle.com Tue May 18 12:49:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 18 May 2010 12:49:27 -0700 Subject: Fwd: Request Review: 6950075: nmethod sweeper should operate concurrently References: Message-ID: For some reason this bounced earlier. tom Begin forwarded message: > From: Tom Rodriguez > Date: May 18, 2010 11:16:26 AM PDT > To: Eric Caspole > Cc: "hotspot-dev at openjdk.java.net Developers" > Subject: Re: Request Review: 6950075: nmethod sweeper should operate concurrently > > I pushed these changes last night. Thanks! > > tom > > On May 12, 2010, at 10:10 AM, Eric Caspole wrote: > >> Hi Tom, >> I updated the comments in rev 11, let me know what you think. >> >> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.11/webrev/ >> >> Thanks, >> Eric >> >> >> On May 7, 2010, at 11:23 AM, Tom Rodriguez wrote: >> >>> There's still some language in sweeper.cpp about running at a safepoint. I know scan_stacks still does but the other parts don't. In particular this comment: >>> >>> // long time we don't want to keep rescanning at every safepoint. >>> >>> should lose the "at every safepoint" part. This needs updating: >>> >>> // Shut off compiler. Sweeper will run exiting from this safepoint >>> // and turn it back on if it clears enough space >>> >>> and this: >>> >>> if (UseCodeCacheFlushing) { >>> if (!CodeCache::needs_flushing()) { >>> // In a safepoint, no race with setters >>> _advise_to_sweep = 0; >>> } >>> >>> probably needs some sort of fix. >>> >>> Otherwise this looks good. >>> >>> tom >>> >>> On May 7, 2010, at 9:27 AM, Eric Caspole wrote: >>> >>>> Thanks Vladimir, see rev 10: >>>> >>>> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.10/ >>>> >>>> Eric >>>> >>>> >>>> On May 5, 2010, at 11:51 PM, Vladimir Kozlov wrote: >>>> >>>>> Eric, >>>>> >>>>> It looks good. Just minor notes. >>>>> >>>>> >>>>> Extend comment for your additional conditions: >>>>> >>>>> ! if ((_current == NULL && !_rescan) && !(UseCodeCacheFlushing && !CompileBroker::should_compile_new_jobs())) { >>>>> >>>>> >>>>> Put first call javaTimeMillis under flag: >>>>> >>>>> + jlong sweep_start; >>>>> + if(PrintMethodFlushing) >>>>> + sweep_start = os::javaTimeMillis(); >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 5/5/10 6:03 PM, Eric Caspole wrote: >>>>>> In the current JVM, the nmethod sweeper runs during each safepoint, >>>>>> and may return early if there is no work to do. It periodically scans >>>>>> the thread stacks to determine if not-entrant nmethods have no >>>>>> lingering active stack frames and can be converted to zombies. It >>>>>> then walks the code cache promoting not-entrant nmethods to zombies >>>>>> if possible and deleting the zombies. It walks a fraction of the code >>>>>> cache in each turn, set by NmethodSweepFraction, which is 4 by >>>>>> default. When the whole code cache is traversed and no progress can >>>>>> be made, the sweeper will go idle until another nmethod becomes not- >>>>>> entrant, starting the process over again. >>>>>> >>>>>> In applications with a lot of compiled code, walking the code cache >>>>>> can take many milliseconds, contributing to long safepoint pause >>>>>> times, reducing application throughput. This change makes part of the >>>>>> sweeper work concurrent to reduce the safepoint pause time. >>>>>> >>>>>> In this webrev, the stack scans continue to happen at safepoint time >>>>>> but the code cache traversal is concurrent with the application. The >>>>>> traversal work runs on the compiler threads where they will check to >>>>>> sweep each time passing through the compile queue. They may take the >>>>>> code cache and stub related locks as necessary to do the sweeping >>>>>> safely. Only one thread will sweep at a time and it preserves the >>>>>> existing way of traversing in chunks by NmethodSweepFraction. >>>>>> >>>>>> There are a few adjustments to the checks regarding the code cache >>>>>> unloading feature to accommodate these changes. Also I added new >>>>>> convenience methods such as CodeCache::next_nmethod() for simple >>>>>> traversal. >>>>>> >>>>>> I worked out this design with Tom Rodriguez over the last month or so. >>>>>> We'd like some other eyes on it. >>>>>> >>>>>> The webrev is at >>>>>> http://cr.openjdk.java.net/~ecaspole/concswpr/webrev.09/webrev/ >>>>>> >>>>>> Thanks, >>>>>> Eric >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > From ahughes at redhat.com Tue May 18 12:50:33 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 18 May 2010 20:50:33 +0100 Subject: HotSpot 17 merge In-Reply-To: <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> References: <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> <4BF1B8F5.4010802@oracle.com> <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> Message-ID: On 17 May 2010 23:03, Erik Trimble wrote: > Back on another note in this thread: > > hs17-b14 was completed awhile ago (May 4th or so), and I just forgot to > push the Hg tag for it onto the hsx17/[baseline,master] repos. I'm doing > so now. > > Andrew - you can take this change: > > 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 > is fixed > > and merge it into OpenJDK6. ?It's the only changeset for hs17-b14. > Thanks Erik. I'll do so if Joe approves. > > > -- > Erik Trimble > Java System Support > Mailstop: ?usca22-123 > Phone: ?x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Tue May 18 14:13:16 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 18 May 2010 14:13:16 -0700 Subject: HotSpot 17 merge In-Reply-To: References: <4BF16EE2.6040801@oracle.com> <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> <4BF1B8F5.4010802@oracle.com> <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> Message-ID: <4BF302EC.60609@oracle.com> Andrew John Hughes wrote: > On 17 May 2010 23:03, Erik Trimble wrote: > >> Back on another note in this thread: >> >> hs17-b14 was completed awhile ago (May 4th or so), and I just forgot to >> push the Hg tag for it onto the hsx17/[baseline,master] repos. I'm doing >> so now. >> >> Andrew - you can take this change: >> >> 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 >> is fixed >> >> and merge it into OpenJDK6. It's the only changeset for hs17-b14. >> >> > > Thanks Erik. I'll do so if Joe approves. > > > So approved! Thanks, -Joe From ahughes at redhat.com Tue May 18 14:41:01 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 18 May 2010 22:41:01 +0100 Subject: HotSpot 17 merge In-Reply-To: <4BF302EC.60609@oracle.com> References: <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> <4BF1B8F5.4010802@oracle.com> <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> <4BF302EC.60609@oracle.com> Message-ID: On 18 May 2010 22:13, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 17 May 2010 23:03, Erik Trimble wrote: >> >>> >>> Back on another note in this thread: >>> >>> hs17-b14 was completed awhile ago (May 4th or so), and I just forgot to >>> push the Hg tag for it onto the hsx17/[baseline,master] repos. I'm doing >>> so now. >>> >>> Andrew - you can take this change: >>> >>> 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 >>> is fixed >>> >>> and merge it into OpenJDK6. ?It's the only changeset for hs17-b14. >>> >>> >> >> Thanks Erik. ?I'll do so if Joe approves. >> >> >> > > So approved! > > Thanks, > > -Joe > > So pushed! Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Wed May 19 08:54:35 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 19 May 2010 16:54:35 +0100 Subject: HotSpot 17 merge In-Reply-To: References: <4BF17829.7040202@oracle.com> <4BF19EF9.60201@oracle.com> <4BF1B8F5.4010802@oracle.com> <1274133818.14197.3.camel@ghostbox.sfbay.sun.com> <4BF302EC.60609@oracle.com> Message-ID: On 18 May 2010 22:41, Andrew John Hughes wrote: > On 18 May 2010 22:13, Joe Darcy wrote: >> Andrew John Hughes wrote: >>> >>> On 17 May 2010 23:03, Erik Trimble wrote: >>> >>>> >>>> Back on another note in this thread: >>>> >>>> hs17-b14 was completed awhile ago (May 4th or so), and I just forgot to >>>> push the Hg tag for it onto the hsx17/[baseline,master] repos. I'm doing >>>> so now. >>>> >>>> Andrew - you can take this change: >>>> >>>> 6948602: Disable use of SSE4.2 in String.indexOf intrinsic until 6942326 >>>> is fixed >>>> >>>> and merge it into OpenJDK6. ?It's the only changeset for hs17-b14. >>>> >>>> >>> >>> Thanks Erik. ?I'll do so if Joe approves. >>> >>> >>> >> >> So approved! >> >> Thanks, >> >> -Joe >> >> > > So pushed! > > Thanks, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > That's me done for b20 btw, assuming you still want the small copyright-change release we originally spoke about. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From jeff at cooljeff.co.uk Wed May 19 09:29:32 2010 From: jeff at cooljeff.co.uk (Jeffrey Sinclair) Date: Wed, 19 May 2010 17:29:32 +0100 Subject: Ensuring short lived objects remain short lived Message-ID: <1274286572.5367.33.camel@Lini> hotspot-dev, Many of the Java server side applications I see involve message pipelines. In an ideal world all of the transient objects involved in processing the message would remain in the young generation to be collected efficiently. Quite often what I see is that some of these transient objects either survive too long (and hence promoted to tenured) for longer message pipelines and others survive when the system is under load because they are promoted straight to the tenured generation. Something I've always been curious about is optimizing the young generation to prevent these use-cases arising. The only mechanism I'm aware of is to use jmap -heap to monitor young/tenured as messages flow and then alter the maxnewsize until you get something that kind of works. However I'd like to have something more quantitative that can be used to scale correctly. For example it would be good for me to be able to say that for this message execution flow, XMb is used per message and here is a breakdown of the objects used. Is there any built-in mechanism or methodology that would allow me to determine more quantitatively that my short lived objects are being regarded as short-lived and not being promoted? Jeffrey Sinclair From daniel.daugherty at oracle.com Wed May 19 11:12:08 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 19 May 2010 18:12:08 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20100519181216.93524442D9@hg.openjdk.java.net> Changeset: 9d4dd91c4a0a Author: poonam Date: 2010-05-15 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d4dd91c4a0a 6745217: jmap assertion failure Summary: SA shows exception with core files > 2GB. These changes fix that by correcting the size of CMSBitmap during its allocation. Reviewed-by: swamyv ! agent/src/share/classes/sun/jvm/hotspot/memory/CMSBitMap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java Changeset: 7ccc203eb6ff Author: dcubed Date: 2010-05-17 03:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7ccc203eb6ff Merge Changeset: d3562366cbfd Author: dcubed Date: 2010-05-17 06:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d3562366cbfd 6949515: 3/3 VM crash when calling GetMethodDeclaringClass Summary: Use resolve_external_guard() instead of resolve_non_null(). Reviewed-by: thurka, kamg, acorn ! src/share/vm/runtime/jniHandles.hpp Changeset: 892898e961c5 Author: dcubed Date: 2010-05-17 07:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/892898e961c5 Merge ! src/share/vm/runtime/jniHandles.hpp From john.r.rose at oracle.com Thu May 20 05:39:45 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 20 May 2010 12:39:45 +0000 Subject: hg: jdk7/hotspot/hotspot: 8 new changesets Message-ID: <20100520124004.9209144390@hg.openjdk.java.net> Changeset: 79bf863697eb Author: kvn Date: 2010-05-17 11:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/79bf863697eb 6951686: Using large pages on Linux prevents zero based compressed oops Summary: Use req_addr when attaching shared memory segment. Reviewed-by: twisti ! src/os/linux/vm/os_linux.cpp Changeset: bfe29ec02863 Author: never Date: 2010-05-17 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bfe29ec02863 6950075: nmethod sweeper should operate concurrently Reviewed-by: never, kvn Contributed-by: eric.caspole at amd.com ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp Changeset: c52275c698d1 Author: kvn Date: 2010-05-18 09:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c52275c698d1 6953267: assert in EA code with -XX:+StressReflectiveCode Summary: Add missing checks into EA code. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 99791ad65936 Author: never Date: 2010-05-18 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/99791ad65936 6953539: after 6892658 c1 reports that it doesn't inline StringBuffer.append Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: b5fdf39b9749 Author: never Date: 2010-05-18 23:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b5fdf39b9749 6953576: bottom_type for matched AddPNodes doesn't always agree with ideal Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/addnode.hpp Changeset: eb79484f795f Author: kvn Date: 2010-04-05 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/eb79484f795f 6937111: Restore optimization for Phi of AddP (6552204) Summary: Restored the original code which was removed by the fix for 6614100. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 1a1603f975b5 Author: kvn Date: 2010-05-19 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1a1603f975b5 Merge ! src/share/vm/opto/cfgnode.cpp Changeset: 1a88d3c58e1d Author: jrose Date: 2010-05-20 01:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1a88d3c58e1d Merge ! src/share/vm/runtime/globals.hpp From dmdabbs at gmail.com Fri May 21 11:27:25 2010 From: dmdabbs at gmail.com (David Dabbs) Date: Fri, 21 May 2010 13:27:25 -0500 Subject: OptimizeStringConcat option In-Reply-To: <1274286572.5367.33.camel@Lini> References: <1274286572.5367.33.camel@Lini> Message-ID: <00a801caf913$44ae7820$ce0b6860$@com> Hello. I see that a bug related to OptimizeStringConcat will land in 6u21 and I guess is also in jdk7-94 (or earlier). >From what I can tell OptimizeStringConcat is now product, but disabled by default. What behavior does it enable? Is this related to issue "C2 should optimize some stringbuilder patterns?" If not, does a separate option enable/disable that optimization? Other questions: Does the closing of the SSE4.2 intrinsics issue mean that they are re-enabled? Release 6u14? introduced some options that I think have been in and out. Specifically, -XX:+DoEscapeAnalysis -XX:+UseCompressedOops -XX:+UseG1GC TreeMap Iteration Improvement (via -XX:+AggressiveOpts) At this point is the options.cpp (sic) the most accurate source for all options, product or otherwise, and their defaults? Thank you, David Dabbs From tom.rodriguez at oracle.com Fri May 21 11:35:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 May 2010 11:35:22 -0700 Subject: review (XS) for 6490487: java support on 64 bit solaris x86 machines is broken. Message-ID: http://cr.openjdk.java.net/~never/6490487/ 6490487: java support on 64 bit solaris x86 machines is broken. Reviewed-by: This is a small annoying bug that should have been fixed long ago. For some reason the 64 bit libjvm_db.so for talking to 32 bit processes is only exported on sparc which means that 64 bit pstack can't decode stacks in 32 bit processes. The fix is simply to always export them. Tested with pstack and JPRT build. make/solaris/makefiles/defs.make From keith.mcguigan at oracle.com Fri May 21 12:51:15 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 21 May 2010 15:51:15 -0400 Subject: review (XS) for 6490487: java support on 64 bit solaris x86 machines is broken. In-Reply-To: References: Message-ID: <4BF6E433.2040303@oracle.com> Tom Rodriguez wrote: > resending because of earlier mail problems. > > http://cr.openjdk.java.net/~never/6490487/ > > 6490487: java support on 64 bit solaris x86 machines is broken. > Reviewed-by: > > This is a small annoying bug that should have been fixed long ago. > For some reason the 64 bit libjvm_db.so for talking to 32 bit > processes is only exported on sparc which means that 64 bit pstack > can't decode stacks in 32 bit processes. The fix is simply to always > export them. Tested with pstack and JPRT build. > > make/solaris/makefiles/defs.make Looks good! -- - Keith From vladimir.kozlov at oracle.com Fri May 21 13:33:38 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 May 2010 13:33:38 -0700 Subject: review (XS) for 6490487: java support on 64 bit solaris x86 machines is broken. In-Reply-To: References: Message-ID: <4BF6EE22.9040501@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > resending because of earlier mail problems. > > http://cr.openjdk.java.net/~never/6490487/ > > 6490487: java support on 64 bit solaris x86 machines is broken. > Reviewed-by: > > This is a small annoying bug that should have been fixed long ago. > For some reason the 64 bit libjvm_db.so for talking to 32 bit > processes is only exported on sparc which means that 64 bit pstack > can't decode stacks in 32 bit processes. The fix is simply to always > export them. Tested with pstack and JPRT build. > > make/solaris/makefiles/defs.make From daniel.daugherty at oracle.com Fri May 21 13:11:03 2010 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 May 2010 14:11:03 -0600 Subject: JVM crashes when adding more than 2 methods to java.lang.Object In-Reply-To: References: Message-ID: <4BF6E8D7.30707@oracle.com> Sorry that I'm really late to this e-mail thread. We don't support using the RedefineClasses() API to add a public method. This testing assertion is verified by an internal test (redefclass020) and I just verified that the test does pass. In Guillaume's scenarios, the Object.class bits are being replaced at ClassFileLoadHook time or by providing the modified Object class using the -Xbootclasspath/p parameter. (That info was provided in another e-mail.) In neither of those cases is the RedefineClasses() API being called so the error check I mention above isn't being made. It more be worth adding a sanity check of some sort to the early bring up/boot strapping logic to verify that the Object class that we're about to load has the expected number of virtual methods. This will allow us to get a cleaner error message for now. Dan On 4/28/2010 12:09 PM, Tom Rodriguez wrote: > I didn't think we supporting redefining Object and adding public methods after JVM bootstrap. Adding methods to classes which are already loaded with subclasses means that you have to generate new vtables for all subclasses and as far as I know we don't do that. You might get more answer over on serviceability-dev. > > tom > > On Apr 24, 2010, at 1:30 PM, Guillaume Pothier wrote: > > >> Hi, >> First of all I hope it is appropriate to ask this kind of question in >> this list, otherwise what would be the correct forum? >> Here is my problem: I'm adding public, non-native methods to the >> Object class through instrumentation, and it seems that adding more >> than 2 such methods causes the JVM to crash. I get different kinds of >> crashes depending on the number of methods I add. With 3 and 4 methods >> I get a SIGSEGV; with more methods I get an NPE during VM >> initialization (in String.charAt). For testing purposes, all added >> methods take no arguments and return void, and have an empty body >> (only the RETURN bytecode). >> Is that expected behavior? Is there something I can do about it? >> Kind regards, >> Guillaume Pothier >> PhD student, University of Chile >> > > > From tom.rodriguez at oracle.com Fri May 21 16:15:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 21 May 2010 16:15:18 -0700 Subject: JVM crashes when adding more than 2 methods to java.lang.Object In-Reply-To: <4BF6E8D7.30707@oracle.com> References: <4BF6E8D7.30707@oracle.com> Message-ID: <0F1066F2-3FCE-40A9-9785-6E8E9509D21B@oracle.com> On May 21, 2010, at 1:11 PM, Daniel D. Daugherty wrote: > Sorry that I'm really late to this e-mail thread. We don't support > using the RedefineClasses() API to add a public method. This testing > assertion is verified by an internal test (redefclass020) and I just > verified that the test does pass. > > In Guillaume's scenarios, the Object.class bits are being replaced at > ClassFileLoadHook time or by providing the modified Object class using > the -Xbootclasspath/p parameter. (That info was provided in another > e-mail.) In neither of those cases is the RedefineClasses() API being > called so the error check I mention above isn't being made. > > It more be worth adding a sanity check of some sort to the early > bring up/boot strapping logic to verify that the Object class that > we're about to load has the expected number of virtual methods. This > will allow us to get a cleaner error message for now. There are existing asserts and I think they should just be converted to exceptions. We could also consider making the base table size into a flag so it could be increased. tom > > Dan > > > On 4/28/2010 12:09 PM, Tom Rodriguez wrote: >> I didn't think we supporting redefining Object and adding public methods after JVM bootstrap. Adding methods to classes which are already loaded with subclasses means that you have to generate new vtables for all subclasses and as far as I know we don't do that. You might get more answer over on serviceability-dev. >> >> tom >> >> On Apr 24, 2010, at 1:30 PM, Guillaume Pothier wrote: >> >> >>> Hi, >>> First of all I hope it is appropriate to ask this kind of question in >>> this list, otherwise what would be the correct forum? >>> Here is my problem: I'm adding public, non-native methods to the >>> Object class through instrumentation, and it seems that adding more >>> than 2 such methods causes the JVM to crash. I get different kinds of >>> crashes depending on the number of methods I add. With 3 and 4 methods >>> I get a SIGSEGV; with more methods I get an NPE during VM >>> initialization (in String.charAt). For testing purposes, all added >>> methods take no arguments and return void, and have an empty body >>> (only the RETURN bytecode). >>> Is that expected behavior? Is there something I can do about it? >>> Kind regards, >>> Guillaume Pothier >>> PhD student, University of Chile >>> >> >> >> > From xerxes at zafena.se Mon May 24 05:55:02 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 24 May 2010 14:55:02 +0200 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. Message-ID: <4BFA7726.1030506@zafena.se> Hi Im hoping to find someone who can enlighten me how to resolve a bug where some hotspot JITs fails the hotspot/test/compiler/6539464 jtreg regression test. The testcase looks like: public class Test { static double log_value = 17197; static double log_result = Math.log(log_value); public static void main(String[] args) throws Exception { for (int i = 0; i < 1000000; i++) { double log_result2 = Math.log(log_value); if (log_result2 != log_result) { throw new InternalError("Math.log produces inconsistent results: " + log_result2 + " != " + log_result); } } } } When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs: StrictMath.log(17197) = 9.75249022898412 And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha: http://www.wolframalpha.com/input/?i=log%2817197%29 log(17197) = 9.7524902289841994797298917760120602447583441794533189705223... or in short 9.752490228984199 So we have a situation where javac, jit, Math and StrictMath generates inconsistent results. How do we resolve this situation? Quoting the Math package java doc: "If a method always has an error less than 0.5 ulps, the method always returns the floating-point number nearest the exact result; such a method is correctly rounded. A correctly rounded method is generally the best a floating-point approximation can be; however, it is impractical for many floating-point methods to be correctly rounded. Instead, for the Math class, a larger error bound of 1 or 2 ulps is allowed for certain methods" Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )? If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of: 9.7524902289841994797298917760120602447583441794533189705223... Cheers and have a great day! Xerxes From ahughes at redhat.com Mon May 24 06:44:59 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 24 May 2010 14:44:59 +0100 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: <4BFA7726.1030506@zafena.se> References: <4BFA7726.1030506@zafena.se> Message-ID: On 24 May 2010 13:55, Xerxes R?nby wrote: > Hi > > Im hoping to find someone who can enlighten me how to resolve a bug > where some hotspot JITs > fails the hotspot/test/compiler/6539464 jtreg regression test. > > The testcase looks like: > > public class Test { > ? ?static double log_value = 17197; > ? ?static double log_result = Math.log(log_value); > > ? ?public static void main(String[] args) throws Exception { > ? ? ? ?for (int i = 0; i < 1000000; i++) { > ? ? ? ? ? ?double log_result2 = Math.log(log_value); > ? ? ? ? ? ?if (log_result2 != log_result) { > ? ? ? ? ? ? ? ?throw new InternalError("Math.log produces inconsistent results: " + log_result2 + " != " + log_result); > ? ? ? ? ? ?} > ? ? ? ?} > ? ?} > } > > When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which > > ARCH+JVM combination ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? log_result (javac) ? ? ?log_result2 (jit) ? ? ? passes regression test? > ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) ? ? ? ? ?9.752490228984199 ? ? ? 9.752490228984199 ? ? ? yes > arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) ? ? ? ? ? ?9.75249022898412 ? ? ? ?9.752490228984199 ? ? ? no > x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 ? ? ? ?9.752490228984199 ? ? ? no > > While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs: > StrictMath.log(17197) = 9.75249022898412 > > And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha: > http://www.wolframalpha.com/input/?i=log%2817197%29 > log(17197) = 9.7524902289841994797298917760120602447583441794533189705223... > or in short 9.752490228984199 > > So we have a situation where javac, jit, Math and StrictMath generates inconsistent results. > How do we resolve this situation? > > Quoting the Math package java doc: > "If a method always has an error less than 0.5 ulps, the method always > ?returns the floating-point number nearest the exact result; such a > ?method is correctly rounded. ?A correctly rounded method is > ?generally the best a floating-point approximation can be; however, > ?it is impractical for many floating-point methods to be correctly > ?rounded. ?Instead, for the Math class, a larger error > ?bound of 1 or 2 ulps is allowed for certain methods" > > Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )? > If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all > JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of: > 9.7524902289841994797298917760120602447583441794533189705223... > > Cheers and have a great day! > Xerxes > > Do x86 and x86_64 give the same results if you actually use the same version of HotSpot as you do on ARM? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From xerxes at zafena.se Mon May 24 07:55:03 2010 From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=) Date: Mon, 24 May 2010 16:55:03 +0200 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: References: <4BFA7726.1030506@zafena.se> Message-ID: <4BFA9347.8090509@zafena.se> On 2010-05-24 15:44, Andrew John Hughes wrote: > On 24 May 2010 13:55, Xerxes R?nby wrote: > >> Hi >> >> Im hoping to find someone who can enlighten me how to resolve a bug >> where some hotspot JITs >> fails the hotspot/test/compiler/6539464 jtreg regression test. >> >> The testcase looks like: >> >> public class Test { >> static double log_value = 17197; >> static double log_result = Math.log(log_value); >> >> public static void main(String[] args) throws Exception { >> for (int i = 0; i < 1000000; i++) { >> double log_result2 = Math.log(log_value); >> if (log_result2 != log_result) { >> throw new InternalError("Math.log produces inconsistent results: " + log_result2 + " != " + log_result); >> } >> } >> } >> } >> >> When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which >> >> ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? >> ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes >> arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no >> x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no >> >> While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs: >> StrictMath.log(17197) = 9.75249022898412 >> >> And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha: >> http://www.wolframalpha.com/input/?i=log%2817197%29 >> log(17197) = 9.7524902289841994797298917760120602447583441794533189705223... >> or in short 9.752490228984199 >> >> So we have a situation where javac, jit, Math and StrictMath generates inconsistent results. >> How do we resolve this situation? >> >> Quoting the Math package java doc: >> "If a method always has an error less than 0.5 ulps, the method always >> returns the floating-point number nearest the exact result; such a >> method is correctly rounded. A correctly rounded method is >> generally the best a floating-point approximation can be; however, >> it is impractical for many floating-point methods to be correctly >> rounded. Instead, for the Math class, a larger error >> bound of 1 or 2 ulps is allowed for certain methods" >> >> Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )? >> If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all >> JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of: >> 9.7524902289841994797298917760120602447583441794533189705223... >> >> Cheers and have a great day! >> Xerxes >> >> >> > Do x86 and x86_64 give the same results if you actually use the same > version of HotSpot as you do on ARM? > Im only able to test x86: But no javac still produces different ressult when compiling static double log_result = Math.log(log_value); and running javac on x86 and arm using the same version of hotspot: ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? ia32+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.752490228984199 9.752490228984199 yes arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no From tom.rodriguez at oracle.com Mon May 24 11:12:06 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 24 May 2010 11:12:06 -0700 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: <4BFA7726.1030506@zafena.se> References: <4BFA7726.1030506@zafena.se> Message-ID: On May 24, 2010, at 5:55 AM, Xerxes R?nby wrote: > > When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which > > ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? > ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes > arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no > x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no The test applies to a bug which was fixed in hs17 so testing with hs14 is sure to fail on x86_64 which is where the bug was. The purpose of the test is to make sure that the value doesn't change over time which isn't allowed. In the original bug the compiler had an intrinsic for log but the interpreter wasn't using the same intrinsic so the interpreter and compiler could return different answers. So presumably if you test with hs17 x86_64 will be fine but I don't know what the problem would be with the ARM port of shark. Does it have intrinsics for Math.log? Also note that javac isn't producing the constant value since it's doesn't constant fold Math.log, let alone any other Math or StrictMath call. That value is computed by the class initializer which will run in the interpreter. tom > > While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs: > StrictMath.log(17197) = 9.75249022898412 > > And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha: > http://www.wolframalpha.com/input/?i=log%2817197%29 > log(17197) = 9.7524902289841994797298917760120602447583441794533189705223... > or in short 9.752490228984199 > > So we have a situation where javac, jit, Math and StrictMath generates inconsistent results. > How do we resolve this situation? > > Quoting the Math package java doc: > "If a method always has an error less than 0.5 ulps, the method always > returns the floating-point number nearest the exact result; such a > method is correctly rounded. A correctly rounded method is > generally the best a floating-point approximation can be; however, > it is impractical for many floating-point methods to be correctly > rounded. Instead, for the Math class, a larger error > bound of 1 or 2 ulps is allowed for certain methods" > > Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )? > If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all > JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of: > 9.7524902289841994797298917760120602447583441794533189705223... > > Cheers and have a great day! > Xerxes > From Christian.Thalinger at Sun.COM Tue May 25 01:22:39 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 25 May 2010 10:22:39 +0200 Subject: review (XS) for 6490487: java support on 64 bit solaris x86 machines is broken. In-Reply-To: References: Message-ID: <1274775759.2370.7.camel@macbook> On Fri, 2010-05-21 at 11:35 -0700, Tom Rodriguez wrote: > resending because of earlier mail problems. > > http://cr.openjdk.java.net/~never/6490487/ > > 6490487: java support on 64 bit solaris x86 machines is broken. > Reviewed-by: > > This is a small annoying bug that should have been fixed long ago. > For some reason the 64 bit libjvm_db.so for talking to 32 bit > processes is only exported on sparc which means that 64 bit pstack > can't decode stacks in 32 bit processes. The fix is simply to always > export them. Tested with pstack and JPRT build. > > make/solaris/makefiles/defs.make Looks good. -- Christian From xerxes at zafena.se Tue May 25 01:37:51 2010 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 25 May 2010 10:37:51 +0200 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: References: <4BFA7726.1030506@zafena.se> Message-ID: <4BFB8C5F.4080500@zafena.se> On 2010-05-24 20:12, Tom Rodriguez wrote: > On May 24, 2010, at 5:55 AM, Xerxes R?nby wrote: > > >> When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which >> >> ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? >> ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes >> arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no >> x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no >> > The test applies to a bug which was fixed in hs17 so testing with hs14 is sure to fail on x86_64 which is where the bug was. The purpose of the test is to make sure that the value doesn't change over time which isn't allowed. In the original bug the compiler had an intrinsic for log but the interpreter wasn't using the same intrinsic so the interpreter and compiler could return different answers. So presumably if you test with hs17 x86_64 will be fine but I don't know what the problem would be with the ARM port of shark. Does it have intrinsics for Math.log? Yes ARM port of Shark uses a intrinsic for the Shark JIT. The Shark JIT uses the LLVM provided math intrinsics for log calculations, and the Shark Interpreter Zero lets the Math.log class method handle it and the class in turn uses the StrictMath.log JNI c call internally. The reason why I get different results are of course because i use two different implementations yet mathematically both valid approximations (+- 1ulps). > Also note that javac isn't producing the constant value since it's doesn't constant fold Math.log, let alone any other Math or StrictMath call. That value is computed by the class initializer which will run in the interpreter. > > tom > Thanks again for this heads up that the static value are calculated at runtime by the interpreter and not constant folded, it makes the problem crystal. We do now have enough information to sort out the bug http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=500 by making the Shark JIT call the same intrinsic as the StrictMath c library provides, or the other way around. Cheers and have a great day! Xerxes > >> While trying to figure out whats the correct result for the log(17197) calculation i tested what StrictMath.log outputs: >> StrictMath.log(17197) = 9.75249022898412 >> >> And in order to get an independent mathematically correct opinion of what log(17197) equals i asked wolfram alpha: >> http://www.wolframalpha.com/input/?i=log%2817197%29 >> log(17197) = 9.7524902289841994797298917760120602447583441794533189705223... >> or in short 9.752490228984199 >> >> So we have a situation where javac, jit, Math and StrictMath generates inconsistent results. >> How do we resolve this situation? >> >> Quoting the Math package java doc: >> "If a method always has an error less than 0.5 ulps, the method always >> returns the floating-point number nearest the exact result; such a >> method is correctly rounded. A correctly rounded method is >> generally the best a floating-point approximation can be; however, >> it is impractical for many floating-point methods to be correctly >> rounded. Instead, for the Math class, a larger error >> bound of 1 or 2 ulps is allowed for certain methods" >> >> Would this quotation imply that both log(17197) calculation results above are correct ( 9.752490228984199 and 9.75249022898412 )? >> If both calculations are correct then I propose that we should change the hotspot/test/compiler/6539464 jtreg regression test to make all >> JVM's pass the test when they are within +- 1 ulps from the mathematically correct answer of: >> 9.7524902289841994797298917760120602447583441794533189705223... >> >> Cheers and have a great day! >> Xerxes >> >> > From aph at redhat.com Tue May 25 01:47:16 2010 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 May 2010 09:47:16 +0100 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: <4BFB8C5F.4080500@zafena.se> References: <4BFA7726.1030506@zafena.se> <4BFB8C5F.4080500@zafena.se> Message-ID: <4BFB8E94.5060702@redhat.com> On 05/25/2010 09:37 AM, Xerxes R?nby wrote: > On 2010-05-24 20:12, Tom Rodriguez wrote: >> On May 24, 2010, at 5:55 AM, Xerxes R?nby wrote: >> >> >>> When running this testcase using various jvms / architectures i get varying results of the calculated log_result2 and log_result which >>> >>> ARCH+JVM combination log_result (javac) log_result2 (jit) passes regression test? >>> ia32+OpenJDK Server VM (build 14.0-b16, mixed mode) 9.752490228984199 9.752490228984199 yes >>> arm+OpenJDK Shark VM (build 16.0-b13, mixed mode) 9.75249022898412 9.752490228984199 no >>> x86_64+OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) 9.75249022898412 9.752490228984199 no >>> >> The test applies to a bug which was fixed in hs17 so testing with hs14 is sure to fail on x86_64 which is where the bug was. The purpose of the test is to make sure that the value doesn't change over time which isn't allowed. In the original bug the compiler had an intrinsic for log but the interpreter wasn't using the same intrinsic so the interpreter and compiler could return different answers. So presumably if you test with hs17 x86_64 will be fine but I don't know what the problem would be with the ARM port of shark. Does it have intrinsics for Math.log? > > Yes ARM port of Shark uses a intrinsic for the Shark JIT. > The Shark JIT uses the LLVM provided math intrinsics for log calculations, > and the Shark Interpreter Zero lets the Math.log class method handle it > and the class in turn uses the StrictMath.log JNI c call internally. > > The reason why I get different results are of course because i use two > different implementations yet mathematically both valid approximations > (+- 1ulps). That doesn't really explain it, though. How come the LLVM log returns a different value from the C library? Andrew. From erik.trimble at oracle.com Tue May 25 10:55:55 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 25 May 2010 17:55:55 +0000 Subject: hg: hsx/hsx17/baseline: Added tag hs17-b15 for changeset a9eaf7923c1f Message-ID: <20100525175602.2AEEB46E05@hg.openjdk.java.net> Changeset: d3fed7ec0d0a Author: trims Date: 2010-05-25 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/d3fed7ec0d0a Added tag hs17-b15 for changeset a9eaf7923c1f ! .hgtags From erik.trimble at oracle.com Tue May 25 11:00:09 2010 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 25 May 2010 18:00:09 +0000 Subject: hg: hsx/hsx17/master: Added tag hs17-b15 for changeset a9eaf7923c1f Message-ID: <20100525180015.C77B746E06@hg.openjdk.java.net> Changeset: d3fed7ec0d0a Author: trims Date: 2010-05-25 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx17/master/rev/d3fed7ec0d0a Added tag hs17-b15 for changeset a9eaf7923c1f ! .hgtags From christos at zoulas.com Tue May 25 13:50:20 2010 From: christos at zoulas.com (Christos Zoulas) Date: Tue, 25 May 2010 16:50:20 -0400 Subject: Math.log(17197) produces inconsistent results between javac, jit, Math and StrictMath on various architectures. In-Reply-To: <4BFA9347.8090509@zafena.se> from =?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?= (May 24, 4:55pm) Message-ID: <20100525205020.4759456425@rebar.astron.com> On May 24, 4:55pm, xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=) wrote: -- Subject: Re: Math.log(17197) produces inconsistent results between javac, | Im only able to test x86: | | But no javac still produces different ressult when compiling | | static double log_result = Math.log(log_value); | | and running javac on x86 and arm using the same version of hotspot: I have encountered this only on x86_64. x86 indeed works. The bug was introduced in jdk 1.6. christos From john.coomes at oracle.com Fri May 28 01:42:55 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 08:42:55 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20100528084255.7D8BE46E5F@hg.openjdk.java.net> Changeset: 412712f77af6 Author: ohair Date: 2010-05-25 15:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/412712f77af6 6943119: Rebrand source copyright notices Reviewed-by: darcy ! Makefile ! make/Defs-internal.gmk ! make/corba-rules.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jaxp-rules.gmk ! make/jaxws-rules.gmk ! make/jdk-rules.gmk ! make/jprt.gmk ! make/jprt.properties ! make/langtools-rules.gmk ! make/sanity-rules.gmk ! make/sponsors-rules.gmk ! make/templates/bsd-header ! make/templates/gpl-cp-header ! test/Makefile Changeset: fd3663286e77 Author: ohair Date: 2010-05-26 10:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/fd3663286e77 Merge Changeset: cf71cb515116 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/cf71cb515116 Added tag jdk7-b95 for changeset fd3663286e77 ! .hgtags From john.coomes at oracle.com Fri May 28 01:46:57 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 08:46:57 +0000 Subject: hg: jdk7/hotspot/jaxp: 3 new changesets Message-ID: <20100528084657.B7A1046E60@hg.openjdk.java.net> Changeset: 72d78db95fb1 Author: ohair Date: 2010-05-25 15:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/72d78db95fb1 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxp.properties ! make/Makefile ! make/jprt.properties Changeset: 07050840f98c Author: ohair Date: 2010-05-26 10:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/07050840f98c Merge Changeset: 9510ed0e1c7a Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/9510ed0e1c7a Added tag jdk7-b95 for changeset 07050840f98c ! .hgtags From john.coomes at oracle.com Fri May 28 01:47:01 2010 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 28 May 2010 08:47:01 +0000 Subject: hg: jdk7/hotspot/jaxws: 3 new changesets Message-ID: <20100528084701.1F4F346E61@hg.openjdk.java.net> Changeset: 4ac192952d75 Author: ohair Date: 2010-05-25 15:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/4ac192952d75 6943119: Rebrand source copyright notices Reviewed-by: darcy ! build-defs.xml ! build-drop-template.xml ! build.properties ! build.xml ! jaxws.properties ! make/Makefile ! make/jprt.properties Changeset: ee06cfb113d5 Author: ohair Date: 2010-05-26 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/ee06cfb113d5 Merge Changeset: 208fd4451232 Author: mikejwre Date: 2010-05-27 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/208fd4451232 Added tag jdk7-b95 for changeset ee06cfb113d5 ! .hgtags From daniel.daugherty at oracle.com Fri May 28 13:32:40 2010 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 28 May 2010 20:32:40 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20100528203245.4440046E7F@hg.openjdk.java.net> Changeset: e40a3601bc1f Author: kamg Date: 2010-05-19 10:19 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e40a3601bc1f 6911922: JVM must throw VerifyError for jsr or jsr_w opcodes in class file v.51+ 6693236: A class file whose version number is greater than to 50.0 must be verified using the typechecker Summary: Disable failover verification for classfiles >= v51 Reviewed-by: never, acorn, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: 3548f3198dca Author: dcubed Date: 2010-05-26 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3548f3198dca Merge