From bengt.rutisson at oracle.com Wed Feb 1 00:50:18 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 01 Feb 2012 09:50:18 +0100 Subject: Request for review 7141200: log some interesting information in ring buffers for crashes In-Reply-To: <532C3F2D-5D52-4337-9100-7177662007F7@oracle.com> References: <190D13C4-541E-470A-901F-EACB0D6A148C@oracle.com> <4F282E18.2060904@oracle.com> <532C3F2D-5D52-4337-9100-7177662007F7@oracle.com> Message-ID: <4F28FCCA.1000709@oracle.com> Tom, Thanks for changing this! It looks much better. The code is cleaner and the the information in the hs_err file is more useful. I have only looked through the GC code changes. I think it looks good. Some comments: The information provided by print_heap_after_gc() is very good, but it does not clearly communicate what type of GC it was. In particular for G1 I think it would be interesting to know if it was a young GC, mixed GC, initial mark of full GC. I'm ok with not including this information now, but maybe we can file a bug to include it? Or maybe we should just leave it for when we re-work this based on JFR... G1 has the notion of "extended" heap information. This can be turned on with the flag PrintHeapAtGCExtended. This gives a lot of information for each region in the heap. I tried running with your patch and turning this flag on. Fortunately you limit the length of the events so the hs_err file is not as huge as it could be. But it gets quite difficult to parse the hs_err file since the extended information kind of messes the output up. I'm attaching an example hs_err file with this output. Again, I'm ok with leaving this as it is and just filing a bug that we should try to turn off "extended" when we log the information for the event buffer. I don't expect that PrintHeapAtGCExtended will be widely used by customers. Code comments: psMarkSweep.cpp, psParallelCompact.cpp, psScavenge.cpp and collectedHeap.hpp If you change the calls "CollectedHeap::print_heap_before_gc()" to "heap->print_heap_before_gc()" the print_heap_before_gc() method does not have to be static. That also means that the _gc_heap_log does not have to be static. Instead we could always set it up in the CollectedHeap::CollectedHeap() constructor as. if (LogEvents) { _gc_heap_log = new GCHeapLog(); } else { _gc_heap_log = NULL; } No need for collectedHeap_log_init() and initialize_heap_log() anymore. collectedHeap.cpp void GCHeapLog::log_heap(bool before) { if (!should_log()) return; The GC code tries to standardize on always using {} after if. So, it would be nice if this was: void GCHeapLog::log_heap(bool before) { if (!should_log()) { return; } Overall this looks great. Thanks again for fixing all of this! Bengt On 2012-01-31 23:27, Tom Rodriguez wrote: > I've got a new version of the GC logging code. It's now using PrintHeapAtGC routines which will give more useful and better formatted output. I fixed all the review comments, deleted the EventMarks in GC code since no one objected, renamed _count to _length and _filled to _count in EventLogBase. Each output line is preceded by Event: to help with greppability. I've updated the webrev and the examples. > > Thanks for all the good feedback. > > Here's a sample of the new GC output: > > GC Heap History (10): > Event: 9672681252 GC heap before > {Heap before GC invocations=25 (full 12): > PSYoungGen total 19712K, used 338K [0xe1e00000, 0xe3400000, 0xf7400000) > eden space 16896K, 2% used [0xe1e00000,0xe1e54870,0xe2e80000) > from space 2816K, 0% used [0xe3140000,0xe3140000,0xe3400000) > to space 2816K, 0% used [0xe2e80000,0xe2e80000,0xe3140000) > PSOldGen total 43008K, used 366K [0xb7400000, 0xb9e00000, 0xe1e00000) > object space 43008K, 0% used [0xb7400000,0xb745bbf8,0xb9e00000) > PSPermGen total 16384K, used 2398K [0xb3400000, 0xb4400000, 0xb7400000) > object space 16384K, 14% used [0xb3400000,0xb36578e0,0xb4400000) > Event: 9672681255 GC heap after > Heap after GC invocations=25 (full 12): > PSYoungGen total 19712K, used 48K [0xe1e00000, 0xe3400000, 0xf7400000) > eden space 16896K, 0% used [0xe1e00000,0xe1e00000,0xe2e80000) > from space 2816K, 1% used [0xe2e80000,0xe2e8c000,0xe3140000) > to space 2816K, 0% used [0xe3140000,0xe3140000,0xe3400000) > PSOldGen total 43008K, used 366K [0xb7400000, 0xb9e00000, 0xe1e00000) > object space 43008K, 0% used [0xb7400000,0xb745bbf8,0xb9e00000) > PSPermGen total 16384K, used 2398K [0xb3400000, 0xb4400000, 0xb7400000) > object space 16384K, 14% used [0xb3400000,0xb36578e0,0xb4400000) > } > > A full example is at http://cr.openjdk.java.net/~never/7141200/example1.log. > > tom > > On Jan 31, 2012, at 10:08 AM, Kevin Walls wrote: > >> Hi Tom, >> >> Thanks for the examples. >> >> Really like that we have a timestamp so we can see the ordering of separate types >> of events. But we will get questions on how to convert a big number like >> 9617182121 into a time, and how it relates to times we see in other log files: >> can we convert it, e.g the same format as the GC logs? >> >> (worst case, I was thinking we log the value of first_hrtime so we have some baseline, >> but I'm sure we can make it prettier than that 8-) ) >> >> >> Why are the GC events all happening in the time period: Time: 0.000000.3 - 0.000000.3 >> >> That must be the format string %f.3 in memoryManager.cpp. Again maybe we >> can make this more readable, this figure will no doubt be used to search GC logs. >> >> >> Trivial typos: >> events.hpp line 108, maybe "Should only be called while mutex is held." >> events.hpp line 58 subclassed rather than subclasses. >> >> >> Thanks! >> Kevin >> >> >> On 31/01/12 07:50, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/7141200 >>> 664 lines changed: 389 ins; 185 del; 90 mod; 37188 unchg >>> >>> 7141200: log some interesting information in ring buffers for crashes >>> Reviewed-by: >>> >>> As part of convergence with JRockit it was requested that Hotspot >>> capture some internal events in ring buffer so that they could be >>> dumped into the error log to provide more context at crash time. I >>> chose to make these logs be mostly text based for simplicity of >>> implementation. Eventually more of the flight recorder infrastructure >>> will be in place and the recording of this kind of data should be more >>> integrated the infrastructure for that. So my current implementation >>> is somewhat ad hoc since I expect it will be revisited. >>> >>> This also doesn't include one of the more important features, dumping >>> crashing context when scanning the heap. Capturing that information >>> without impacting GC performance is difficult and would require broad >>> changes in the heap iteration code. That can possibly be address later. >>> >>> I've chosen to tear out the existing Events class which was a debug >>> only feature of limited use and extend that into a collection of >>> product ring buffers. They are registered during JVM startup and >>> dumped into the hs_err log when the JVM crashes. There are a couple >>> different categories maintained: compilation, deopt, internal >>> exceptions, other uncategorized messages and GC events. Each ring >>> buffer has it's own mutex to reduce contention across different kinds >>> of events and generally logging is performed for relatively infrequent >>> or expensive events to minimize any performance penalty. I also chose >>> to maintain separate logs for the categories so that higher frequency >>> events one kind don't hide other kinds. >>> >>> I eliminated some of the less useful Events::log calls as well and >>> move some others around. >>> >>> The GC logging keeps track of GC history using GCStatInfos. This has >>> the benefit that it's GC independent and provides before and after >>> information. It could also or instead capture Universe::print_on >>> though that's pretty verbose output. The GC section is fairly long >>> and I'm not sure what the best output would be. Opinions would be >>> appreciated. >>> >>> There are some EventMarks in GC code that I'm tempted to delete. Any >>> objections? >>> >>> I put a couple example logs at: >>> >>> http://cr.openjdk.java.net/~never/7141200/example1.log >>> http://cr.openjdk.java.net/~never/7141200/example2.log >>> >>> I can produce others if needed. >>> >>> Performance seems to be largely unchanged according to refworkload but >>> I'm still running some benchmarks. Tested with JCK vm and lang, and >>> the nsk tests. >>> >>> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid4492.log Url: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120201/6d36df85/hs_err_pid4492-0001.log From christian.thalinger at oracle.com Wed Feb 1 02:26:24 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 1 Feb 2012 11:26:24 +0100 Subject: Request for review (S): 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 In-Reply-To: References: Message-ID: <5D3BF751-2A8A-4C38-A5DB-383CF1A8156D@oracle.com> On Jan 31, 2012, at 8:07 PM, Volker Simonis wrote: > Hi, > > as the test in the webrev demonstrates, the MH spread invoker > will crashes the VM if invoked with a NULL argument on x86_32 > platforms. > > This is because nn 32-bit Intel platforms, the spread invoker > uses the 'rsi' register as temporary. But because 'rsi' also > contains the 'saved_last_sp' on x86_32 platforms, 'rsi' has to be > temporary saved on the stack. If this saving is done before a > failing 'NULL' check in the spread adapter, the following > excpetion handling routine will be confused by the extra value on > the stack, because it expects to find the return address here. > > To fix this problem, I've exchanged the usage of the temporary > registers 'rsi' and 'rdi' in the spread adapter such that we only > have to save the value of 'rsi' to the stack after the NULL check > was done: > > http://cr.openjdk.java.net/~simonis/SpreadNullArg/ Thanks for the detailed bug report and the fix. I filed: 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 and created and webrev just for the record: http://cr.openjdk.java.net/~twisti/7141637/ The changes look good, I fixed a typo and moved the test into the right directory. -- Chris > > Regards, > Volker > > PS: please don't forget to update the test directory name after a > bug id was assigned to this issue. From volker.simonis at gmail.com Wed Feb 1 02:36:15 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Feb 2012 11:36:15 +0100 Subject: Request for review (S): 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 In-Reply-To: <5D3BF751-2A8A-4C38-A5DB-383CF1A8156D@oracle.com> References: <5D3BF751-2A8A-4C38-A5DB-383CF1A8156D@oracle.com> Message-ID: Looks good:) Thank you, Volker On Wed, Feb 1, 2012 at 11:26 AM, Christian Thalinger wrote: > > On Jan 31, 2012, at 8:07 PM, Volker Simonis wrote: > >> Hi, >> >> as the test in the webrev demonstrates, the MH spread invoker >> will crashes the VM if invoked with a NULL argument on x86_32 >> platforms. >> >> This is because nn 32-bit Intel platforms, the spread invoker >> uses the 'rsi' register as temporary. But because 'rsi' also >> contains the 'saved_last_sp' on x86_32 platforms, 'rsi' has to be >> temporary saved on the stack. ?If this saving is done before a >> failing 'NULL' check in the spread adapter, the following >> excpetion handling routine will be confused by the extra value on >> the stack, because it expects to find the return address here. >> >> To fix this problem, I've exchanged the usage of the temporary >> registers 'rsi' and 'rdi' in the spread adapter such that we only >> have to save the value of 'rsi' to the stack after the NULL check >> was done: >> >> http://cr.openjdk.java.net/~simonis/SpreadNullArg/ > > Thanks for the detailed bug report and the fix. ?I filed: > > 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 > > and created and webrev just for the record: > > http://cr.openjdk.java.net/~twisti/7141637/ > > The changes look good, I fixed a typo and moved the test into the right directory. > > -- Chris > >> >> Regards, >> Volker >> >> PS: please don't forget to update the test directory name after a >> bug id was assigned to this issue. > From tom.rodriguez at oracle.com Wed Feb 1 07:16:45 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Feb 2012 07:16:45 -0800 Subject: Request for review 7141200: log some interesting information in ring buffers for crashes In-Reply-To: <4F28FCCA.1000709@oracle.com> References: <190D13C4-541E-470A-901F-EACB0D6A148C@oracle.com> <4F282E18.2060904@oracle.com> <532C3F2D-5D52-4337-9100-7177662007F7@oracle.com> <4F28FCCA.1000709@oracle.com> Message-ID: On Feb 1, 2012, at 12:50 AM, Bengt Rutisson wrote: > > Tom, > > Thanks for changing this! It looks much better. The code is cleaner and the the information in the hs_err file is more useful. > > I have only looked through the GC code changes. I think it looks good. > > Some comments: > > The information provided by print_heap_after_gc() is very good, but it does not clearly communicate what type of GC it was. In particular for G1 I think it would be interesting to know if it was a young GC, mixed GC, initial mark of full GC. I'm ok with not including this information now, but maybe we can file a bug to include it? Or maybe we should just leave it for when we re-work this based on JFR? I'd like to not rework that at this point. I'll file a bug for some enhancements. > > G1 has the notion of "extended" heap information. This can be turned on with the flag PrintHeapAtGCExtended. This gives a lot of information for each region in the heap. I tried running with your patch and turning this flag on. Fortunately you limit the length of the events so the hs_err file is not as huge as it could be. But it gets quite difficult to parse the hs_err file since the extended information kind of messes the output up. I'm attaching an example hs_err file with this output. > > Again, I'm ok with leaving this as it is and just filing a bug that we should try to turn off "extended" when we log the information for the event buffer. I don't expect that PrintHeapAtGCExtended will be widely used by customers. Ok. That sounds good. > > Code comments: > > psMarkSweep.cpp, psParallelCompact.cpp, psScavenge.cpp and collectedHeap.hpp > > If you change the calls "CollectedHeap::print_heap_before_gc()" to "heap->print_heap_before_gc()" the print_heap_before_gc() method does not have to be static. That also means that the _gc_heap_log does not have to be static. Instead we could always set it up in the CollectedHeap::CollectedHeap() constructor as. > > if (LogEvents) { > _gc_heap_log = new GCHeapLog(); > } else { > _gc_heap_log = NULL; > } > > No need for collectedHeap_log_init() and initialize_heap_log() anymore. I had originally gone with static because it seemed simpler, but you're right it would be easy to make it non-static. > > > > collectedHeap.cpp > > void GCHeapLog::log_heap(bool before) { > if (!should_log()) return; > > The GC code tries to standardize on always using {} after if. So, it would be nice if this was: > > void GCHeapLog::log_heap(bool before) { > if (!should_log()) { > return; > } Sure. I tend to do that too but occasionally I skip it. > > > Overall this looks great. Thanks again for fixing all of this! I'm glad we were able to resolve your concerns. I think it turned out pretty well. tom > > Bengt > > > On 2012-01-31 23:27, Tom Rodriguez wrote: >> I've got a new version of the GC logging code. It's now using PrintHeapAtGC routines which will give more useful and better formatted output. I fixed all the review comments, deleted the EventMarks in GC code since no one objected, renamed _count to _length and _filled to _count in EventLogBase. Each output line is preceded by Event: to help with greppability. I've updated the webrev and the examples. >> >> Thanks for all the good feedback. >> >> Here's a sample of the new GC output: >> >> GC Heap History (10): >> Event: 9672681252 GC heap before >> {Heap before GC invocations=25 (full 12): >> PSYoungGen total 19712K, used 338K [0xe1e00000, 0xe3400000, 0xf7400000) >> eden space 16896K, 2% used [0xe1e00000,0xe1e54870,0xe2e80000) >> from space 2816K, 0% used [0xe3140000,0xe3140000,0xe3400000) >> to space 2816K, 0% used [0xe2e80000,0xe2e80000,0xe3140000) >> PSOldGen total 43008K, used 366K [0xb7400000, 0xb9e00000, 0xe1e00000) >> object space 43008K, 0% used [0xb7400000,0xb745bbf8,0xb9e00000) >> PSPermGen total 16384K, used 2398K [0xb3400000, 0xb4400000, 0xb7400000) >> object space 16384K, 14% used [0xb3400000,0xb36578e0,0xb4400000) >> Event: 9672681255 GC heap after >> Heap after GC invocations=25 (full 12): >> PSYoungGen total 19712K, used 48K [0xe1e00000, 0xe3400000, 0xf7400000) >> eden space 16896K, 0% used [0xe1e00000,0xe1e00000,0xe2e80000) >> from space 2816K, 1% used [0xe2e80000,0xe2e8c000,0xe3140000) >> to space 2816K, 0% used [0xe3140000,0xe3140000,0xe3400000) >> PSOldGen total 43008K, used 366K [0xb7400000, 0xb9e00000, 0xe1e00000) >> object space 43008K, 0% used [0xb7400000,0xb745bbf8,0xb9e00000) >> PSPermGen total 16384K, used 2398K [0xb3400000, 0xb4400000, 0xb7400000) >> object space 16384K, 14% used [0xb3400000,0xb36578e0,0xb4400000) >> } >> >> A full example is at http://cr.openjdk.java.net/~never/7141200/example1.log. >> >> tom >> >> On Jan 31, 2012, at 10:08 AM, Kevin Walls wrote: >> >>> Hi Tom, >>> >>> Thanks for the examples. >>> >>> Really like that we have a timestamp so we can see the ordering of separate types >>> of events. But we will get questions on how to convert a big number like >>> 9617182121 into a time, and how it relates to times we see in other log files: >>> can we convert it, e.g the same format as the GC logs? >>> >>> (worst case, I was thinking we log the value of first_hrtime so we have some baseline, >>> but I'm sure we can make it prettier than that 8-) ) >>> >>> >>> Why are the GC events all happening in the time period: Time: 0.000000.3 - 0.000000.3 >>> >>> That must be the format string %f.3 in memoryManager.cpp. Again maybe we >>> can make this more readable, this figure will no doubt be used to search GC logs. >>> >>> >>> Trivial typos: >>> events.hpp line 108, maybe "Should only be called while mutex is held." >>> events.hpp line 58 subclassed rather than subclasses. >>> >>> >>> Thanks! >>> Kevin >>> >>> >>> On 31/01/12 07:50, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/7141200 >>>> 664 lines changed: 389 ins; 185 del; 90 mod; 37188 unchg >>>> >>>> 7141200: log some interesting information in ring buffers for crashes >>>> Reviewed-by: >>>> >>>> As part of convergence with JRockit it was requested that Hotspot >>>> capture some internal events in ring buffer so that they could be >>>> dumped into the error log to provide more context at crash time. I >>>> chose to make these logs be mostly text based for simplicity of >>>> implementation. Eventually more of the flight recorder infrastructure >>>> will be in place and the recording of this kind of data should be more >>>> integrated the infrastructure for that. So my current implementation >>>> is somewhat ad hoc since I expect it will be revisited. >>>> >>>> This also doesn't include one of the more important features, dumping >>>> crashing context when scanning the heap. Capturing that information >>>> without impacting GC performance is difficult and would require broad >>>> changes in the heap iteration code. That can possibly be address later. >>>> >>>> I've chosen to tear out the existing Events class which was a debug >>>> only feature of limited use and extend that into a collection of >>>> product ring buffers. They are registered during JVM startup and >>>> dumped into the hs_err log when the JVM crashes. There are a couple >>>> different categories maintained: compilation, deopt, internal >>>> exceptions, other uncategorized messages and GC events. Each ring >>>> buffer has it's own mutex to reduce contention across different kinds >>>> of events and generally logging is performed for relatively infrequent >>>> or expensive events to minimize any performance penalty. I also chose >>>> to maintain separate logs for the categories so that higher frequency >>>> events one kind don't hide other kinds. >>>> >>>> I eliminated some of the less useful Events::log calls as well and >>>> move some others around. >>>> >>>> The GC logging keeps track of GC history using GCStatInfos. This has >>>> the benefit that it's GC independent and provides before and after >>>> information. It could also or instead capture Universe::print_on >>>> though that's pretty verbose output. The GC section is fairly long >>>> and I'm not sure what the best output would be. Opinions would be >>>> appreciated. >>>> >>>> There are some EventMarks in GC code that I'm tempted to delete. Any >>>> objections? >>>> >>>> I put a couple example logs at: >>>> >>>> http://cr.openjdk.java.net/~never/7141200/example1.log >>>> http://cr.openjdk.java.net/~never/7141200/example2.log >>>> >>>> I can produce others if needed. >>>> >>>> Performance seems to be largely unchanged according to refworkload but >>>> I'm still running some benchmarks. Tested with JCK vm and lang, and >>>> the nsk tests. >>>> >>>> > > From james.melvin at oracle.com Wed Feb 1 11:06:26 2012 From: james.melvin at oracle.com (James Melvin) Date: Wed, 01 Feb 2012 14:06:26 -0500 Subject: RFR(S): 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X In-Reply-To: <4F285433.4030106@oracle.com> References: <4F284ED3.3070303@oracle.com> <4F285433.4030106@oracle.com> Message-ID: <4F298D32.9080904@oracle.com> Dan, Thanks for the excellent code review. I've incorporated all your suggestions. Here is an updated webrev and JPRT job... WEBREV: http://cr.openjdk.java.net/~jmelvin/7123386/webrev.01 JPRT JOB (internal): 2012-02-01-164233.jmelvin.7123386 Thanks, Jim On 1/31/12 3:50 PM, Daniel D. Daugherty wrote: > On 1/31/12 1:28 PM, James Melvin wrote: >> Hi, >> >> Please review the change to HotSpot to package JVM libraries in a >> universal binary on Mac OS X. The current plan of record is to only >> support a 64-bit JVM on Mac OS X. This solution preserves the option to >> additionally include other architectures in the universal binary >> in the future. It also further encapsulates platform specific makefile >> changes for Mac OS X builds. >> >> Feedback welcome... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7123386/webrev.00 > > Thumbs up! > > Please update copyright years to 2012. > > make/Makefile > No comments. > > make/bsd/makefiles/defs.make > nit: line 174: 'settins -> 'settings' > > line 192, 196, 197 - those '.txt' files aren't binaries... :-) > > line 198: Is there a reason not to have the Client VM on the > "LIPO" list? We may not support a 64-bit Client VM, but > that doesn't mean someone in the OpenJDK world wouldn't > want/like/support one... > > make/defs.make > No comments. > > make/bsd/makefiles/universal.gmk > line 79: '-xfp' instead of '-xf'? Preserves timestamps... From tom.rodriguez at oracle.com Wed Feb 1 11:08:35 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Feb 2012 11:08:35 -0800 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F27A26E.5020803@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> Message-ID: >>>> >>>> >>>> You still use tty->timestamp().milliseconds() instead of javaTimeNanos(). Not sure whether you just didn't get to fixing it yet or if you decided against it. >>> I decided against it. It's a printing timestamp so matching the time stamp in tty seemed to make more sense to me. >> I'm about to send out a webrev for some other changes and I'm going to correct this to use javaTimeNanos to be consistent with the other GC timestamps. I'm also going to remove the extra braces in safepoint.cpp. > > Had a quick look at the changes you sent out for 7013347. I see that you have included these fixes there. Thanks! I think that using tty->timestamp().milliseconds() was actually correct. GC uses gclog_or_tty->stamp() or gclog_or_tty->date_stamp() for all the times printed in the logs that I can see, which uses the same value as timestamp().milliseconds(). javaTimeNanos (and previous javaTimeMillis) appears to be used for measuring elapsed times. Am I reading this wrong? tom > > Bengt > >> tom >> >>>> >>>> >>>> gcLocker.hpp >>>> >>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>> >>>> Not sure what the correct thing is here, but the GC code seems to use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only difference is for optimized builds (and of course using #ifndef PRODUCT instead of #ifdef ASSERT). >>> I didn't want it doing any work in optimized builds so that's why it's NOT_DEBUG_RETURN. >>> >>>> >>>> >>>> safepoint.cpp >>>> >>>> Not strictly related to your change, but the SafepointSynchronize::begin() method is missing one indentation level due to the the scoping that starts on line 139: >>> Yes, I noticed that too. The whole thing could be factored better too. I already pushed so I can't fix it. I've got another change coming so maybe I'll fix it in there. Thanks. >>> >>> tom >>> >>>> 139 { >>>> 140 MutexLocker mu(Safepoint_lock); >>>> 141 >>>> 142 // Reset the count of active JNI critical threads >>>> 143 _current_jni_active_count = 0; >>>> >>>> This scope ends at the end of the method: >>>> >>>> 398 if (PrintSafepointStatistics) { >>>> 399 // Record how much time spend on the above cleanup tasks >>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>> 401 } >>>> 402 } >>>> 403 } >>>> >>>> It seems to me that the scope is not really necessary. In that case, can we remove it? It would be nice to have the method correctly indented. If we decide to keep the scope I'd prefer a comment on line 402, to indicate that it is the end of the MutexLocker scope. >>>> >>>> Bengt >>>> >>>> On 2012-01-30 03:26, David Holmes wrote: >>>>> Hi Tom, >>>>> >>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>> >>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>> Thanks Vladimir! >>>>>>> >>>>>>> Overall I find it difficult to follow the protocol that applies here - in particular how safepoints can and can not appear between different methods and the way in which needs_gc() might change value between the enter and exit of a critical region. Without that understanding it is hard to evaluate the correctness of the new approach. >>>>>> I tried to put in enough asserts to ensure that it was clear what invariants are in force when updating the state. Safepoints can appear wherever they normally can appear, while locking and waiting on mutexes. _needs_gc can only change from false to true during a safepoint. For the most part everything operates exactly as it used to once _needs_gc is set and the only trick is computing the correct value of _jni_active_count when setting _needs_gc to be true. The debug code that still performs the atomics attempts to verify that the computed value and actual value are in sync. Is there any more that I can explain about how it operates? >>>>> It's my ignorance of the overall operation that makes evaluating this change difficult for me. But thanks to your side-band emails I now have a much clear understanding of things - thanks. And the protocol seems safe. >>>>> >>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>> >>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>> >>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis here? Use of this was recently changed elsewhere in the GC code. >>>>>> It's only printing code, but I'll switch it to use tty->timestamp().milliseconds() which will make it match our internal time stamps, which seems like a useful property. Is that ok? >>>>> The recent GC changes switched to using javaTimeNanos() converted to millis - see 7117303 and 7129514. The TimeStamp is based on elapsedCounter which is still a time-of-day source on some platforms and so not monotonic. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I've updated the webrev. >>>>>> >>>>>> tom >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In GC_locker::check_active_before_gc() move wait_begin initialization >>>>>>>> under Print* check since it used only under such checks. Could method >>>>>>>> check_active_before_gc() be called from different threads concurrently? >>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>> >>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>> Summary: >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> The machinery for GC_locker which supports GetPrimitiveArrayCritical >>>>>>>>> maintains a count of the number of threads that currently have raw >>>>>>>>> pointers exposed. This is used to allow existing critical sections to >>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>> these counts are updated using atomic all the time, even if a GC isn't >>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>> threads are hammering atomic operations on the jni_lock_count. The >>>>>>>>> count only needs to be valid when checking if a critical section is >>>>>>>>> currently active and when draining the existing sections. The fix is >>>>>>>>> to make the count be computed as part of the safepointing machinery >>>>>>>>> and to only decrement the counters when _needs_gc is true. In debug >>>>>>>>> mode the old count is maintained and validated against the lazily >>>>>>>>> computed count. >>>>>>>>> >>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical with many >>>>>>>>> threads and relatively short critical section it can more than double >>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily measurable >>>>>>>>> with larger scale programs. >>>>>>>>> >>>>>>>>> Tested with microbenchmark that stresses GetPrimtiveArrayCritical and >>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also ran the >>>>>>>>> java.io regression tests from the JDK. >>>>>>>>> > From bengt.rutisson at oracle.com Thu Feb 2 00:49:03 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 02 Feb 2012 09:49:03 +0100 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> Message-ID: <4F2A4DFF.1010809@oracle.com> On 2012-02-01 20:08, Tom Rodriguez wrote: >>>>> >>>>> You still use tty->timestamp().milliseconds() instead of javaTimeNanos(). Not sure whether you just didn't get to fixing it yet or if you decided against it. >>>> I decided against it. It's a printing timestamp so matching the time stamp in tty seemed to make more sense to me. >>> I'm about to send out a webrev for some other changes and I'm going to correct this to use javaTimeNanos to be consistent with the other GC timestamps. I'm also going to remove the extra braces in safepoint.cpp. >> Had a quick look at the changes you sent out for 7013347. I see that you have included these fixes there. Thanks! > I think that using tty->timestamp().milliseconds() was actually correct. GC uses gclog_or_tty->stamp() or gclog_or_tty->date_stamp() for all the times printed in the logs that I can see, which uses the same value as timestamp().milliseconds(). javaTimeNanos (and previous javaTimeMillis) appears to be used for measuring elapsed times. Am I reading this wrong? First, I was not really arguing for doing this one way or the other. It was just not clear to me from the review comments if you wanted to change to javaTimeNanos() or not. You are right about the use in the GC code. We recently changed to use javaTimeNanos() for time intervals, but we use tty->timestamp().seconds() to print the time stamps. If I remember correctly, you were logging how long a thread had to wait, so it seemed like an interval to me. But, as I said, I was mostly just wondering what the decision was. It would probably be a good idea to use the same time source for time stamps and intervals. When we were using javaTimeMillis() I think it was consistent, but maybe we should now change to javaTimeNanos() for tty->timestamp()? I can't say I know the implications of changing tty->timestamp() to use the same timesource as javaTimeNanos(). Currently they boil down to the same OS calls on Windows, but on Linux and Solaris the implementations are quite different. Bengt Bengt > > tom > >> Bengt >> >>> tom >>> >>>>> >>>>> gcLocker.hpp >>>>> >>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>> >>>>> Not sure what the correct thing is here, but the GC code seems to use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only difference is for optimized builds (and of course using #ifndef PRODUCT instead of #ifdef ASSERT). >>>> I didn't want it doing any work in optimized builds so that's why it's NOT_DEBUG_RETURN. >>>> >>>>> >>>>> safepoint.cpp >>>>> >>>>> Not strictly related to your change, but the SafepointSynchronize::begin() method is missing one indentation level due to the the scoping that starts on line 139: >>>> Yes, I noticed that too. The whole thing could be factored better too. I already pushed so I can't fix it. I've got another change coming so maybe I'll fix it in there. Thanks. >>>> >>>> tom >>>> >>>>> 139 { >>>>> 140 MutexLocker mu(Safepoint_lock); >>>>> 141 >>>>> 142 // Reset the count of active JNI critical threads >>>>> 143 _current_jni_active_count = 0; >>>>> >>>>> This scope ends at the end of the method: >>>>> >>>>> 398 if (PrintSafepointStatistics) { >>>>> 399 // Record how much time spend on the above cleanup tasks >>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>> 401 } >>>>> 402 } >>>>> 403 } >>>>> >>>>> It seems to me that the scope is not really necessary. In that case, can we remove it? It would be nice to have the method correctly indented. If we decide to keep the scope I'd prefer a comment on line 402, to indicate that it is the end of the MutexLocker scope. >>>>> >>>>> Bengt >>>>> >>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>> Hi Tom, >>>>>> >>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>> >>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>> Thanks Vladimir! >>>>>>>> >>>>>>>> Overall I find it difficult to follow the protocol that applies here - in particular how safepoints can and can not appear between different methods and the way in which needs_gc() might change value between the enter and exit of a critical region. Without that understanding it is hard to evaluate the correctness of the new approach. >>>>>>> I tried to put in enough asserts to ensure that it was clear what invariants are in force when updating the state. Safepoints can appear wherever they normally can appear, while locking and waiting on mutexes. _needs_gc can only change from false to true during a safepoint. For the most part everything operates exactly as it used to once _needs_gc is set and the only trick is computing the correct value of _jni_active_count when setting _needs_gc to be true. The debug code that still performs the atomics attempts to verify that the computed value and actual value are in sync. Is there any more that I can explain about how it operates? >>>>>> It's my ignorance of the overall operation that makes evaluating this change difficult for me. But thanks to your side-band emails I now have a much clear understanding of things - thanks. And the protocol seems safe. >>>>>> >>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>> >>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>> >>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis here? Use of this was recently changed elsewhere in the GC code. >>>>>>> It's only printing code, but I'll switch it to use tty->timestamp().milliseconds() which will make it match our internal time stamps, which seems like a useful property. Is that ok? >>>>>> The recent GC changes switched to using javaTimeNanos() converted to millis - see 7117303 and 7129514. The TimeStamp is based on elapsedCounter which is still a time-of-day source on some platforms and so not monotonic. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I've updated the webrev. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin initialization >>>>>>>>> under Print* check since it used only under such checks. Could method >>>>>>>>> check_active_before_gc() be called from different threads concurrently? >>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>> >>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>> Summary: >>>>>>>>>> Reviewed-by: >>>>>>>>>> >>>>>>>>>> The machinery for GC_locker which supports GetPrimitiveArrayCritical >>>>>>>>>> maintains a count of the number of threads that currently have raw >>>>>>>>>> pointers exposed. This is used to allow existing critical sections to >>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>> these counts are updated using atomic all the time, even if a GC isn't >>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>> threads are hammering atomic operations on the jni_lock_count. The >>>>>>>>>> count only needs to be valid when checking if a critical section is >>>>>>>>>> currently active and when draining the existing sections. The fix is >>>>>>>>>> to make the count be computed as part of the safepointing machinery >>>>>>>>>> and to only decrement the counters when _needs_gc is true. In debug >>>>>>>>>> mode the old count is maintained and validated against the lazily >>>>>>>>>> computed count. >>>>>>>>>> >>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical with many >>>>>>>>>> threads and relatively short critical section it can more than double >>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily measurable >>>>>>>>>> with larger scale programs. >>>>>>>>>> >>>>>>>>>> Tested with microbenchmark that stresses GetPrimtiveArrayCritical and >>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also ran the >>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>> From david.holmes at oracle.com Thu Feb 2 01:31:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Feb 2012 19:31:25 +1000 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F2A4DFF.1010809@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> Message-ID: <4F2A57ED.9050207@oracle.com> On 2/02/2012 6:49 PM, Bengt Rutisson wrote: > On 2012-02-01 20:08, Tom Rodriguez wrote: >>>>>> >>>>>> You still use tty->timestamp().milliseconds() instead of >>>>>> javaTimeNanos(). Not sure whether you just didn't get to fixing it >>>>>> yet or if you decided against it. >>>>> I decided against it. It's a printing timestamp so matching the >>>>> time stamp in tty seemed to make more sense to me. >>>> I'm about to send out a webrev for some other changes and I'm going >>>> to correct this to use javaTimeNanos to be consistent with the other >>>> GC timestamps. I'm also going to remove the extra braces in >>>> safepoint.cpp. >>> Had a quick look at the changes you sent out for 7013347. I see that >>> you have included these fixes there. Thanks! >> I think that using tty->timestamp().milliseconds() was actually >> correct. GC uses gclog_or_tty->stamp() or gclog_or_tty->date_stamp() >> for all the times printed in the logs that I can see, which uses the >> same value as timestamp().milliseconds(). javaTimeNanos (and previous >> javaTimeMillis) appears to be used for measuring elapsed times. Am I >> reading this wrong? > > First, I was not really arguing for doing this one way or the other. It > was just not clear to me from the review comments if you wanted to > change to javaTimeNanos() or not. > > You are right about the use in the GC code. We recently changed to use > javaTimeNanos() for time intervals, but we use > tty->timestamp().seconds() to print the time stamps. If I remember > correctly, you were logging how long a thread had to wait, so it seemed > like an interval to me. But, as I said, I was mostly just wondering what > the decision was. > > It would probably be a good idea to use the same time source for time > stamps and intervals. When we were using javaTimeMillis() I think it was > consistent, but maybe we should now change to javaTimeNanos() for > tty->timestamp()? > > I can't say I know the implications of changing tty->timestamp() to use > the same timesource as javaTimeNanos(). Currently they boil down to the > same OS calls on Windows, but on Linux and Solaris the implementations > are quite different. The primary difference is that javaTimeMillis reports the time-of-day, while javaTimeNanos does not. If you really want a timestamp that you can correlate with other time-related events then javaTimeMillis is what you need, but then you have to deal with lower resolution and non-monotonicity. A compromise is a time-source with the resolution of nanoTime which is sync'ed to time-of-day at VM start (this is what the real-time clock gives you in the Real-Time Specification for Java). David ----- > Bengt > > > > > > > Bengt > >> >> tom >> >>> Bengt >>> >>>> tom >>>> >>>>>> >>>>>> gcLocker.hpp >>>>>> >>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>> >>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>> difference is for optimized builds (and of course using #ifndef >>>>>> PRODUCT instead of #ifdef ASSERT). >>>>> I didn't want it doing any work in optimized builds so that's why >>>>> it's NOT_DEBUG_RETURN. >>>>> >>>>>> >>>>>> safepoint.cpp >>>>>> >>>>>> Not strictly related to your change, but the >>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>> level due to the the scoping that starts on line 139: >>>>> Yes, I noticed that too. The whole thing could be factored better >>>>> too. I already pushed so I can't fix it. I've got another change >>>>> coming so maybe I'll fix it in there. Thanks. >>>>> >>>>> tom >>>>> >>>>>> 139 { >>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>> 141 >>>>>> 142 // Reset the count of active JNI critical threads >>>>>> 143 _current_jni_active_count = 0; >>>>>> >>>>>> This scope ends at the end of the method: >>>>>> >>>>>> 398 if (PrintSafepointStatistics) { >>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>> 401 } >>>>>> 402 } >>>>>> 403 } >>>>>> >>>>>> It seems to me that the scope is not really necessary. In that >>>>>> case, can we remove it? It would be nice to have the method >>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>> comment on line 402, to indicate that it is the end of the >>>>>> MutexLocker scope. >>>>>> >>>>>> Bengt >>>>>> >>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>> Hi Tom, >>>>>>> >>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>> >>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>> Thanks Vladimir! >>>>>>>>> >>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>> correctness of the new approach. >>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>> during a safepoint. For the most part everything operates >>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>> how it operates? >>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>> protocol seems safe. >>>>>>> >>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>> >>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>> >>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>> that ok? >>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>> platforms and so not monotonic. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I've updated the webrev. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>> initialization >>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>> method >>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>> concurrently? >>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>> >>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>> Summary: >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> >>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>> have raw >>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>> sections to >>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>> GC isn't >>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>> jni_lock_count. The >>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>> section is >>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>> fix is >>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>> machinery >>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>> debug >>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>> lazily >>>>>>>>>>> computed count. >>>>>>>>>>> >>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>> with many >>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>> than double >>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>> measurable >>>>>>>>>>> with larger scale programs. >>>>>>>>>>> >>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>> ran the >>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>> > From bengt.rutisson at oracle.com Thu Feb 2 02:46:53 2012 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 2 Feb 2012 11:46:53 +0100 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F2A57ED.9050207@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> Message-ID: <3FF43C14-2D5E-4744-8A49-E8425DB4AADB@oracle.com> 2 feb 2012 kl. 10:31 skrev David Holmes : > On 2/02/2012 6:49 PM, Bengt Rutisson wrote: >> On 2012-02-01 20:08, Tom Rodriguez wrote: >>>>>>> >>>>>>> You still use tty->timestamp().milliseconds() instead of >>>>>>> javaTimeNanos(). Not sure whether you just didn't get to fixing it >>>>>>> yet or if you decided against it. >>>>>> I decided against it. It's a printing timestamp so matching the >>>>>> time stamp in tty seemed to make more sense to me. >>>>> I'm about to send out a webrev for some other changes and I'm going >>>>> to correct this to use javaTimeNanos to be consistent with the other >>>>> GC timestamps. I'm also going to remove the extra braces in >>>>> safepoint.cpp. >>>> Had a quick look at the changes you sent out for 7013347. I see that >>>> you have included these fixes there. Thanks! >>> I think that using tty->timestamp().milliseconds() was actually >>> correct. GC uses gclog_or_tty->stamp() or gclog_or_tty->date_stamp() >>> for all the times printed in the logs that I can see, which uses the >>> same value as timestamp().milliseconds(). javaTimeNanos (and previous >>> javaTimeMillis) appears to be used for measuring elapsed times. Am I >>> reading this wrong? >> >> First, I was not really arguing for doing this one way or the other. It >> was just not clear to me from the review comments if you wanted to >> change to javaTimeNanos() or not. >> >> You are right about the use in the GC code. We recently changed to use >> javaTimeNanos() for time intervals, but we use >> tty->timestamp().seconds() to print the time stamps. If I remember >> correctly, you were logging how long a thread had to wait, so it seemed >> like an interval to me. But, as I said, I was mostly just wondering what >> the decision was. >> >> It would probably be a good idea to use the same time source for time >> stamps and intervals. When we were using javaTimeMillis() I think it was >> consistent, but maybe we should now change to javaTimeNanos() for >> tty->timestamp()? >> >> I can't say I know the implications of changing tty->timestamp() to use >> the same timesource as javaTimeNanos(). Currently they boil down to the >> same OS calls on Windows, but on Linux and Solaris the implementations >> are quite different. > > The primary difference is that javaTimeMillis reports the time-of-day, while javaTimeNanos does not. If you really want a timestamp that you can correlate with other time-related events then javaTimeMillis is what you need, but then you have to deal with lower resolution and non-monotonicity. A compromise is a time-source with the resolution of nanoTime which is sync'ed to time-of-day at VM start (this is what the real-time clock gives you in the Real-Time Specification for Java). Thanks for the high level background on this. I saw this difference in the implementation but I didn't really know why they had to be different. Bengt > > David > ----- > >> Bengt >> >> >> >> >> >> >> Bengt >> >>> >>> tom >>> >>>> Bengt >>>> >>>>> tom >>>>> >>>>>>> >>>>>>> gcLocker.hpp >>>>>>> >>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>> >>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>> it's NOT_DEBUG_RETURN. >>>>>> >>>>>>> >>>>>>> safepoint.cpp >>>>>>> >>>>>>> Not strictly related to your change, but the >>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>> level due to the the scoping that starts on line 139: >>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>> >>>>>> tom >>>>>> >>>>>>> 139 { >>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>> 141 >>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>> 143 _current_jni_active_count = 0; >>>>>>> >>>>>>> This scope ends at the end of the method: >>>>>>> >>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>> 401 } >>>>>>> 402 } >>>>>>> 403 } >>>>>>> >>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>> case, can we remove it? It would be nice to have the method >>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>> MutexLocker scope. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>> Thanks Vladimir! >>>>>>>>>> >>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>> correctness of the new approach. >>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>> how it operates? >>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>> protocol seems safe. >>>>>>>> >>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>> >>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>> >>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>> that ok? >>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>> platforms and so not monotonic. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've updated the webrev. >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>> initialization >>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>> method >>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>> concurrently? >>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>> >>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>> Summary: >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>> have raw >>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>> sections to >>>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>> GC isn't >>>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>> section is >>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>> fix is >>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>> machinery >>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>> debug >>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>> lazily >>>>>>>>>>>> computed count. >>>>>>>>>>>> >>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>> with many >>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>> than double >>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>> measurable >>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>> >>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>> ran the >>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>> >> From zhengyu.gu at oracle.com Thu Feb 2 08:11:36 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 02 Feb 2012 11:11:36 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err Message-ID: <4F2AB5B8.6000002@oracle.com> The cause of the problem is that decode acquires lock inside signal handler and generates assertion. The decoder is only used by error handler at this point, so it is safe to run without lock. Locking has many undesirable consequences under this scenario, besides signal handler issue, the error handler can be invoked when the thread is holding other locks, as David Holmes suggested. But it will also be used in upcoming native memory tracking code, which potentially can have multi-thread invoking decoder, so synchronization is needed. The proposed fix is to let error handler set decoder to single threaded mode, in which mode no lock is acquired. Please review Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ Thanks, -Zhengyu From keith.mcguigan at oracle.com Thu Feb 2 08:28:54 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 02 Feb 2012 11:28:54 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2AB5B8.6000002@oracle.com> References: <4F2AB5B8.6000002@oracle.com> Message-ID: <4F2AB9C6.3010801@oracle.com> On 2/2/2012 11:11 AM, Zhengyu Gu wrote: > Please review > Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ In Decoder::can_decode_C_frame_in_vm(), the 'single_threaded' variable is uninitialized. Instead of checking and rechecking that variable for lock/unlock, use the MutexLockerEx with NULL if you're single-threaded (if you can), i.e.: MutexLockerEx locker(_single_threaded ? _decoder_lock : NULL); It's simpler and safer. -- - Keith From tom.rodriguez at oracle.com Thu Feb 2 10:03:38 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Feb 2012 10:03:38 -0800 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F2A57ED.9050207@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> Message-ID: <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> >> >> First, I was not really arguing for doing this one way or the other. It >> was just not clear to me from the review comments if you wanted to >> change to javaTimeNanos() or not. >> >> You are right about the use in the GC code. We recently changed to use >> javaTimeNanos() for time intervals, but we use >> tty->timestamp().seconds() to print the time stamps. If I remember >> correctly, you were logging how long a thread had to wait, so it seemed >> like an interval to me. But, as I said, I was mostly just wondering what >> the decision was. >> >> It would probably be a good idea to use the same time source for time >> stamps and intervals. When we were using javaTimeMillis() I think it was >> consistent, but maybe we should now change to javaTimeNanos() for >> tty->timestamp()? >> >> I can't say I know the implications of changing tty->timestamp() to use >> the same timesource as javaTimeNanos(). Currently they boil down to the >> same OS calls on Windows, but on Linux and Solaris the implementations >> are quite different. > > The primary difference is that javaTimeMillis reports the time-of-day, while javaTimeNanos does not. If you really want a timestamp that you can correlate with other time-related events then javaTimeMillis is what you need, but then you have to deal with lower resolution and non-monotonicity. A compromise is a time-source with the resolution of nanoTime which is sync'ed to time-of-day at VM start (this is what the real-time clock gives you in the Real-Time Specification for Java). I think we should implement os::elapsed_counter in terms of javaTimeNanos and that would bring these sources into agreement. On Solaris they both use getTimeNanos, which is basically gethrtime. On linux elapsed_counter is gettimeofday and javaTimeNanos uses clock_gettime if it's supported. It looks like the sources just diverged and elapsed_counter was never updated. On windows it's also the same though the implementation equivalence is somewhat complicated. It might be most straightforward to move elapsed_counter into os.cpp and implement it in terms of javaTimeNanos. Is there any reason that javaTimeMillis shouldn't be implemented in terms of javaTimeNanos too? tom > > David > ----- > >> Bengt >> >> >> >> >> >> >> Bengt >> >>> >>> tom >>> >>>> Bengt >>>> >>>>> tom >>>>> >>>>>>> >>>>>>> gcLocker.hpp >>>>>>> >>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>> >>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>> it's NOT_DEBUG_RETURN. >>>>>> >>>>>>> >>>>>>> safepoint.cpp >>>>>>> >>>>>>> Not strictly related to your change, but the >>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>> level due to the the scoping that starts on line 139: >>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>> >>>>>> tom >>>>>> >>>>>>> 139 { >>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>> 141 >>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>> 143 _current_jni_active_count = 0; >>>>>>> >>>>>>> This scope ends at the end of the method: >>>>>>> >>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>> 401 } >>>>>>> 402 } >>>>>>> 403 } >>>>>>> >>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>> case, can we remove it? It would be nice to have the method >>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>> MutexLocker scope. >>>>>>> >>>>>>> Bengt >>>>>>> >>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>> Hi Tom, >>>>>>>> >>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>> Thanks Vladimir! >>>>>>>>>> >>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>> correctness of the new approach. >>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>> how it operates? >>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>> protocol seems safe. >>>>>>>> >>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>> >>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>> >>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>> that ok? >>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>> platforms and so not monotonic. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've updated the webrev. >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>> initialization >>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>> method >>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>> concurrently? >>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>> >>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>> Summary: >>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>> >>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>> have raw >>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>> sections to >>>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>> GC isn't >>>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>> section is >>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>> fix is >>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>> machinery >>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>> debug >>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>> lazily >>>>>>>>>>>> computed count. >>>>>>>>>>>> >>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>> with many >>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>> than double >>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>> measurable >>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>> >>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>> ran the >>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>> >> From keith.mcguigan at oracle.com Thu Feb 2 15:56:27 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Thu, 02 Feb 2012 18:56:27 -0500 Subject: Request for review: hotspot/jprt.properties [S] Message-ID: <4F2B22AB.2090807@oracle.com> Hello, Here's a webrev for changing the default JPRT release value for hotspot to jdk8. It can still be overridden by the -release jdk7 during JPRT submission. I also removed references to pre-7 releases and other unused value (jdk7b107, jdk7temp). The targets and parameters for jdk7 & jdk8 are identical for now, but it's probably good to keep the distinction in the file so we can update jdk8 targets independently as development continues. http://cr.openjdk.java.net/~kamg/7069991/webrev.00/ Thanks for any reviews. -- - Keith From paul.hohensee at oracle.com Thu Feb 2 16:42:41 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 02 Feb 2012 19:42:41 -0500 Subject: Request for review: hotspot/jprt.properties [S] In-Reply-To: <4F2B22AB.2090807@oracle.com> References: <4F2B22AB.2090807@oracle.com> Message-ID: <4F2B2D81.1020406@oracle.com> Looks good. Paul On 2/2/12 6:56 PM, Keith McGuigan wrote: > Hello, > > Here's a webrev for changing the default JPRT release value for > hotspot to jdk8. It can still be overridden by the -release jdk7 > during JPRT submission. I also removed references to pre-7 releases > and other unused value (jdk7b107, jdk7temp). > > The targets and parameters for jdk7 & jdk8 are identical for now, but > it's probably good to keep the distinction in the file so we can > update jdk8 targets independently as development continues. > > http://cr.openjdk.java.net/~kamg/7069991/webrev.00/ > > Thanks for any reviews. > > -- > - Keith From david.holmes at oracle.com Thu Feb 2 17:30:08 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 11:30:08 +1000 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> Message-ID: <4F2B38A0.2040801@oracle.com> On 3/02/2012 4:03 AM, Tom Rodriguez wrote: >>> First, I was not really arguing for doing this one way or the other. It >>> was just not clear to me from the review comments if you wanted to >>> change to javaTimeNanos() or not. >>> >>> You are right about the use in the GC code. We recently changed to use >>> javaTimeNanos() for time intervals, but we use >>> tty->timestamp().seconds() to print the time stamps. If I remember >>> correctly, you were logging how long a thread had to wait, so it seemed >>> like an interval to me. But, as I said, I was mostly just wondering what >>> the decision was. >>> >>> It would probably be a good idea to use the same time source for time >>> stamps and intervals. When we were using javaTimeMillis() I think it was >>> consistent, but maybe we should now change to javaTimeNanos() for >>> tty->timestamp()? >>> >>> I can't say I know the implications of changing tty->timestamp() to use >>> the same timesource as javaTimeNanos(). Currently they boil down to the >>> same OS calls on Windows, but on Linux and Solaris the implementations >>> are quite different. >> >> The primary difference is that javaTimeMillis reports the time-of-day, while javaTimeNanos does not. If you really want a timestamp that you can correlate with other time-related events then javaTimeMillis is what you need, but then you have to deal with lower resolution and non-monotonicity. A compromise is a time-source with the resolution of nanoTime which is sync'ed to time-of-day at VM start (this is what the real-time clock gives you in the Real-Time Specification for Java). > > I think we should implement os::elapsed_counter in terms of javaTimeNanos and that would bring these sources into agreement. On Solaris they both use getTimeNanos, which is basically gethrtime. On linux elapsed_counter is gettimeofday and javaTimeNanos uses clock_gettime if it's supported. It looks like the sources just diverged and elapsed_counter was never updated. On windows it's also the same though the implementation equivalence is somewhat complicated. It might be most straightforward to move elapsed_counter into os.cpp and implement it in terms of javaTimeNanos. Is there any reason that javaTimeMillis shouldn't be implemented in terms of javaTimeNanos too? Switching os::elapsed_counter to use javaTimeNanos on all platforms, in platform-independent code, would be a good thing in my opinion. Only problem as always is the backward compatibility issue. On Linux those numbers were timestamps and could be reconciled with timestamps produced by other sources - if we change them to javaTimeNanos then the correlation with system time is gone. javaTimeMillis _must_ be the time-of-day, that is what it is required to return. David ----- > tom > >> >> David >> ----- >> >>> Bengt >>> >>> >>> >>> >>> >>> >>> Bengt >>> >>>> >>>> tom >>>> >>>>> Bengt >>>>> >>>>>> tom >>>>>> >>>>>>>> >>>>>>>> gcLocker.hpp >>>>>>>> >>>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>>> >>>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>>> it's NOT_DEBUG_RETURN. >>>>>>> >>>>>>>> >>>>>>>> safepoint.cpp >>>>>>>> >>>>>>>> Not strictly related to your change, but the >>>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>>> level due to the the scoping that starts on line 139: >>>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>>> >>>>>>> tom >>>>>>> >>>>>>>> 139 { >>>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>>> 141 >>>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>>> 143 _current_jni_active_count = 0; >>>>>>>> >>>>>>>> This scope ends at the end of the method: >>>>>>>> >>>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>>> 401 } >>>>>>>> 402 } >>>>>>>> 403 } >>>>>>>> >>>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>>> case, can we remove it? It would be nice to have the method >>>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>>> MutexLocker scope. >>>>>>>> >>>>>>>> Bengt >>>>>>>> >>>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>>> Thanks Vladimir! >>>>>>>>>>> >>>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>>> correctness of the new approach. >>>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>>> how it operates? >>>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>>> protocol seems safe. >>>>>>>>> >>>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>>> >>>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>>> >>>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>>> that ok? >>>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>>> platforms and so not monotonic. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've updated the webrev. >>>>>>>>>> >>>>>>>>>> tom >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>>> initialization >>>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>>> method >>>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>>> concurrently? >>>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>>> >>>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>>> Summary: >>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>> >>>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>>> have raw >>>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>>> sections to >>>>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>>> GC isn't >>>>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>>> section is >>>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>>> fix is >>>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>>> machinery >>>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>>> debug >>>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>>> lazily >>>>>>>>>>>>> computed count. >>>>>>>>>>>>> >>>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>>> with many >>>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>>> than double >>>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>>> measurable >>>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>>> >>>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>>> ran the >>>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>>> >>> > From david.holmes at oracle.com Thu Feb 2 17:39:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 11:39:57 +1000 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F2B38A0.2040801@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> <4F2B38A0.2040801@oracle.com> Message-ID: <4F2B3AED.5010105@oracle.com> On 3/02/2012 11:30 AM, David Holmes wrote: > On 3/02/2012 4:03 AM, Tom Rodriguez wrote: >>> >>> The primary difference is that javaTimeMillis reports the >>> time-of-day, while javaTimeNanos does not. If you really want a >>> timestamp that you can correlate with other time-related events then >>> javaTimeMillis is what you need, but then you have to deal with lower >>> resolution and non-monotonicity. A compromise is a time-source with >>> the resolution of nanoTime which is sync'ed to time-of-day at VM >>> start (this is what the real-time clock gives you in the Real-Time >>> Specification for Java). >> >> I think we should implement os::elapsed_counter in terms of >> javaTimeNanos and that would bring these sources into agreement. On >> Solaris they both use getTimeNanos, which is basically gethrtime. On >> linux elapsed_counter is gettimeofday and javaTimeNanos uses >> clock_gettime if it's supported. It looks like the sources just >> diverged and elapsed_counter was never updated. On windows it's also >> the same though the implementation equivalence is somewhat >> complicated. It might be most straightforward to move elapsed_counter >> into os.cpp and implement it in terms of javaTimeNanos. Is there any >> reason that javaTimeMillis shouldn't be implemented in terms of >> javaTimeNanos too? > > Switching os::elapsed_counter to use javaTimeNanos on all platforms, in > platform-independent code, would be a good thing in my opinion. Only > problem as always is the backward compatibility issue. On Linux those > numbers were timestamps and could be reconciled with timestamps produced > by other sources - if we change them to javaTimeNanos then the > correlation with system time is gone. Also see 6523968 for a related issue with elapsed_counter on Linux. These underlying API's are quite extensively used by higher-level API's. David > javaTimeMillis _must_ be the time-of-day, that is what it is required to > return. > > David > ----- > >> tom >> >>> >>> David >>> ----- >>> >>>> Bengt >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bengt >>>> >>>>> >>>>> tom >>>>> >>>>>> Bengt >>>>>> >>>>>>> tom >>>>>>> >>>>>>>>> >>>>>>>>> gcLocker.hpp >>>>>>>>> >>>>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>>>> >>>>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>>>> it's NOT_DEBUG_RETURN. >>>>>>>> >>>>>>>>> >>>>>>>>> safepoint.cpp >>>>>>>>> >>>>>>>>> Not strictly related to your change, but the >>>>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>>>> level due to the the scoping that starts on line 139: >>>>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> 139 { >>>>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>>>> 141 >>>>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>>>> 143 _current_jni_active_count = 0; >>>>>>>>> >>>>>>>>> This scope ends at the end of the method: >>>>>>>>> >>>>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>>>> 401 } >>>>>>>>> 402 } >>>>>>>>> 403 } >>>>>>>>> >>>>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>>>> case, can we remove it? It would be nice to have the method >>>>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>>>> MutexLocker scope. >>>>>>>>> >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>>>> Thanks Vladimir! >>>>>>>>>>>> >>>>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>>>> correctness of the new approach. >>>>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>>>> how it operates? >>>>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>>>> protocol seems safe. >>>>>>>>>> >>>>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>>>> >>>>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>>>> >>>>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>>>> here? Use of this was recently changed elsewhere in the GC >>>>>>>>>>>> code. >>>>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>>>> that ok? >>>>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>>>> platforms and so not monotonic. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I've updated the webrev. >>>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>>>> initialization >>>>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>>>> method >>>>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>>>> concurrently? >>>>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>>>> Summary: >>>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>>>> have raw >>>>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>>>> sections to >>>>>>>>>>>>>> drain before creating new ones so that a GC can occur. >>>>>>>>>>>>>> Currently >>>>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>>>> GC isn't >>>>>>>>>>>>>> being requested. This creates scalability problem when a >>>>>>>>>>>>>> lot of >>>>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>>>> section is >>>>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>>>> fix is >>>>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>>>> machinery >>>>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>>>> debug >>>>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>>>> lazily >>>>>>>>>>>>>> computed count. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>>>> with many >>>>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>>>> than double >>>>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>>>> measurable >>>>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>>>> ran the >>>>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>>>> >>>> >> From david.holmes at oracle.com Thu Feb 2 18:01:01 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 12:01:01 +1000 Subject: Request for review: hotspot/jprt.properties [S] In-Reply-To: <4F2B22AB.2090807@oracle.com> References: <4F2B22AB.2090807@oracle.com> Message-ID: <4F2B3FDD.50104@oracle.com> Hi Keith, On 3/02/2012 9:56 AM, Keith McGuigan wrote: > Here's a webrev for changing the default JPRT release value for hotspot > to jdk8. It can still be overridden by the -release jdk7 during JPRT > submission. I also removed references to pre-7 releases and other unused > value (jdk7b107, jdk7temp). Are we sure there is no reason to leave any pre-7 release info here? Otherwise changes seem okay. David > The targets and parameters for jdk7 & jdk8 are identical for now, but > it's probably good to keep the distinction in the file so we can update > jdk8 targets independently as development continues. > > http://cr.openjdk.java.net/~kamg/7069991/webrev.00/ > > Thanks for any reviews. > > -- > - Keith From tom.rodriguez at oracle.com Thu Feb 2 18:32:58 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 2 Feb 2012 18:32:58 -0800 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <4F2B38A0.2040801@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> <4F2B38A0.2040801@oracle.com> Message-ID: <3BE0A740-B387-4016-BE9A-1FC4788D66BE@oracle.com> >> >> I think we should implement os::elapsed_counter in terms of javaTimeNanos and that would bring these sources into agreement. On Solaris they both use getTimeNanos, which is basically gethrtime. On linux elapsed_counter is gettimeofday and javaTimeNanos uses clock_gettime if it's supported. It looks like the sources just diverged and elapsed_counter was never updated. On windows it's also the same though the implementation equivalence is somewhat complicated. It might be most straightforward to move elapsed_counter into os.cpp and implement it in terms of javaTimeNanos. Is there any reason that javaTimeMillis shouldn't be implemented in terms of javaTimeNanos too? > > Switching os::elapsed_counter to use javaTimeNanos on all platforms, in platform-independent code, would be a good thing in my opinion. Only problem as always is the backward compatibility issue. On Linux those numbers were timestamps and could be reconciled with timestamps produced by other sources - if we change them to javaTimeNanos then the correlation with system time is gone. elapsed_counter is always the delta since the start of the JVM so there really isn't an exposed way to turn them into wall clock times. > > javaTimeMillis _must_ be the time-of-day, that is what it is required to return. Ah, right. tom > > David > ----- > >> tom >> >>> >>> David >>> ----- >>> >>>> Bengt >>>> >>>> >>>> >>>> >>>> >>>> >>>> Bengt >>>> >>>>> >>>>> tom >>>>> >>>>>> Bengt >>>>>> >>>>>>> tom >>>>>>> >>>>>>>>> >>>>>>>>> gcLocker.hpp >>>>>>>>> >>>>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>>>> >>>>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>>>> it's NOT_DEBUG_RETURN. >>>>>>>> >>>>>>>>> >>>>>>>>> safepoint.cpp >>>>>>>>> >>>>>>>>> Not strictly related to your change, but the >>>>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>>>> level due to the the scoping that starts on line 139: >>>>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>> 139 { >>>>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>>>> 141 >>>>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>>>> 143 _current_jni_active_count = 0; >>>>>>>>> >>>>>>>>> This scope ends at the end of the method: >>>>>>>>> >>>>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>>>> 401 } >>>>>>>>> 402 } >>>>>>>>> 403 } >>>>>>>>> >>>>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>>>> case, can we remove it? It would be nice to have the method >>>>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>>>> MutexLocker scope. >>>>>>>>> >>>>>>>>> Bengt >>>>>>>>> >>>>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>>>> Thanks Vladimir! >>>>>>>>>>>> >>>>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>>>> correctness of the new approach. >>>>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>>>> how it operates? >>>>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>>>> protocol seems safe. >>>>>>>>>> >>>>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>>>> >>>>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>>>> >>>>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>>>> that ok? >>>>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>>>> platforms and so not monotonic. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I've updated the webrev. >>>>>>>>>>> >>>>>>>>>>> tom >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>>>> initialization >>>>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>>>> method >>>>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>>>> concurrently? >>>>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>>>> Summary: >>>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>>>> have raw >>>>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>>>> sections to >>>>>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>>>> GC isn't >>>>>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>>>> section is >>>>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>>>> fix is >>>>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>>>> machinery >>>>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>>>> debug >>>>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>>>> lazily >>>>>>>>>>>>>> computed count. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>>>> with many >>>>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>>>> than double >>>>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>>>> measurable >>>>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>>>> ran the >>>>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>>>> >>>> >> From david.holmes at oracle.com Thu Feb 2 18:43:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 12:43:44 +1000 Subject: review for 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale In-Reply-To: <3BE0A740-B387-4016-BE9A-1FC4788D66BE@oracle.com> References: <4DDD98EA-07C9-44D9-AF7E-C938E086C6FC@oracle.com> <4F22FA22.3000106@oracle.com> <4F25DC17.60309@oracle.com> <4F25FFC1.5020904@oracle.com> <4F266D93.9080308@oracle.com> <76326728-2D3E-4690-8F32-F6C79189B6CC@oracle.com> <359A5416-4618-44C9-8588-1C2BEC55A6CC@oracle.com> <4F27A26E.5020803@oracle.com> <4F2A4DFF.1010809@oracle.com> <4F2A57ED.9050207@oracle.com> <7BBA6D48-418C-4A8F-9223-4543F5764C29@oracle.com> <4F2B38A0.2040801@oracle.com> <3BE0A740-B387-4016-BE9A-1FC4788D66BE@oracle.com> Message-ID: <4F2B49E0.1050802@oracle.com> On 3/02/2012 12:32 PM, Tom Rodriguez wrote: >>> >>> I think we should implement os::elapsed_counter in terms of javaTimeNanos and that would bring these sources into agreement. On Solaris they both use getTimeNanos, which is basically gethrtime. On linux elapsed_counter is gettimeofday and javaTimeNanos uses clock_gettime if it's supported. It looks like the sources just diverged and elapsed_counter was never updated. On windows it's also the same though the implementation equivalence is somewhat complicated. It might be most straightforward to move elapsed_counter into os.cpp and implement it in terms of javaTimeNanos. Is there any reason that javaTimeMillis shouldn't be implemented in terms of javaTimeNanos too? >> >> Switching os::elapsed_counter to use javaTimeNanos on all platforms, in platform-independent code, would be a good thing in my opinion. Only problem as always is the backward compatibility issue. On Linux those numbers were timestamps and could be reconciled with timestamps produced by other sources - if we change them to javaTimeNanos then the correlation with system time is gone. > > elapsed_counter is always the delta since the start of the JVM so there really isn't an exposed way to turn them into wall clock times. Well there are ways because there is a way to ask for the VM start time through the M&M interface. But no in general elapsed_counter should always be a delta. I'm unclear what the TimeStamp class is actually presenting when it is used? Anyway if this is changed we should make sure we know all of the clients of this code. Thanks, David >> >> javaTimeMillis _must_ be the time-of-day, that is what it is required to return. > > Ah, right. > > tom > >> >> David >> ----- >> >>> tom >>> >>>> >>>> David >>>> ----- >>>> >>>>> Bengt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Bengt >>>>> >>>>>> >>>>>> tom >>>>>> >>>>>>> Bengt >>>>>>> >>>>>>>> tom >>>>>>>> >>>>>>>>>> >>>>>>>>>> gcLocker.hpp >>>>>>>>>> >>>>>>>>>> 84 static void verify_critical_count() NOT_DEBUG_RETURN; >>>>>>>>>> >>>>>>>>>> Not sure what the correct thing is here, but the GC code seems to >>>>>>>>>> use PRODUCT_RETURN more than NOT_DEBUG_RETURN. I guess the only >>>>>>>>>> difference is for optimized builds (and of course using #ifndef >>>>>>>>>> PRODUCT instead of #ifdef ASSERT). >>>>>>>>> I didn't want it doing any work in optimized builds so that's why >>>>>>>>> it's NOT_DEBUG_RETURN. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> safepoint.cpp >>>>>>>>>> >>>>>>>>>> Not strictly related to your change, but the >>>>>>>>>> SafepointSynchronize::begin() method is missing one indentation >>>>>>>>>> level due to the the scoping that starts on line 139: >>>>>>>>> Yes, I noticed that too. The whole thing could be factored better >>>>>>>>> too. I already pushed so I can't fix it. I've got another change >>>>>>>>> coming so maybe I'll fix it in there. Thanks. >>>>>>>>> >>>>>>>>> tom >>>>>>>>> >>>>>>>>>> 139 { >>>>>>>>>> 140 MutexLocker mu(Safepoint_lock); >>>>>>>>>> 141 >>>>>>>>>> 142 // Reset the count of active JNI critical threads >>>>>>>>>> 143 _current_jni_active_count = 0; >>>>>>>>>> >>>>>>>>>> This scope ends at the end of the method: >>>>>>>>>> >>>>>>>>>> 398 if (PrintSafepointStatistics) { >>>>>>>>>> 399 // Record how much time spend on the above cleanup tasks >>>>>>>>>> 400 update_statistics_on_cleanup_end(os::javaTimeNanos()); >>>>>>>>>> 401 } >>>>>>>>>> 402 } >>>>>>>>>> 403 } >>>>>>>>>> >>>>>>>>>> It seems to me that the scope is not really necessary. In that >>>>>>>>>> case, can we remove it? It would be nice to have the method >>>>>>>>>> correctly indented. If we decide to keep the scope I'd prefer a >>>>>>>>>> comment on line 402, to indicate that it is the end of the >>>>>>>>>> MutexLocker scope. >>>>>>>>>> >>>>>>>>>> Bengt >>>>>>>>>> >>>>>>>>>> On 2012-01-30 03:26, David Holmes wrote: >>>>>>>>>>> Hi Tom, >>>>>>>>>>> >>>>>>>>>>> On 30/01/2012 10:30 AM, Tom Rodriguez wrote: >>>>>>>>>>>> On Jan 29, 2012, at 3:53 PM, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 28/01/2012 5:25 AM, Vladimir Kozlov wrote: >>>>>>>>>>>>>> I change alias to hotspot-dev since it affects everyone. >>>>>>>>>>>>> Thanks Vladimir! >>>>>>>>>>>>> >>>>>>>>>>>>> Overall I find it difficult to follow the protocol that applies >>>>>>>>>>>>> here - in particular how safepoints can and can not appear >>>>>>>>>>>>> between different methods and the way in which needs_gc() might >>>>>>>>>>>>> change value between the enter and exit of a critical region. >>>>>>>>>>>>> Without that understanding it is hard to evaluate the >>>>>>>>>>>>> correctness of the new approach. >>>>>>>>>>>> I tried to put in enough asserts to ensure that it was clear >>>>>>>>>>>> what invariants are in force when updating the state. Safepoints >>>>>>>>>>>> can appear wherever they normally can appear, while locking and >>>>>>>>>>>> waiting on mutexes. _needs_gc can only change from false to true >>>>>>>>>>>> during a safepoint. For the most part everything operates >>>>>>>>>>>> exactly as it used to once _needs_gc is set and the only trick >>>>>>>>>>>> is computing the correct value of _jni_active_count when setting >>>>>>>>>>>> _needs_gc to be true. The debug code that still performs the >>>>>>>>>>>> atomics attempts to verify that the computed value and actual >>>>>>>>>>>> value are in sync. Is there any more that I can explain about >>>>>>>>>>>> how it operates? >>>>>>>>>>> It's my ignorance of the overall operation that makes evaluating >>>>>>>>>>> this change difficult for me. But thanks to your side-band emails >>>>>>>>>>> I now have a much clear understanding of things - thanks. And the >>>>>>>>>>> protocol seems safe. >>>>>>>>>>> >>>>>>>>>>>>> src/share/vm/memory/gcLocker.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> 72 _wait_begin = os::javaTimeMillis(); >>>>>>>>>>>>> 135 os::javaTimeMillis() - _wait_begin, >>>>>>>>>>>>> >>>>>>>>>>>>> Are you sure you want to use the non-monotonic javaTimeMillis >>>>>>>>>>>>> here? Use of this was recently changed elsewhere in the GC code. >>>>>>>>>>>> It's only printing code, but I'll switch it to use >>>>>>>>>>>> tty->timestamp().milliseconds() which will make it match our >>>>>>>>>>>> internal time stamps, which seems like a useful property. Is >>>>>>>>>>>> that ok? >>>>>>>>>>> The recent GC changes switched to using javaTimeNanos() converted >>>>>>>>>>> to millis - see 7117303 and 7129514. The TimeStamp is based on >>>>>>>>>>> elapsedCounter which is still a time-of-day source on some >>>>>>>>>>> platforms and so not monotonic. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> I've updated the webrev. >>>>>>>>>>>> >>>>>>>>>>>> tom >>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> In GC_locker::check_active_before_gc() move wait_begin >>>>>>>>>>>>>> initialization >>>>>>>>>>>>>> under Print* check since it used only under such checks. Could >>>>>>>>>>>>>> method >>>>>>>>>>>>>> check_active_before_gc() be called from different threads >>>>>>>>>>>>>> concurrently? >>>>>>>>>>>>>> Does it need lock? Note that other methods have lock. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~never/7129164 >>>>>>>>>>>>>>> 200 lines changed: 126 ins; 33 del; 41 mod; 3958 unchg >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale >>>>>>>>>>>>>>> Summary: >>>>>>>>>>>>>>> Reviewed-by: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The machinery for GC_locker which supports >>>>>>>>>>>>>>> GetPrimitiveArrayCritical >>>>>>>>>>>>>>> maintains a count of the number of threads that currently >>>>>>>>>>>>>>> have raw >>>>>>>>>>>>>>> pointers exposed. This is used to allow existing critical >>>>>>>>>>>>>>> sections to >>>>>>>>>>>>>>> drain before creating new ones so that a GC can occur. Currently >>>>>>>>>>>>>>> these counts are updated using atomic all the time, even if a >>>>>>>>>>>>>>> GC isn't >>>>>>>>>>>>>>> being requested. This creates scalability problem when a lot of >>>>>>>>>>>>>>> threads are hammering atomic operations on the >>>>>>>>>>>>>>> jni_lock_count. The >>>>>>>>>>>>>>> count only needs to be valid when checking if a critical >>>>>>>>>>>>>>> section is >>>>>>>>>>>>>>> currently active and when draining the existing sections. The >>>>>>>>>>>>>>> fix is >>>>>>>>>>>>>>> to make the count be computed as part of the safepointing >>>>>>>>>>>>>>> machinery >>>>>>>>>>>>>>> and to only decrement the counters when _needs_gc is true. In >>>>>>>>>>>>>>> debug >>>>>>>>>>>>>>> mode the old count is maintained and validated against the >>>>>>>>>>>>>>> lazily >>>>>>>>>>>>>>> computed count. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On a microbenchmark that stresses GetPrimitiveArrayCritical >>>>>>>>>>>>>>> with many >>>>>>>>>>>>>>> threads and relatively short critical section it can more >>>>>>>>>>>>>>> than double >>>>>>>>>>>>>>> the throughput. This also slightly speeds up the normal >>>>>>>>>>>>>>> GetPrimtiveArrayCritical calls. Mostly it's not easily >>>>>>>>>>>>>>> measurable >>>>>>>>>>>>>>> with larger scale programs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tested with microbenchmark that stresses >>>>>>>>>>>>>>> GetPrimtiveArrayCritical and >>>>>>>>>>>>>>> the crypto benchmarks of specjvm2008 on x86 and sparc. I also >>>>>>>>>>>>>>> ran the >>>>>>>>>>>>>>> java.io regression tests from the JDK. >>>>>>>>>>>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Feb 2 19:03:15 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Feb 2012 13:03:15 +1000 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2AB5B8.6000002@oracle.com> References: <4F2AB5B8.6000002@oracle.com> Message-ID: <4F2B4E73.2010904@oracle.com> On 3/02/2012 2:11 AM, Zhengyu Gu wrote: > The cause of the problem is that decode acquires lock inside signal > handler and generates assertion. > > The decoder is only used by error handler at this point, so it is safe > to run without lock. Locking has many undesirable consequences under > this scenario, besides signal handler issue, the error handler can be > invoked when the thread is holding other locks, as David Holmes suggested. > > But it will also be used in upcoming native memory tracking code, which > potentially can have multi-thread invoking decoder, so synchronization > is needed. > > The proposed fix is to let error handler set decoder to single threaded > mode, in which mode no lock is acquired. The comment here: 803 // This should be the only running thread, decoder can safely run in 804 // single threaded mode without acquiring lock 805 Decoder::set_single_threaded(true); 806 807 jlong mytid = os::current_thread_id(); 808 if (first_error == NULL && 809 Atomic::cmpxchg_ptr(this, &first_error, NULL) == NULL) { 810 811 // first time 812 first_error_tid = mytid; 813 set_error_reported(); isn't quite correct as at this stage you can have multiple threads trying to do report_and_die(). So at least move it inside the if block. Later when there are multiple users of the Decoder I don't know how you will fix this because those other users can run concurrently with report_and_die(). That said I'm unclear what it is about the Decoder that requires locking - what state does it maintain? Is there a reason not to create a Decoder only when needed? --- In decoder.cpp you can still use MutexLockerEx and as it will take a null mutex and just act as a no-op eg: MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); Cheers, David ----- > > Please review > Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ > > > Thanks, > > -Zhengyu > From john.coomes at oracle.com Thu Feb 2 20:32:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:32:15 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b24 for changeset 1a5f1d6b98d6 Message-ID: <20120203043215.7F65C47326@hg.openjdk.java.net> Changeset: 5350cd6e0cc0 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5350cd6e0cc0 Added tag jdk8-b24 for changeset 1a5f1d6b98d6 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:32:21 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:32:21 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b24 for changeset b98f0e6dddf9 Message-ID: <20120203043224.C341547327@hg.openjdk.java.net> Changeset: e45d6b406d5f Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/e45d6b406d5f Added tag jdk8-b24 for changeset b98f0e6dddf9 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:32:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:32:31 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b24 for changeset 7836655e2495 Message-ID: <20120203043231.8946F47328@hg.openjdk.java.net> Changeset: bb694c151fc7 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/bb694c151fc7 Added tag jdk8-b24 for changeset 7836655e2495 ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:32:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:32:38 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b24 for changeset e0d90803439b Message-ID: <20120203043238.4790247329@hg.openjdk.java.net> Changeset: b376d901e006 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/b376d901e006 Added tag jdk8-b24 for changeset e0d90803439b ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:32:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:32:47 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b24 for changeset 34029a0c69bb Message-ID: <20120203043321.6A7CC4732A@hg.openjdk.java.net> Changeset: 8da468cf037b Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8da468cf037b Added tag jdk8-b24 for changeset 34029a0c69bb ! .hgtags From john.coomes at oracle.com Thu Feb 2 20:34:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 03 Feb 2012 04:34:37 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b24 for changeset 6c9d21ca92c4 Message-ID: <20120203043443.76D044732B@hg.openjdk.java.net> Changeset: 5a784dab75f1 Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/5a784dab75f1 Added tag jdk8-b24 for changeset 6c9d21ca92c4 ! .hgtags From keith.mcguigan at oracle.com Fri Feb 3 03:55:37 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 03 Feb 2012 06:55:37 -0500 Subject: Request for review: hotspot/jprt.properties [S] In-Reply-To: <4F2B3FDD.50104@oracle.com> References: <4F2B22AB.2090807@oracle.com> <4F2B3FDD.50104@oracle.com> Message-ID: <4F2BCB39.60806@oracle.com> On 2/2/2012 9:01 PM, David Holmes wrote: > On 3/02/2012 9:56 AM, Keith McGuigan wrote: >> Here's a webrev for changing the default JPRT release value for hotspot >> to jdk8. It can still be overridden by the -release jdk7 during JPRT >> submission. I also removed references to pre-7 releases and other unused >> value (jdk7b107, jdk7temp). > > Are we sure there is no reason to leave any pre-7 release info here? As far as I know, hsx will be used only for jdk7 & jdk8 releases, anything pre-7 has it's own separate hotspot repository (or it will, if needed). -- - Keith From paul.hohensee at oracle.com Fri Feb 3 07:58:47 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 03 Feb 2012 10:58:47 -0500 Subject: Request for review: hotspot/jprt.properties [S] In-Reply-To: <4F2BCB39.60806@oracle.com> References: <4F2B22AB.2090807@oracle.com> <4F2B3FDD.50104@oracle.com> <4F2BCB39.60806@oracle.com> Message-ID: <4F2C0437.90104@oracle.com> Correct. Sustaining owns the pre-7 releases. Paul On 2/3/12 6:55 AM, Keith McGuigan wrote: > > > On 2/2/2012 9:01 PM, David Holmes wrote: >> On 3/02/2012 9:56 AM, Keith McGuigan wrote: >>> Here's a webrev for changing the default JPRT release value for hotspot >>> to jdk8. It can still be overridden by the -release jdk7 during JPRT >>> submission. I also removed references to pre-7 releases and other >>> unused >>> value (jdk7b107, jdk7temp). >> >> Are we sure there is no reason to leave any pre-7 release info here? > > As far as I know, hsx will be used only for jdk7 & jdk8 releases, > anything pre-7 has it's own separate hotspot repository (or it will, > if needed). > > -- > - Keith > From zhengyu.gu at oracle.com Fri Feb 3 14:12:24 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Fri, 03 Feb 2012 17:12:24 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2B4E73.2010904@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> Message-ID: <4F2C5BC8.4070303@oracle.com> Hi David, Thanks for reviewing. I think I made wrong assumption that the thread is the last running thread. 803 // This should be the only running thread, decoder can safely run in 804 // single threaded mode without acquiring lock 805 Decoder::set_single_threaded(true); 806 To avoid locking in error handler, the only solution I can think of, is to have its own private decoder. Please see revised webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ > Later when there are multiple users of the Decoder I don't know how > you will fix this because those other users can run concurrently with > report_and_die(). That said I'm unclear what it is about the Decoder > that requires locking - what state does it maintain? Is there a reason > not to create a Decoder only when needed? > Decoder is created on demand, but would prefer to be shared, since it can consume noticeable amount memory on Unix platform, by loading Elf files' symbol tables and string tables into memory (not impact on Windows). The lock is needed to protect a linked list structure in Elf decoder, or current file position. Thanks, -Zhengyu > --- > > In decoder.cpp you can still use MutexLockerEx and as it will take a > null mutex and just act as a no-op eg: > > MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); > > Cheers, > David > ----- > >> >> Please review >> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu >> From vitalyd at gmail.com Fri Feb 3 14:42:09 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 Feb 2012 17:42:09 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2C5BC8.4070303@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> Message-ID: How about an instance/non-static decoder which when needing to do symbol loading obtains a static lock (or semaphore if more than 1 is OK) before loading symbols and then releases it once the memory is freed? Not pretty but allows decoder to have its own state (whether locking is needed) but have global control on how many of them can do the expensive operation. Maybe have separate impl for elf vs windows where windows impl doesn't acquire any locks. Sent from my phone On Feb 3, 2012 5:13 PM, "Zhengyu Gu" wrote: > Hi David, > > Thanks for reviewing. I think I made wrong assumption that the thread is > the last running thread. > > 803 // This should be the only running thread, decoder can safely run in > 804 // single threaded mode without acquiring lock > 805 Decoder::set_single_threaded(**true); > 806 > > To avoid locking in error handler, the only solution I can think of, is to > have its own private decoder. > > Please see revised webrev: http://cr.openjdk.java.net/~** > zgu/7141259/webrev.01/ > > Later when there are multiple users of the Decoder I don't know how you >> will fix this because those other users can run concurrently with >> report_and_die(). That said I'm unclear what it is about the Decoder that >> requires locking - what state does it maintain? Is there a reason not to >> create a Decoder only when needed? >> >> Decoder is created on demand, but would prefer to be shared, since it > can consume noticeable amount memory on Unix platform, by loading Elf > files' symbol tables and string tables into memory (not impact on Windows). > The lock is needed to protect a linked list structure in Elf decoder, or > current file position. > > Thanks, > > -Zhengyu > >> --- >> >> In decoder.cpp you can still use MutexLockerEx and as it will take a null >> mutex and just act as a no-op eg: >> >> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >> >> Cheers, >> David >> ----- >> >> >>> Please review >>> Webrev: http://cr.openjdk.java.net/~**zgu/7141259/webrev.00/ >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120203/ed106f4e/attachment.html From frederic.parain at oracle.com Fri Feb 3 15:26:20 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Fri, 03 Feb 2012 23:26:20 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20120203232634.1E93A47361@hg.openjdk.java.net> Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d96c130c9399 Merge Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp From john.coomes at oracle.com Fri Feb 3 17:45:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 04 Feb 2012 01:45:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20120204014553.6D74D47362@hg.openjdk.java.net> Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp From john.coomes at oracle.com Fri Feb 3 20:05:53 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 04 Feb 2012 04:05:53 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20120204040603.9A77A47365@hg.openjdk.java.net> Changeset: be649fefcdc2 Author: stefank Date: 2012-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be649fefcdc2 7134655: Crash in reference processing when doing single-threaded remarking Summary: Temporarily disabled multi-threaded reference discovery when entering a single-threaded remark phase. Reviewed-by: brutisso, tonyp, jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c03e06373b47 Author: stefank Date: 2012-01-28 01:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c03e06373b47 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: 2eeebe4b4213 Author: brutisso Date: 2012-01-30 15:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2eeebe4b4213 7140909: Visual Studio project builds broken: need to define INCLUDE_TRACE Summary: Add define of INCLUDE_TRACE Reviewed-by: sla, kamg ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5ab44ceb4d57 Merge From john.coomes at oracle.com Fri Feb 3 22:41:13 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 04 Feb 2012 06:41:13 +0000 Subject: hg: hsx/hsx23/hotspot: 25 new changesets Message-ID: <20120204064204.0AE904736A@hg.openjdk.java.net> Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: 9f1c2b7cdfb6 Author: amurillo Date: 2012-01-27 14:49 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/9f1c2b7cdfb6 7135385: new hotspot build - hs23-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 34e2e90e7182 Author: rbackman Date: 2012-01-24 14:48 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/34e2e90e7182 7130476: Remove use of #ifdef TRACE_DEFINE_KLASS_TRACE_ID from klass.hpp Reviewed-by: kamg, phh, dsamersoff Contributed-by: Rickard Backman ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/trace/traceMacros.hpp Changeset: 26a08cbbf042 Author: stefank Date: 2012-01-27 13:46 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/26a08cbbf042 7022100: Method annotations are incorrectly set when redefining classes Summary: Changed to the correct annotation arrays Reviewed-by: kamg, dholmes, sla ! src/share/vm/oops/instanceKlass.hpp Changeset: f457154eee8b Author: brutisso Date: 2012-01-30 12:36 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f457154eee8b 7140882: Don't return booleans from methods returning pointers Summary: Changed "return false" to "return NULL" Reviewed-by: dholmes, rottenha Contributed-by: dbhole at redhat.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/loopnode.cpp Changeset: d96c130c9399 Author: brutisso Date: 2012-01-30 05:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d96c130c9399 Merge Changeset: b2cd0ee8f778 Author: acorn Date: 2012-01-30 23:27 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b2cd0ee8f778 7114376: Make system dictionary hashtable bucket array size configurable Summary: 7u4 new experimental flag -XX:PredictedClassLoadedCount=# Reviewed-by: dholmes, phh, dcubed ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: 481a9443f721 Author: phh Date: 2012-02-01 15:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/481a9443f721 7123386: RFE: Preserve universal builds of HotSpot on Mac OS X Summary: Add support for packaging HotSpot JVM builds in universal binaries Reviewed-by: dholmes, kamg, dcubed, phh Contributed-by: james.melvin at oracle.com ! make/Makefile ! make/bsd/makefiles/defs.make + make/bsd/makefiles/universal.gmk ! make/defs.make Changeset: 527cf36f4a20 Author: fparain Date: 2012-02-03 14:04 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/527cf36f4a20 Merge ! src/share/vm/runtime/globals.hpp Changeset: 1a2723f7ad8e Author: never Date: 2012-01-29 16:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1a2723f7ad8e 7129164: JNI Get/ReleasePrimitiveArrayCritical doesn't scale Reviewed-by: kvn, iveresov, dholmes ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/thread.hpp Changeset: 5f17b16b3219 Author: iveresov Date: 2012-01-30 19:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5f17b16b3219 7141059: 7116795 broke pure c2 builds Summary: Fix pure c2 builds Reviewed-by: kvn, brutisso, never ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ed8f599a788 Author: kvn Date: 2012-01-31 07:18 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5ed8f599a788 7140924: SIGSEGV in compiled code for sun.awt.X11.XDecoratedPeer.updateMinSizeHints Summary: Use unknown_obj instead of empty_map for NULL or Constant Pool object constants in bytecode Escape Analyzer. Reviewed-by: iveresov, never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 2f5980b127e3 Author: twisti Date: 2012-01-31 09:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2f5980b127e3 7132180: JSR 292: C1 JVM crash with ClassValue/MethodHandle Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f067b4e0e04b Author: roland Date: 2012-02-01 10:36 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f067b4e0e04b 7090976: Eclipse/CDT causes a JVM crash while indexing C++ code Summary: too optimistic inlining decision confuses local value numbering. Reviewed-by: never ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.cpp + test/compiler/7090976/Test7090976.java Changeset: aa3d708d67c4 Author: never Date: 2012-02-01 07:59 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/aa3d708d67c4 7141200: log some interesting information in ring buffers for crashes Reviewed-by: kvn, jrose, kevinw, brutisso, twisti, jmasa ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 0382d2b469b2 Author: never Date: 2012-02-01 16:57 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/0382d2b469b2 7013347: allow crypto functions to be called inline to enhance performance Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/nativeLookup.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 392a3f07d567 Author: twisti Date: 2012-02-02 09:14 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/392a3f07d567 7141637: JSR 292: MH spread invoker crashes with NULL argument on x86_32 Reviewed-by: twisti Contributed-by: Volker Simonis ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/7141637/SpreadNullArg.java Changeset: 379b22e03c32 Author: jcoomes Date: 2012-02-03 12:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/379b22e03c32 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: be649fefcdc2 Author: stefank Date: 2012-01-27 14:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/be649fefcdc2 7134655: Crash in reference processing when doing single-threaded remarking Summary: Temporarily disabled multi-threaded reference discovery when entering a single-threaded remark phase. Reviewed-by: brutisso, tonyp, jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c03e06373b47 Author: stefank Date: 2012-01-28 01:15 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c03e06373b47 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: 2eeebe4b4213 Author: brutisso Date: 2012-01-30 15:21 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2eeebe4b4213 7140909: Visual Studio project builds broken: need to define INCLUDE_TRACE Summary: Add define of INCLUDE_TRACE Reviewed-by: sla, kamg ! src/share/tools/ProjectCreator/BuildConfig.java Changeset: 24cae3e4cbaa Author: jcoomes Date: 2012-02-02 16:05 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/24cae3e4cbaa 6679764: enable parallel compaction by default Reviewed-by: phh, jmasa ! src/share/vm/runtime/arguments.cpp Changeset: 5ab44ceb4d57 Author: jcoomes Date: 2012-02-03 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5ab44ceb4d57 Merge Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags From zhengyu.gu at oracle.com Sat Feb 4 03:49:49 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Sat, 4 Feb 2012 06:49:49 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> Message-ID: <9E38C5A7-BFFE-401E-AC75-97E50FC449D7@oracle.com> But it does not solve the problem that lock can be acquired in signal handler. -Zhengyu On Feb 3, 2012, at 5:42 PM, Vitaly Davidovich wrote: > How about an instance/non-static decoder which when needing to do symbol loading obtains a static lock (or semaphore if more than 1 is OK) before loading symbols and then releases it once the memory is freed? Not pretty but allows decoder to have its own state (whether locking is needed) but have global control on how many of them can do the expensive operation. Maybe have separate impl for elf vs windows where windows impl doesn't acquire any locks. > > Sent from my phone > > On Feb 3, 2012 5:13 PM, "Zhengyu Gu" wrote: > Hi David, > > Thanks for reviewing. I think I made wrong assumption that the thread is the last running thread. > > 803 // This should be the only running thread, decoder can safely run in > 804 // single threaded mode without acquiring lock > 805 Decoder::set_single_threaded(true); > 806 > > To avoid locking in error handler, the only solution I can think of, is to have its own private decoder. > > Please see revised webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ > > Later when there are multiple users of the Decoder I don't know how you will fix this because those other users can run concurrently with report_and_die(). That said I'm unclear what it is about the Decoder that requires locking - what state does it maintain? Is there a reason not to create a Decoder only when needed? > > Decoder is created on demand, but would prefer to be shared, since it can consume noticeable amount memory on Unix platform, by loading Elf files' symbol tables and string tables into memory (not impact on Windows). The lock is needed to protect a linked list structure in Elf decoder, or current file position. > > Thanks, > > -Zhengyu > --- > > In decoder.cpp you can still use MutexLockerEx and as it will take a null mutex and just act as a no-op eg: > > MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); > > Cheers, > David > ----- > > > Please review > Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ > > > Thanks, > > -Zhengyu > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120204/68ebf499/attachment.html From john.coomes at oracle.com Sat Feb 4 21:04:40 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sun, 05 Feb 2012 05:04:40 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120205050457.54AB047379@hg.openjdk.java.net> Changeset: 905945c5913e Author: katleman Date: 2012-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/905945c5913e Added tag jdk8-b24 for changeset a80fd4f45d7a ! .hgtags Changeset: b22de8247499 Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b22de8247499 Merge Changeset: 4e9b30938cbf Author: amurillo Date: 2012-02-03 18:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4e9b30938cbf Added tag hs23-b13 for changeset b22de8247499 ! .hgtags Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version From james.melvin at oracle.com Sun Feb 5 12:43:46 2012 From: james.melvin at oracle.com (James Melvin) Date: Sun, 05 Feb 2012 15:43:46 -0500 Subject: RFR (XXS): 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Message-ID: <4F2EEA02.7050506@oracle.com> Hi, Typical JDK control builds override EXPORT_PATH to define where to find freshly built HotSpot libraries. On Mac OS X, the override is broken. Below is a solution to this problem, as well as a solution to missing Xusage.txt files on 64-bit only builds. This fix needs to be included in the push to master to prevent RE builds from failing with the same problem. HotSpot and the JDK repos will build fine separately, but fail when built in tandem such as control builds through JPRT and RE official promotions. I'd like to request a PIT waiver to integrate this build-only change. WEBREV: http://cr.openjdk.java.net/~jmelvin/7142616/webrev.00 JPRT RUN: (internal) http://prt-web.us.oracle.com//archive/2012/02/2012-02-04-212853.jmelvin.jdk7u-dev TESTING: Builds permuting over 32/64-bit, manual/jprt, hotspot/jdk (or both), Apple/Oracle BOOTDIRs, JDK7/JDK8... SPECjbb2005 testsuite manual runs Feedback welcome. Jim From david.holmes at oracle.com Mon Feb 6 00:14:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 06 Feb 2012 18:14:21 +1000 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2C5BC8.4070303@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> Message-ID: <4F2F8BDD.9040602@oracle.com> Hi Zhengyu, On 4/02/2012 8:12 AM, Zhengyu Gu wrote: > Thanks for reviewing. I think I made wrong assumption that the thread is > the last running thread. > > 803 // This should be the only running thread, decoder can safely run in > 804 // single threaded mode without acquiring lock > 805 Decoder::set_single_threaded(true); > 806 > > To avoid locking in error handler, the only solution I can think of, is > to have its own private decoder. > > Please see revised webrev: > http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ This seems functionally ok. It is a bit strange to have a static API built on the assumption of a singleton instance now having to special case "is this the VM error thread" and use more than once instance, but I think changing that requires revisiting the whole Decoder framework. David ----- >> Later when there are multiple users of the Decoder I don't know how >> you will fix this because those other users can run concurrently with >> report_and_die(). That said I'm unclear what it is about the Decoder >> that requires locking - what state does it maintain? Is there a reason >> not to create a Decoder only when needed? >> > Decoder is created on demand, but would prefer to be shared, since it > can consume noticeable amount memory on Unix platform, by loading Elf > files' symbol tables and string tables into memory (not impact on > Windows). The lock is needed to protect a linked list structure in Elf > decoder, or current file position. > > Thanks, > > -Zhengyu >> --- >> >> In decoder.cpp you can still use MutexLockerEx and as it will take a >> null mutex and just act as a no-op eg: >> >> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >> >> Cheers, >> David >> ----- >> >>> >>> Please review >>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> From zhengyu.gu at oracle.com Mon Feb 6 06:30:53 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Mon, 06 Feb 2012 09:30:53 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2F8BDD.9040602@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> Message-ID: <4F2FE41D.80104@oracle.com> David, I total agree that it is a bit of hack. The problem is that, decoder actually hides behind os::dll_address_to_function_name(), which makes it less flexible in design. Unless we are willing to mark it as multi-thread unsafe, and manage decoder instance and lock outside the scope. Native memory tracking has such flexibility, I think that the real issue is how to redesign dll_address_to_function_name() API. Thanks, -Zhengyu On 2/6/2012 3:14 AM, David Holmes wrote: > Hi Zhengyu, > > On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >> Thanks for reviewing. I think I made wrong assumption that the thread is >> the last running thread. >> >> 803 // This should be the only running thread, decoder can safely run in >> 804 // single threaded mode without acquiring lock >> 805 Decoder::set_single_threaded(true); >> 806 >> >> To avoid locking in error handler, the only solution I can think of, is >> to have its own private decoder. >> >> Please see revised webrev: >> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ > > This seems functionally ok. It is a bit strange to have a static API > built on the assumption of a singleton instance now having to special > case "is this the VM error thread" and use more than once instance, > but I think changing that requires revisiting the whole Decoder > framework. > > David > ----- > >>> Later when there are multiple users of the Decoder I don't know how >>> you will fix this because those other users can run concurrently with >>> report_and_die(). That said I'm unclear what it is about the Decoder >>> that requires locking - what state does it maintain? Is there a reason >>> not to create a Decoder only when needed? >>> >> Decoder is created on demand, but would prefer to be shared, since it >> can consume noticeable amount memory on Unix platform, by loading Elf >> files' symbol tables and string tables into memory (not impact on >> Windows). The lock is needed to protect a linked list structure in Elf >> decoder, or current file position. >> >> Thanks, >> >> -Zhengyu >>> --- >>> >>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>> null mutex and just act as a no-op eg: >>> >>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>> >>> Cheers, >>> David >>> ----- >>> >>>> >>>> Please review >>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> From paul.hohensee at oracle.com Mon Feb 6 09:53:00 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 06 Feb 2012 12:53:00 -0500 Subject: RFR (XXS): 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds In-Reply-To: <4F2EEA02.7050506@oracle.com> References: <4F2EEA02.7050506@oracle.com> Message-ID: <4F30137C.8060901@oracle.com> Looks good. Paul On 2/5/12 3:43 PM, James Melvin wrote: > Hi, > > Typical JDK control builds override EXPORT_PATH to define where to find > freshly built HotSpot libraries. On Mac OS X, the override is broken. > Below is a solution to this problem, as well as a solution to missing > Xusage.txt files on 64-bit only builds. > > This fix needs to be included in the push to master to prevent RE builds > from failing with the same problem. HotSpot and the JDK repos will build > fine separately, but fail when built in tandem such as control builds > through JPRT and RE official promotions. I'd like to request a PIT > waiver to integrate this build-only change. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7142616/webrev.00 > > JPRT RUN: (internal) > > http://prt-web.us.oracle.com//archive/2012/02/2012-02-04-212853.jmelvin.jdk7u-dev > > > TESTING: > Builds permuting over 32/64-bit, manual/jprt, hotspot/jdk (or both), > Apple/Oracle BOOTDIRs, JDK7/JDK8... > SPECjbb2005 testsuite manual runs > > Feedback welcome. > > Jim From daniel.daugherty at oracle.com Mon Feb 6 09:56:10 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 06 Feb 2012 10:56:10 -0700 Subject: RFR (XXS): 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds In-Reply-To: <4F2EEA02.7050506@oracle.com> References: <4F2EEA02.7050506@oracle.com> Message-ID: <4F30143A.3040308@oracle.com> Hi, > > Typical JDK control builds override EXPORT_PATH to define where to find > freshly built HotSpot libraries. On Mac OS X, the override is broken. > Below is a solution to this problem, as well as a solution to missing > Xusage.txt files on 64-bit only builds. > > This fix needs to be included in the push to master to prevent RE builds > from failing with the same problem. HotSpot and the JDK repos will build > fine separately, but fail when built in tandem such as control builds > through JPRT and RE official promotions. I'd like to request a PIT > waiver to integrate this build-only change. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7142616/webrev.00 Thumbs up! make/bsd/makefiles/defs.make No comments. make/bsd/makefiles/universal.gmk No comments. Dan > > JPRT RUN: (internal) > > http://prt-web.us.oracle.com//archive/2012/02/2012-02-04-212853.jmelvin.jdk7u-dev > > > TESTING: > Builds permuting over 32/64-bit, manual/jprt, hotspot/jdk (or both), > Apple/Oracle BOOTDIRs, JDK7/JDK8... > SPECjbb2005 testsuite manual runs > > Feedback welcome. > > Jim From paul.hohensee at oracle.com Mon Feb 6 13:46:49 2012 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Mon, 06 Feb 2012 21:46:49 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20120206214655.35FA14739F@hg.openjdk.java.net> Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk From john.coomes at oracle.com Mon Feb 6 14:07:30 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Mon, 06 Feb 2012 22:07:30 +0000 Subject: hg: hsx/hsx23/hotspot: 4 new changesets Message-ID: <20120206220740.3DA29473A1@hg.openjdk.java.net> Changeset: 1f22b536808b Author: amurillo Date: 2012-02-03 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1f22b536808b 7142393: new hotspot build - hs23-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 585feefad374 Author: phh Date: 2012-02-06 14:01 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/585feefad374 7142852: MAC: Comment out JPRT jbb tests on Mac OS X until 7142850 is resolved Summary: Comment out JPRT jbb tests on Mac OS X until GUI hang can be fixed Reviewed-by: dholmes, brutisso, phh Contributed-by: james.melvin at oracle.com ! make/jprt.properties Changeset: 64b46f975ab8 Author: phh Date: 2012-02-06 14:02 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/64b46f975ab8 7142616: MAC: Honor ALT_EXPORT_PATH overrides from JDK control builds Summary: Fix EXPORT_PATH overrides on Mac OS X and only change default. Reviewed-by: phh, dcubed Contributed-by: james.melvin at oracle.com ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/universal.gmk Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags From john.coomes at oracle.com Mon Feb 6 17:54:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 07 Feb 2012 01:54:46 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20120207015459.1694F473AD@hg.openjdk.java.net> Changeset: 9ad8feb5afbd Author: amurillo Date: 2012-02-06 12:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9ad8feb5afbd Added tag hs23-b14 for changeset 64b46f975ab8 ! .hgtags Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version From david.holmes at oracle.com Mon Feb 6 18:52:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Feb 2012 12:52:20 +1000 Subject: Request for review: hotspot/jprt.properties [S] In-Reply-To: <4F2BCB39.60806@oracle.com> References: <4F2B22AB.2090807@oracle.com> <4F2B3FDD.50104@oracle.com> <4F2BCB39.60806@oracle.com> Message-ID: <4F3091E4.3040002@oracle.com> On 3/02/2012 9:55 PM, Keith McGuigan wrote: > On 2/2/2012 9:01 PM, David Holmes wrote: >> On 3/02/2012 9:56 AM, Keith McGuigan wrote: >>> Here's a webrev for changing the default JPRT release value for hotspot >>> to jdk8. It can still be overridden by the -release jdk7 during JPRT >>> submission. I also removed references to pre-7 releases and other unused >>> value (jdk7b107, jdk7temp). >> >> Are we sure there is no reason to leave any pre-7 release info here? > > As far as I know, hsx will be used only for jdk7 & jdk8 releases, > anything pre-7 has it's own separate hotspot repository (or it will, if > needed). Ok. Good to go. David From david.holmes at oracle.com Mon Feb 6 19:08:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Feb 2012 13:08:41 +1000 Subject: Fwd: hg: hsx/hotspot-rt/hotspot: 7141242: build-infra merge: Rename CPP->CXX and LINK->LD In-Reply-To: <20120207025517.43DA9473B1@hg.openjdk.java.net> References: <20120207025517.43DA9473B1@hg.openjdk.java.net> Message-ID: <4F3095B9.50506@oracle.com> Sorry for the wide distribution but the handful of people that may be affected by this could be spread across various groups. The patch below changes the names of the some of make variables used when building hotspot. Eg CPPFLAGS becomes CXXFLAGS, LINKXXX becomes LDXXX etc. It is possible that people occasionally pre-set these variables in their environment to override the default settings in the build system, or to add to them. If you do that then you will need to update your build environment to use the new names. Cheers, David Holmes (Don't shoot me, I'm just the messenger ;-) ) -------- Original Message -------- Subject: hg: hsx/hotspot-rt/hotspot: 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Date: Tue, 07 Feb 2012 02:55:13 +0000 From: david.holmes at oracle.com To: hotspot-runtime-dev at openjdk.java.net, serviceability-dev at openjdk.java.net Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make From david.holmes at oracle.com Wed Feb 8 00:36:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Feb 2012 18:36:24 +1000 Subject: 7013347: allow crypto functions to be called inline to enhance performance In-Reply-To: References: Message-ID: <4F323408.6030508@oracle.com> Hi Tom, Sorry it took a while to get to this. I get the gist of what you are trying to do here. Obviously the details are quite intricate and I don't quite follow them all, but I don't have any specific issues with anything I saw. Aside: I expect the extra { } scope in the safepoint code came from when declarations could only appear at the start of blocks. David On 31/01/2012 11:49 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/7013347 > 1133 lines changed: 979 ins; 56 del; 98 mod; 35796 unchg > > 7013347: allow crypto functions to be called inline to enhance performance > Reviewed-by: > > This is a long one. > > The synopsis of this is slightly misleading. This doens't allow > direct calls to native routines from Java but it does attempt to > reduce the overhead of using JNI for specific use cases while still > maintaining the safety invariants that JNI provdies. For native code > that runs in a bounded time JNI provides a function called > GetPrimtiveArrayCritical which may provide direct access to the body > of Java arrays of primitive. In Hotspot this is accomplished by > suppressing garbage collection while these pointers are exposed to > native code. This is accomplished with the GC_locker class which is > basically a readers/writers lock. Note that the GC_locker doesn't > suppress safepointing, just garbage collections. There are many > operations which require a safepoint to make forward progress, so > suppressing them indefinitely isn't acceptable. > > This RFE provides is a shorthand for the use of > GetPrimtiveArrayCritical by defining an alternate native calling > convention that only allows the use of primitive or arrays of > primtive. The native method must also be static since non-static > methods are passed the receiver as an argument and Java objects aren't > allowed. Synchronization and exceptions aren't allowed either. The > Java code calling these natives is fee to use all of those features so > it's not that onerous of a restriction. > > The benefits of this approach are that JVM can more quickly do the > work inline that would normally be done by the > GetPrimtiveArrayCritical/ReleasePrimtiveArrayCritical function calls. > Calling back into the JVM through JNI requires synchronization with > the JVM and each upcall adds a minimum overhead to the native routine. > This helps to reduce the overhead to a more fixed cost per call. It > also simplifies the work that the caller must do since synchronization > and exceptions aren't allowed. For now this work is being done in the > existing native wrapper generation but with some more simplification > this could be more easily inlined directly into the caller. > > The signature of the native routine follows the same name mangling as > normal JNI methods but they start with JavaCritical_ instead of Java_. > Any array arguments are unpacked into a pair of arguments, the length > followed by a pointer to the body of the array. If the incoming array > is NULL then the body pointer is NULL and the length is 0. > > Currently this is a JDK private interface while we gain some > experience with it but it will likely become a more standard > extension. It's also an optional extension so a native library is > required to provide the normal point in addition to the alternate > entry point. > > The changes consist of three parts. The first is the lookup logic > that finds the alternate native entry point. JNI critical natives > currently can only be found through dynamic lookup. JNI > RegisterNatives doesn't know about these functions so there's no way > to provide the alternate entry point. > > The second part is the lazy critical entry logic. The fix for 7129164 > introduced code that computed the JNI active count during > safepointing. Now as part of that computation, if a thread is seen to > be in thread_in_native state and the nmethod on the top of stack is a > critical native wrapper, then the critical count for that thread is > incremented and the suspend flags are set so that when the nmethod > returns the native code it will call back into the runtime and do the > unlock of the critical native. > > The last part are the native wrappers themselves. When compiling a > critical native wrapper, they emit a new check of GC_locker::_needs_gc > and they call into the runtime if it's true. This keeps them from > starting new JNI critical sections if a GC has been requested. The > arguments are unpacked following the alternate calling convention and > the method is called as it normally would be. > > On return the wrapper checks the suspend flags as it normally would > and calls back into the runtime where is might have to block and force > a GC if it's the last thread exiting the GC_locker. This required > some slightly different handling of the final transition back to > thread_in_Java since we have to allow blocking. > > The wrappers are only generated differently if they are compiling a > critical native so it shouldn't have much effect on normal execution. > The only library currently taking advantage of this is the new ucrypto > provider on Solaris. For some crypto operations it improves > throughput by 20% or more because the crypto routines are fast enough > that the JNi overhead is significant. It's expected that other parts > of the JDK will take advantage of it going forward and hopefully it > can be tightened up further. > > Tested with new crypto provider and microbenchmark test case. Also > ran runthese. > > From frederic.parain at oracle.com Wed Feb 8 02:12:01 2012 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 08 Feb 2012 11:12:01 +0100 Subject: CFV: New HSX Committer In-Reply-To: <4F280845.2030400@oracle.com> References: <4F280845.2030400@oracle.com> Message-ID: <4F324A71.7030600@oracle.com> Vote: yes On 01/31/12 04:27 PM, Paul Hohensee wrote: > I'd like to nominate Staffan Larsen to be an OpenJDK HSX project > Committer [0]. > > Staffan is a Committer on the JDK 6, 7, 7u and 8 projects, has pushed seven > changes to the Hotspot forest and is the Oracle Serviceability group > lead (the > Serviceability group's responsibility includes functionality in both the > JDK > libraries and Hotspot). Staffan is thus well-qualified to be a Committer on > the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, February 8th, 2012. > > Only current HSX Committers [1] are eligible to vote on this nomination. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > > Paul > > [0] http://openjdk.java.net/bylaws#committer > [1] http://openjdk.java.net/census/#hsx > [2] http://openjdk.java.net/projects/#committer-vote -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at Oracle.com From christian.thalinger at oracle.com Wed Feb 8 05:50:25 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 8 Feb 2012 14:50:25 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Message-ID: http://cr.openjdk.java.net/~twisti/7143766/ 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: I'd like to add the possibility to specify JDK_IMAGE_DIR via ALT_JDK_IMAGE_DIR. This is very helpful during development since it's possible to copy a JDK into a specified directory and export different VM builds to the same JDK. Doing this you don't have to change any paths (or command line arguments) but use the same java command, e.g.: $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk And after all your bugs are fixed do a product build, export that and use the same java command: $ make product export_product ALT_EXPORT_DIR=/foo/jdk The changes for test_jdk make sure that the right VM is tested. This might not be the case when you are doing 64-bit builds on Solaris, export the VM and do a test_jdk: $ make test_jdk LP64=1 INFO: no objcopy cmd found so cannot create .debuginfo files. /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) What you actually want is to run the just-built 64-bit VM, like: $ make test_jdk LP64=1 INFO: no objcopy cmd found so cannot create .debuginfo files. /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) I also added printing -Xinternalversion to test_jdk. This makes it easier to verify the installed VM is the one you just built (and want to test). make/Makefile make/bsd/makefiles/defs.make make/defs.make From rickard.backman at oracle.com Wed Feb 8 06:15:20 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 08 Feb 2012 15:15:20 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: References: Message-ID: <4F328378.9090105@oracle.com> Christian, is the duplication of lines 452-453 on 455-456 intendend? (make/Makefile) 450 ifeq ($(ARCH_DATA_MODEL), 32) 451 ifneq ($(ZERO_BUILD), true) 452 $(JDK_IMAGE_DIR)/bin/java -d32 -client -Xinternalversion 453 $(JDK_IMAGE_DIR)/bin/java -d32 -client -version 454 endif 455 $(JDK_IMAGE_DIR)/bin/java -d32 -server -Xinternalversion 456 $(JDK_IMAGE_DIR)/bin/java -d32 -server -version 457 endif Seems like the commands will run twice on non-zero builds? /R On 02/08/2012 02:50 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7143766/ > > 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk > Reviewed-by: > > I'd like to add the possibility to specify JDK_IMAGE_DIR via > ALT_JDK_IMAGE_DIR. This is very helpful during development since it's > possible to copy a JDK into a specified directory and export different > VM builds to the same JDK. Doing this you don't have to change any > paths (or command line arguments) but use the same java command, e.g.: > > $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk > $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk > > And after all your bugs are fixed do a product build, export that and > use the same java command: > > $ make product export_product ALT_EXPORT_DIR=/foo/jdk > > The changes for test_jdk make sure that the right VM is tested. This > might not be the case when you are doing 64-bit builds on Solaris, > export the VM and do a test_jdk: > > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) > > What you actually want is to run the just-built 64-bit VM, like: > > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion > Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) > > I also added printing -Xinternalversion to test_jdk. This makes it > easier to verify the installed VM is the one you just built (and want > to test). > > make/Makefile > make/bsd/makefiles/defs.make > make/defs.make > From christian.thalinger at oracle.com Wed Feb 8 06:21:44 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 8 Feb 2012 15:21:44 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <4F328378.9090105@oracle.com> References: <4F328378.9090105@oracle.com> Message-ID: <398280D1-29F6-43F8-95F9-6A9E887717D2@oracle.com> On Feb 8, 2012, at 3:15 PM, Rickard B?ckman wrote: > Christian, > > is the duplication of lines 452-453 on 455-456 intendend? (make/Makefile) > > 450 ifeq ($(ARCH_DATA_MODEL), 32) > 451 ifneq ($(ZERO_BUILD), true) > 452 $(JDK_IMAGE_DIR)/bin/java -d32 -client -Xinternalversion > 453 $(JDK_IMAGE_DIR)/bin/java -d32 -client -version > 454 endif > 455 $(JDK_IMAGE_DIR)/bin/java -d32 -server -Xinternalversion > 456 $(JDK_IMAGE_DIR)/bin/java -d32 -server -version > 457 endif > > Seems like the commands will run twice on non-zero builds? If you look closely it's testing client and server on 32-bit. Zero never had a client VM. -- Chris > > /R > > On 02/08/2012 02:50 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7143766/ >> >> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >> Reviewed-by: >> >> I'd like to add the possibility to specify JDK_IMAGE_DIR via >> ALT_JDK_IMAGE_DIR. This is very helpful during development since it's >> possible to copy a JDK into a specified directory and export different >> VM builds to the same JDK. Doing this you don't have to change any >> paths (or command line arguments) but use the same java command, e.g.: >> >> $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk >> $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk >> >> And after all your bugs are fixed do a product build, export that and >> use the same java command: >> >> $ make product export_product ALT_EXPORT_DIR=/foo/jdk >> >> The changes for test_jdk make sure that the right VM is tested. This >> might not be the case when you are doing 64-bit builds on Solaris, >> export the VM and do a test_jdk: >> >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >> >> What you actually want is to run the just-built 64-bit VM, like: >> >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >> >> I also added printing -Xinternalversion to test_jdk. This makes it >> easier to verify the installed VM is the one you just built (and want >> to test). >> >> make/Makefile >> make/bsd/makefiles/defs.make >> make/defs.make >> > From rickard.backman at oracle.com Wed Feb 8 06:29:52 2012 From: rickard.backman at oracle.com (=?ISO-8859-1?Q?Rickard_B=E4ckman?=) Date: Wed, 08 Feb 2012 15:29:52 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <398280D1-29F6-43F8-95F9-6A9E887717D2@oracle.com> References: <4F328378.9090105@oracle.com> <398280D1-29F6-43F8-95F9-6A9E887717D2@oracle.com> Message-ID: <4F3286E0.20903@oracle.com> On 02/08/2012 03:21 PM, Christian Thalinger wrote: > > On Feb 8, 2012, at 3:15 PM, Rickard B?ckman wrote: > >> Christian, >> >> is the duplication of lines 452-453 on 455-456 intendend? (make/Makefile) >> >> 450 ifeq ($(ARCH_DATA_MODEL), 32) >> 451 ifneq ($(ZERO_BUILD), true) >> 452 $(JDK_IMAGE_DIR)/bin/java -d32 -client -Xinternalversion >> 453 $(JDK_IMAGE_DIR)/bin/java -d32 -client -version >> 454 endif >> 455 $(JDK_IMAGE_DIR)/bin/java -d32 -server -Xinternalversion >> 456 $(JDK_IMAGE_DIR)/bin/java -d32 -server -version >> 457 endif >> >> Seems like the commands will run twice on non-zero builds? > > If you look closely it's testing client and server on 32-bit. Zero never had a client VM. > Right! Looks good to me. /R > -- Chris > >> >> /R >> >> On 02/08/2012 02:50 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7143766/ >>> >>> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >>> Reviewed-by: >>> >>> I'd like to add the possibility to specify JDK_IMAGE_DIR via >>> ALT_JDK_IMAGE_DIR. This is very helpful during development since it's >>> possible to copy a JDK into a specified directory and export different >>> VM builds to the same JDK. Doing this you don't have to change any >>> paths (or command line arguments) but use the same java command, e.g.: >>> >>> $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk >>> $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk >>> >>> And after all your bugs are fixed do a product build, export that and >>> use the same java command: >>> >>> $ make product export_product ALT_EXPORT_DIR=/foo/jdk >>> >>> The changes for test_jdk make sure that the right VM is tested. This >>> might not be the case when you are doing 64-bit builds on Solaris, >>> export the VM and do a test_jdk: >>> >>> $ make test_jdk LP64=1 >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >>> >>> What you actually want is to run the just-built 64-bit VM, like: >>> >>> $ make test_jdk LP64=1 >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >>> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >>> >>> I also added printing -Xinternalversion to test_jdk. This makes it >>> easier to verify the installed VM is the one you just built (and want >>> to test). >>> >>> make/Makefile >>> make/bsd/makefiles/defs.make >>> make/defs.make >>> >> > From karen.kinnear at oracle.com Wed Feb 8 07:19:56 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Feb 2012 10:19:56 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F2FE41D.80104@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> <4F2FE41D.80104@oracle.com> Message-ID: <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> Zhengyu, The code looks like it will work. I would appreciate a comment that we never cleanup the error handler decoder since it is only used on crashing. Just to be sure I understand - there are currently no callers of Decoder::shutdown(), i.e. no users of the shared decoder are in the system yet. Longer term, with additional cases I would recommend managing the scope of the decoder instance outside the decoder code itself. thanks, Karen On Feb 6, 2012, at 9:30 AM, Zhengyu Gu wrote: > David, > > I total agree that it is a bit of hack. The problem is that, decoder actually hides behind os::dll_address_to_function_name(), which makes it less flexible in design. Unless we are willing to mark it as multi-thread unsafe, and manage decoder instance and lock outside the scope. Native memory tracking has such flexibility, I think that the real issue is how to redesign dll_address_to_function_name() API. > > > Thanks, > > -Zhengyu > > On 2/6/2012 3:14 AM, David Holmes wrote: >> Hi Zhengyu, >> >> On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >>> Thanks for reviewing. I think I made wrong assumption that the thread is >>> the last running thread. >>> >>> 803 // This should be the only running thread, decoder can safely run in >>> 804 // single threaded mode without acquiring lock >>> 805 Decoder::set_single_threaded(true); >>> 806 >>> >>> To avoid locking in error handler, the only solution I can think of, is >>> to have its own private decoder. >>> >>> Please see revised webrev: >>> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ >> >> This seems functionally ok. It is a bit strange to have a static API built on the assumption of a singleton instance now having to special case "is this the VM error thread" and use more than once instance, but I think changing that requires revisiting the whole Decoder framework. >> >> David >> ----- >> >>>> Later when there are multiple users of the Decoder I don't know how >>>> you will fix this because those other users can run concurrently with >>>> report_and_die(). That said I'm unclear what it is about the Decoder >>>> that requires locking - what state does it maintain? Is there a reason >>>> not to create a Decoder only when needed? >>>> >>> Decoder is created on demand, but would prefer to be shared, since it >>> can consume noticeable amount memory on Unix platform, by loading Elf >>> files' symbol tables and string tables into memory (not impact on >>> Windows). The lock is needed to protect a linked list structure in Elf >>> decoder, or current file position. >>> >>> Thanks, >>> >>> -Zhengyu >>>> --- >>>> >>>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>>> null mutex and just act as a no-op eg: >>>> >>>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> >>>>> Please review >>>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zhengyu.gu at oracle.com Wed Feb 8 09:25:55 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 08 Feb 2012 12:25:55 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> <4F2FE41D.80104@oracle.com> <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> Message-ID: <4F32B023.1080801@oracle.com> Karen, Thanks for reviewing. I am incorporating Keith's and your comments, will send out a revision later. -Zhengyu On 2/8/2012 10:19 AM, Karen Kinnear wrote: > Zhengyu, > > The code looks like it will work. > > I would appreciate a comment that we never cleanup the error handler decoder since it > is only used on crashing. > Just to be sure I understand - there are currently no callers of Decoder::shutdown(), i.e. > no users of the shared decoder are in the system yet. > Longer term, with additional cases I would recommend managing the scope of the decoder > instance outside the decoder code itself. > > thanks, > Karen > > On Feb 6, 2012, at 9:30 AM, Zhengyu Gu wrote: > >> David, >> >> I total agree that it is a bit of hack. The problem is that, decoder actually hides behind os::dll_address_to_function_name(), which makes it less flexible in design. Unless we are willing to mark it as multi-thread unsafe, and manage decoder instance and lock outside the scope. Native memory tracking has such flexibility, I think that the real issue is how to redesign dll_address_to_function_name() API. >> >> >> Thanks, >> >> -Zhengyu >> >> On 2/6/2012 3:14 AM, David Holmes wrote: >>> Hi Zhengyu, >>> >>> On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >>>> Thanks for reviewing. I think I made wrong assumption that the thread is >>>> the last running thread. >>>> >>>> 803 // This should be the only running thread, decoder can safely run in >>>> 804 // single threaded mode without acquiring lock >>>> 805 Decoder::set_single_threaded(true); >>>> 806 >>>> >>>> To avoid locking in error handler, the only solution I can think of, is >>>> to have its own private decoder. >>>> >>>> Please see revised webrev: >>>> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ >>> This seems functionally ok. It is a bit strange to have a static API built on the assumption of a singleton instance now having to special case "is this the VM error thread" and use more than once instance, but I think changing that requires revisiting the whole Decoder framework. >>> >>> David >>> ----- >>> >>>>> Later when there are multiple users of the Decoder I don't know how >>>>> you will fix this because those other users can run concurrently with >>>>> report_and_die(). That said I'm unclear what it is about the Decoder >>>>> that requires locking - what state does it maintain? Is there a reason >>>>> not to create a Decoder only when needed? >>>>> >>>> Decoder is created on demand, but would prefer to be shared, since it >>>> can consume noticeable amount memory on Unix platform, by loading Elf >>>> files' symbol tables and string tables into memory (not impact on >>>> Windows). The lock is needed to protect a linked list structure in Elf >>>> decoder, or current file position. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>>> --- >>>>> >>>>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>>>> null mutex and just act as a no-op eg: >>>>> >>>>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>>> Please review >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> From tom.rodriguez at oracle.com Wed Feb 8 10:17:24 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 8 Feb 2012 10:17:24 -0800 Subject: 7013347: allow crypto functions to be called inline to enhance performance In-Reply-To: <4F323408.6030508@oracle.com> References: <4F323408.6030508@oracle.com> Message-ID: On Feb 8, 2012, at 12:36 AM, David Holmes wrote: > Hi Tom, > > Sorry it took a while to get to this. > > I get the gist of what you are trying to do here. Obviously the details are quite intricate and I don't quite follow them all, but I don't have any specific issues with anything I saw. Thanks for looking at it. tom > > Aside: I expect the extra { } scope in the safepoint code came from when declarations could only appear at the start of blocks. > > David > > > On 31/01/2012 11:49 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/7013347 >> 1133 lines changed: 979 ins; 56 del; 98 mod; 35796 unchg >> >> 7013347: allow crypto functions to be called inline to enhance performance >> Reviewed-by: >> >> This is a long one. >> >> The synopsis of this is slightly misleading. This doens't allow >> direct calls to native routines from Java but it does attempt to >> reduce the overhead of using JNI for specific use cases while still >> maintaining the safety invariants that JNI provdies. For native code >> that runs in a bounded time JNI provides a function called >> GetPrimtiveArrayCritical which may provide direct access to the body >> of Java arrays of primitive. In Hotspot this is accomplished by >> suppressing garbage collection while these pointers are exposed to >> native code. This is accomplished with the GC_locker class which is >> basically a readers/writers lock. Note that the GC_locker doesn't >> suppress safepointing, just garbage collections. There are many >> operations which require a safepoint to make forward progress, so >> suppressing them indefinitely isn't acceptable. >> >> This RFE provides is a shorthand for the use of >> GetPrimtiveArrayCritical by defining an alternate native calling >> convention that only allows the use of primitive or arrays of >> primtive. The native method must also be static since non-static >> methods are passed the receiver as an argument and Java objects aren't >> allowed. Synchronization and exceptions aren't allowed either. The >> Java code calling these natives is fee to use all of those features so >> it's not that onerous of a restriction. >> >> The benefits of this approach are that JVM can more quickly do the >> work inline that would normally be done by the >> GetPrimtiveArrayCritical/ReleasePrimtiveArrayCritical function calls. >> Calling back into the JVM through JNI requires synchronization with >> the JVM and each upcall adds a minimum overhead to the native routine. >> This helps to reduce the overhead to a more fixed cost per call. It >> also simplifies the work that the caller must do since synchronization >> and exceptions aren't allowed. For now this work is being done in the >> existing native wrapper generation but with some more simplification >> this could be more easily inlined directly into the caller. >> >> The signature of the native routine follows the same name mangling as >> normal JNI methods but they start with JavaCritical_ instead of Java_. >> Any array arguments are unpacked into a pair of arguments, the length >> followed by a pointer to the body of the array. If the incoming array >> is NULL then the body pointer is NULL and the length is 0. >> >> Currently this is a JDK private interface while we gain some >> experience with it but it will likely become a more standard >> extension. It's also an optional extension so a native library is >> required to provide the normal point in addition to the alternate >> entry point. >> >> The changes consist of three parts. The first is the lookup logic >> that finds the alternate native entry point. JNI critical natives >> currently can only be found through dynamic lookup. JNI >> RegisterNatives doesn't know about these functions so there's no way >> to provide the alternate entry point. >> >> The second part is the lazy critical entry logic. The fix for 7129164 >> introduced code that computed the JNI active count during >> safepointing. Now as part of that computation, if a thread is seen to >> be in thread_in_native state and the nmethod on the top of stack is a >> critical native wrapper, then the critical count for that thread is >> incremented and the suspend flags are set so that when the nmethod >> returns the native code it will call back into the runtime and do the >> unlock of the critical native. >> >> The last part are the native wrappers themselves. When compiling a >> critical native wrapper, they emit a new check of GC_locker::_needs_gc >> and they call into the runtime if it's true. This keeps them from >> starting new JNI critical sections if a GC has been requested. The >> arguments are unpacked following the alternate calling convention and >> the method is called as it normally would be. >> >> On return the wrapper checks the suspend flags as it normally would >> and calls back into the runtime where is might have to block and force >> a GC if it's the last thread exiting the GC_locker. This required >> some slightly different handling of the final transition back to >> thread_in_Java since we have to allow blocking. >> >> The wrappers are only generated differently if they are compiling a >> critical native so it shouldn't have much effect on normal execution. >> The only library currently taking advantage of this is the new ucrypto >> provider on Solaris. For some crypto operations it improves >> throughput by 20% or more because the crypto routines are fast enough >> that the JNi overhead is significant. It's expected that other parts >> of the JDK will take advantage of it going forward and hopefully it >> can be tightened up further. >> >> Tested with new crypto provider and microbenchmark test case. Also >> ran runthese. >> >> From zhengyu.gu at oracle.com Wed Feb 8 10:23:47 2012 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Wed, 08 Feb 2012 13:23:47 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> <4F2FE41D.80104@oracle.com> <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> Message-ID: <4F32BDB3.5020304@oracle.com> Hi, As I mentioned in earlier email, please find revised webrev, which incorporated suggestions from Karen and Keith. http://cr.openjdk.java.net/~zgu/7141259/webrev.02/ Thanks, -Zhengyu On 2/8/2012 10:19 AM, Karen Kinnear wrote: > Zhengyu, > > The code looks like it will work. > > I would appreciate a comment that we never cleanup the error handler decoder since it > is only used on crashing. > Just to be sure I understand - there are currently no callers of Decoder::shutdown(), i.e. > no users of the shared decoder are in the system yet. > Longer term, with additional cases I would recommend managing the scope of the decoder > instance outside the decoder code itself. > > thanks, > Karen > > On Feb 6, 2012, at 9:30 AM, Zhengyu Gu wrote: > >> David, >> >> I total agree that it is a bit of hack. The problem is that, decoder actually hides behind os::dll_address_to_function_name(), which makes it less flexible in design. Unless we are willing to mark it as multi-thread unsafe, and manage decoder instance and lock outside the scope. Native memory tracking has such flexibility, I think that the real issue is how to redesign dll_address_to_function_name() API. >> >> >> Thanks, >> >> -Zhengyu >> >> On 2/6/2012 3:14 AM, David Holmes wrote: >>> Hi Zhengyu, >>> >>> On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >>>> Thanks for reviewing. I think I made wrong assumption that the thread is >>>> the last running thread. >>>> >>>> 803 // This should be the only running thread, decoder can safely run in >>>> 804 // single threaded mode without acquiring lock >>>> 805 Decoder::set_single_threaded(true); >>>> 806 >>>> >>>> To avoid locking in error handler, the only solution I can think of, is >>>> to have its own private decoder. >>>> >>>> Please see revised webrev: >>>> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ >>> This seems functionally ok. It is a bit strange to have a static API built on the assumption of a singleton instance now having to special case "is this the VM error thread" and use more than once instance, but I think changing that requires revisiting the whole Decoder framework. >>> >>> David >>> ----- >>> >>>>> Later when there are multiple users of the Decoder I don't know how >>>>> you will fix this because those other users can run concurrently with >>>>> report_and_die(). That said I'm unclear what it is about the Decoder >>>>> that requires locking - what state does it maintain? Is there a reason >>>>> not to create a Decoder only when needed? >>>>> >>>> Decoder is created on demand, but would prefer to be shared, since it >>>> can consume noticeable amount memory on Unix platform, by loading Elf >>>> files' symbol tables and string tables into memory (not impact on >>>> Windows). The lock is needed to protect a linked list structure in Elf >>>> decoder, or current file position. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>>> --- >>>>> >>>>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>>>> null mutex and just act as a no-op eg: >>>>> >>>>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>>> Please review >>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> From john.r.rose at oracle.com Wed Feb 8 11:14:53 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Feb 2012 11:14:53 -0800 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: References: Message-ID: <165C8110-D994-4FD3-87A6-8232359BFFB3@oracle.com> Consider rolling in this debug help so "make gamma" works. http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f21b335377b0 -- John (on my iPhone) On Feb 8, 2012, at 5:50 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7143766/ > > 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk > Reviewed-by: > > I'd like to add the possibility to specify JDK_IMAGE_DIR via > ALT_JDK_IMAGE_DIR. This is very helpful during development since it's > possible to copy a JDK into a specified directory and export different > VM builds to the same JDK. Doing this you don't have to change any > paths (or command line arguments) but use the same java command, e.g.: > > $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk > $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk > > And after all your bugs are fixed do a product build, export that and > use the same java command: > > $ make product export_product ALT_EXPORT_DIR=/foo/jdk > > The changes for test_jdk make sure that the right VM is tested. This > might not be the case when you are doing 64-bit builds on Solaris, > export the VM and do a test_jdk: > > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) > > What you actually want is to run the just-built 64-bit VM, like: > > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion > Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) > > I also added printing -Xinternalversion to test_jdk. This makes it > easier to verify the installed VM is the one you just built (and want > to test). > > make/Makefile > make/bsd/makefiles/defs.make > make/defs.make > From kirk at kodewerk.com Wed Feb 8 14:16:21 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Wed, 8 Feb 2012 23:16:21 +0100 Subject: 7013347: allow crypto functions to be called inline to enhance performance In-Reply-To: <4F323408.6030508@oracle.com> References: <4F323408.6030508@oracle.com> Message-ID: <3A7B118E-EB5F-467C-92B8-24DB5EDA9FFA@kodewerk.com> Hi all, Once again I'm looking at a client where the *only* problem they have are long pause times created the the RMI forced full gc. So, once again I have to question, why does RMI force a full GC when we all know this (aside from a few edge cases) is generally regarded as bad practice. I'm about to file this as a bug. Regards, Kirk From david.holmes at oracle.com Wed Feb 8 18:32:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Feb 2012 12:32:44 +1000 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: References: Message-ID: <4F33304C.8020208@oracle.com> Hi Christian, On 8/02/2012 11:50 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7143766/ > > 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk > Reviewed-by: > > I'd like to add the possibility to specify JDK_IMAGE_DIR via > ALT_JDK_IMAGE_DIR. There's no need to add this, you can just set JDK_IMAGE_DIR > The changes for test_jdk make sure that the right VM is tested. This > might not be the case when you are doing 64-bit builds on Solaris, > export the VM and do a test_jdk: Hmmm. Not sure that launching the VM four times for a normal 32-bit build is really something to add. But then I don't think any regular build process (JDK control build, JPRT) actually uses the target you modified. David ----- > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) > > What you actually want is to run the just-built 64-bit VM, like: > > $ make test_jdk LP64=1 > INFO: no objcopy cmd found so cannot create .debuginfo files. > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion > Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 > /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) > > I also added printing -Xinternalversion to test_jdk. This makes it > easier to verify the installed VM is the one you just built (and want > to test). > > make/Makefile > make/bsd/makefiles/defs.make > make/defs.make > From david.holmes at oracle.com Wed Feb 8 19:07:53 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Feb 2012 13:07:53 +1000 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F32BDB3.5020304@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> <4F2FE41D.80104@oracle.com> <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> <4F32BDB3.5020304@oracle.com> Message-ID: <4F333889.3010508@oracle.com> I didn't see any comments from Keith so had to infer what the additional changes were. Seems okay. David On 9/02/2012 4:23 AM, Zhengyu Gu wrote: > Hi, > > As I mentioned in earlier email, please find revised webrev, which > incorporated suggestions from Karen and Keith. > > http://cr.openjdk.java.net/~zgu/7141259/webrev.02/ > > Thanks, > > -Zhengyu > > On 2/8/2012 10:19 AM, Karen Kinnear wrote: >> Zhengyu, >> >> The code looks like it will work. >> >> I would appreciate a comment that we never cleanup the error handler >> decoder since it >> is only used on crashing. >> Just to be sure I understand - there are currently no callers of >> Decoder::shutdown(), i.e. >> no users of the shared decoder are in the system yet. >> Longer term, with additional cases I would recommend managing the >> scope of the decoder >> instance outside the decoder code itself. >> >> thanks, >> Karen >> >> On Feb 6, 2012, at 9:30 AM, Zhengyu Gu wrote: >> >>> David, >>> >>> I total agree that it is a bit of hack. The problem is that, decoder >>> actually hides behind os::dll_address_to_function_name(), which makes >>> it less flexible in design. Unless we are willing to mark it as >>> multi-thread unsafe, and manage decoder instance and lock outside the >>> scope. Native memory tracking has such flexibility, I think that the >>> real issue is how to redesign dll_address_to_function_name() API. >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> On 2/6/2012 3:14 AM, David Holmes wrote: >>>> Hi Zhengyu, >>>> >>>> On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >>>>> Thanks for reviewing. I think I made wrong assumption that the >>>>> thread is >>>>> the last running thread. >>>>> >>>>> 803 // This should be the only running thread, decoder can safely >>>>> run in >>>>> 804 // single threaded mode without acquiring lock >>>>> 805 Decoder::set_single_threaded(true); >>>>> 806 >>>>> >>>>> To avoid locking in error handler, the only solution I can think >>>>> of, is >>>>> to have its own private decoder. >>>>> >>>>> Please see revised webrev: >>>>> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ >>>> This seems functionally ok. It is a bit strange to have a static API >>>> built on the assumption of a singleton instance now having to >>>> special case "is this the VM error thread" and use more than once >>>> instance, but I think changing that requires revisiting the whole >>>> Decoder framework. >>>> >>>> David >>>> ----- >>>> >>>>>> Later when there are multiple users of the Decoder I don't know how >>>>>> you will fix this because those other users can run concurrently with >>>>>> report_and_die(). That said I'm unclear what it is about the Decoder >>>>>> that requires locking - what state does it maintain? Is there a >>>>>> reason >>>>>> not to create a Decoder only when needed? >>>>>> >>>>> Decoder is created on demand, but would prefer to be shared, since it >>>>> can consume noticeable amount memory on Unix platform, by loading Elf >>>>> files' symbol tables and string tables into memory (not impact on >>>>> Windows). The lock is needed to protect a linked list structure in Elf >>>>> decoder, or current file position. >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>>> --- >>>>>> >>>>>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>>>>> null mutex and just act as a no-op eg: >>>>>> >>>>>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Please review >>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Zhengyu >>>>>>> From christian.thalinger at oracle.com Thu Feb 9 00:37:31 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Feb 2012 09:37:31 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <4F33304C.8020208@oracle.com> References: <4F33304C.8020208@oracle.com> Message-ID: <9C4EAD31-BEA9-4154-BDD4-EC7ED94DB2F3@oracle.com> On Feb 9, 2012, at 3:32 AM, David Holmes wrote: > Hi Christian, > > On 8/02/2012 11:50 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/7143766/ >> >> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >> Reviewed-by: >> >> I'd like to add the possibility to specify JDK_IMAGE_DIR via >> ALT_JDK_IMAGE_DIR. > > There's no need to add this, you can just set JDK_IMAGE_DIR That's correct but only when you specify it on the command line not when you set it as env variable: $ make help JDK_IMAGE_DIR=/foo | grep JDK_IMAGE_DIR Makefile:401: target `/Xusage.txt' given more than once in the same rule. ALT_JDK_IMAGE_DIR - Directory to place JDK to copy JDK_IMAGE_DIR=/foo $ JDK_IMAGE_DIR=/foo make help | grep JDK_IMAGE_DIR Makefile:401: target `/Xusage.txt' given more than once in the same rule. ALT_JDK_IMAGE_DIR - Directory to place JDK to copy JDK_IMAGE_DIR=/Users/twisti/build/mlvm/hotspot/build/jdk-bsd-amd64 I guess my examples weren't good chosen. -- Chris > >> The changes for test_jdk make sure that the right VM is tested. This >> might not be the case when you are doing 64-bit builds on Solaris, >> export the VM and do a test_jdk: > > Hmmm. Not sure that launching the VM four times for a normal 32-bit build is really something to add. But then I don't think any regular build process (JDK control build, JPRT) actually uses the target you modified. > > David > ----- > >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >> >> What you actually want is to run the just-built 64-bit VM, like: >> >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >> >> I also added printing -Xinternalversion to test_jdk. This makes it >> easier to verify the installed VM is the one you just built (and want >> to test). >> >> make/Makefile >> make/bsd/makefiles/defs.make >> make/defs.make >> From david.holmes at oracle.com Thu Feb 9 00:43:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 09 Feb 2012 18:43:26 +1000 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <9C4EAD31-BEA9-4154-BDD4-EC7ED94DB2F3@oracle.com> References: <4F33304C.8020208@oracle.com> <9C4EAD31-BEA9-4154-BDD4-EC7ED94DB2F3@oracle.com> Message-ID: <4F33872E.7080000@oracle.com> On 9/02/2012 6:37 PM, Christian Thalinger wrote: > > On Feb 9, 2012, at 3:32 AM, David Holmes wrote: > >> Hi Christian, >> >> On 8/02/2012 11:50 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/7143766/ >>> >>> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >>> Reviewed-by: >>> >>> I'd like to add the possibility to specify JDK_IMAGE_DIR via >>> ALT_JDK_IMAGE_DIR. >> >> There's no need to add this, you can just set JDK_IMAGE_DIR > > That's correct but only when you specify it on the command line not when you set it as env variable: Also correct. :) Seems a minor change and likely short-lived given the impending build changes in the pipeline. So okay by me. David ----- > $ make help JDK_IMAGE_DIR=/foo | grep JDK_IMAGE_DIR > Makefile:401: target `/Xusage.txt' given more than once in the same rule. > ALT_JDK_IMAGE_DIR - Directory to place JDK to copy > JDK_IMAGE_DIR=/foo > > $ JDK_IMAGE_DIR=/foo make help | grep JDK_IMAGE_DIR > Makefile:401: target `/Xusage.txt' given more than once in the same rule. > ALT_JDK_IMAGE_DIR - Directory to place JDK to copy > JDK_IMAGE_DIR=/Users/twisti/build/mlvm/hotspot/build/jdk-bsd-amd64 > > I guess my examples weren't good chosen. > > -- Chris > >> >>> The changes for test_jdk make sure that the right VM is tested. This >>> might not be the case when you are doing 64-bit builds on Solaris, >>> export the VM and do a test_jdk: >> >> Hmmm. Not sure that launching the VM four times for a normal 32-bit build is really something to add. But then I don't think any regular build process (JDK control build, JPRT) actually uses the target you modified. >> >> David >> ----- >> >>> $ make test_jdk LP64=1 >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >>> >>> What you actually want is to run the just-built 64-bit VM, like: >>> >>> $ make test_jdk LP64=1 >>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >>> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >>> >>> I also added printing -Xinternalversion to test_jdk. This makes it >>> easier to verify the installed VM is the one you just built (and want >>> to test). >>> >>> make/Makefile >>> make/bsd/makefiles/defs.make >>> make/defs.make >>> > From christian.thalinger at oracle.com Thu Feb 9 01:03:23 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 9 Feb 2012 10:03:23 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <4F33872E.7080000@oracle.com> References: <4F33304C.8020208@oracle.com> <9C4EAD31-BEA9-4154-BDD4-EC7ED94DB2F3@oracle.com> <4F33872E.7080000@oracle.com> Message-ID: <9934D6D1-7E7B-434C-8A60-BE7A73B6F55F@oracle.com> On Feb 9, 2012, at 9:43 AM, David Holmes wrote: > On 9/02/2012 6:37 PM, Christian Thalinger wrote: >> >> On Feb 9, 2012, at 3:32 AM, David Holmes wrote: >> >>> Hi Christian, >>> >>> On 8/02/2012 11:50 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/7143766/ >>>> >>>> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >>>> Reviewed-by: >>>> >>>> I'd like to add the possibility to specify JDK_IMAGE_DIR via >>>> ALT_JDK_IMAGE_DIR. >>> >>> There's no need to add this, you can just set JDK_IMAGE_DIR >> >> That's correct but only when you specify it on the command line not when you set it as env variable: > > Also correct. :) > > Seems a minor change and likely short-lived given the impending build changes in the pipeline. So okay by me. Yeah, I hope not :-( Thanks for the review. -- Chris > > David > ----- > >> $ make help JDK_IMAGE_DIR=/foo | grep JDK_IMAGE_DIR >> Makefile:401: target `/Xusage.txt' given more than once in the same rule. >> ALT_JDK_IMAGE_DIR - Directory to place JDK to copy >> JDK_IMAGE_DIR=/foo >> >> $ JDK_IMAGE_DIR=/foo make help | grep JDK_IMAGE_DIR >> Makefile:401: target `/Xusage.txt' given more than once in the same rule. >> ALT_JDK_IMAGE_DIR - Directory to place JDK to copy >> JDK_IMAGE_DIR=/Users/twisti/build/mlvm/hotspot/build/jdk-bsd-amd64 >> >> I guess my examples weren't good chosen. >> >> -- Chris >> >>> >>>> The changes for test_jdk make sure that the right VM is tested. This >>>> might not be the case when you are doing 64-bit builds on Solaris, >>>> export the VM and do a test_jdk: >>> >>> Hmmm. Not sure that launching the VM four times for a normal 32-bit build is really something to add. But then I don't think any regular build process (JDK control build, JPRT) actually uses the target you modified. >>> >>> David >>> ----- >>> >>>> $ make test_jdk LP64=1 >>>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>>> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >>>> >>>> What you actually want is to run the just-built 64-bit VM, like: >>>> >>>> $ make test_jdk LP64=1 >>>> INFO: no objcopy cmd found so cannot create .debuginfo files. >>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >>>> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >>>> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >>>> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >>>> >>>> I also added printing -Xinternalversion to test_jdk. This makes it >>>> easier to verify the installed VM is the one you just built (and want >>>> to test). >>>> >>>> make/Makefile >>>> make/bsd/makefiles/defs.make >>>> make/defs.make >>>> >> From karen.kinnear at oracle.com Thu Feb 9 05:41:32 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 9 Feb 2012 08:41:32 -0500 Subject: Code review request: CR 7141259 Native stack is missing in hs_err In-Reply-To: <4F333889.3010508@oracle.com> References: <4F2AB5B8.6000002@oracle.com> <4F2B4E73.2010904@oracle.com> <4F2C5BC8.4070303@oracle.com> <4F2F8BDD.9040602@oracle.com> <4F2FE41D.80104@oracle.com> <1F32A261-5C69-44C5-B690-12AF4E86AB1D@oracle.com> <4F32BDB3.5020304@oracle.com> <4F333889.3010508@oracle.com> Message-ID: Looks fine. Ship it. Thanks Zhengyu, Karen On Feb 8, 2012, at 10:07 PM, David Holmes wrote: > I didn't see any comments from Keith so had to infer what the additional changes were. > > Seems okay. > > David > > On 9/02/2012 4:23 AM, Zhengyu Gu wrote: >> Hi, >> >> As I mentioned in earlier email, please find revised webrev, which >> incorporated suggestions from Karen and Keith. >> >> http://cr.openjdk.java.net/~zgu/7141259/webrev.02/ >> >> Thanks, >> >> -Zhengyu >> >> On 2/8/2012 10:19 AM, Karen Kinnear wrote: >>> Zhengyu, >>> >>> The code looks like it will work. >>> >>> I would appreciate a comment that we never cleanup the error handler >>> decoder since it >>> is only used on crashing. >>> Just to be sure I understand - there are currently no callers of >>> Decoder::shutdown(), i.e. >>> no users of the shared decoder are in the system yet. >>> Longer term, with additional cases I would recommend managing the >>> scope of the decoder >>> instance outside the decoder code itself. >>> >>> thanks, >>> Karen >>> >>> On Feb 6, 2012, at 9:30 AM, Zhengyu Gu wrote: >>> >>>> David, >>>> >>>> I total agree that it is a bit of hack. The problem is that, decoder >>>> actually hides behind os::dll_address_to_function_name(), which makes >>>> it less flexible in design. Unless we are willing to mark it as >>>> multi-thread unsafe, and manage decoder instance and lock outside the >>>> scope. Native memory tracking has such flexibility, I think that the >>>> real issue is how to redesign dll_address_to_function_name() API. >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> On 2/6/2012 3:14 AM, David Holmes wrote: >>>>> Hi Zhengyu, >>>>> >>>>> On 4/02/2012 8:12 AM, Zhengyu Gu wrote: >>>>>> Thanks for reviewing. I think I made wrong assumption that the >>>>>> thread is >>>>>> the last running thread. >>>>>> >>>>>> 803 // This should be the only running thread, decoder can safely >>>>>> run in >>>>>> 804 // single threaded mode without acquiring lock >>>>>> 805 Decoder::set_single_threaded(true); >>>>>> 806 >>>>>> >>>>>> To avoid locking in error handler, the only solution I can think >>>>>> of, is >>>>>> to have its own private decoder. >>>>>> >>>>>> Please see revised webrev: >>>>>> http://cr.openjdk.java.net/~zgu/7141259/webrev.01/ >>>>> This seems functionally ok. It is a bit strange to have a static API >>>>> built on the assumption of a singleton instance now having to >>>>> special case "is this the VM error thread" and use more than once >>>>> instance, but I think changing that requires revisiting the whole >>>>> Decoder framework. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>>> Later when there are multiple users of the Decoder I don't know how >>>>>>> you will fix this because those other users can run concurrently with >>>>>>> report_and_die(). That said I'm unclear what it is about the Decoder >>>>>>> that requires locking - what state does it maintain? Is there a >>>>>>> reason >>>>>>> not to create a Decoder only when needed? >>>>>>> >>>>>> Decoder is created on demand, but would prefer to be shared, since it >>>>>> can consume noticeable amount memory on Unix platform, by loading Elf >>>>>> files' symbol tables and string tables into memory (not impact on >>>>>> Windows). The lock is needed to protect a linked list structure in Elf >>>>>> decoder, or current file position. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>>> --- >>>>>>> >>>>>>> In decoder.cpp you can still use MutexLockerEx and as it will take a >>>>>>> null mutex and just act as a no-op eg: >>>>>>> >>>>>>> MutexLockerEx locker( _single_thread ? NULL : _decoder_lock, true); >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Please review >>>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/7141259/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Zhengyu >>>>>>>> From frederic.parain at oracle.com Thu Feb 9 09:11:12 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Thu, 09 Feb 2012 17:11:12 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120209171122.65A6847414@hg.openjdk.java.net> Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea677dbdd883 Merge From paul.hohensee at oracle.com Thu Feb 9 15:00:30 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 09 Feb 2012 18:00:30 -0500 Subject: Result: new HSX Committer: Staffan Larsen Message-ID: <4F34500E.9060709@oracle.com> Voting for Staffan Larsen [1] is now closed. Yes: 15 Veto: 0 Abstain: 24 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Regards, Paul Hohensee (phh) [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-January/005131.html [2] http://openjdk.java.net/bylaws#lazy-consensus From paul.hohensee at oracle.com Thu Feb 9 15:50:56 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 09 Feb 2012 18:50:56 -0500 Subject: Result: new HSX Committer: Staffan Larsen In-Reply-To: <4F34500E.9060709@oracle.com> References: <4F34500E.9060709@oracle.com> Message-ID: <4F345BE0.6060007@oracle.com> I've been reminded that "Abstain" may not be the same thing as "Did not vote". 24 Committers did not vote. There were no explicit abstentions. Paul On 2/9/12 6:00 PM, Paul Hohensee wrote: > Voting for Staffan Larsen [1] is now closed. > > Yes: 15 > Veto: 0 > Abstain: 24 > > According to the Bylaws definition of Lazy Consensus [2], this is > sufficient to > approve the nomination. > > Regards, > > Paul Hohensee (phh) > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-January/005131.html > [2] http://openjdk.java.net/bylaws#lazy-consensus > > > From paul.hohensee at oracle.com Thu Feb 9 16:09:13 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 09 Feb 2012 19:09:13 -0500 Subject: John Rose on premature optimization Message-ID: <4F346029.8060309@oracle.com> John posted a note on this subject on the compiler alias which I think is a reminder well worth reading. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-February/007177.html Thanks, John! Paul From john.coomes at oracle.com Thu Feb 9 20:33:56 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:33:56 +0000 Subject: hg: hsx/hotspot-main: 4 new changesets Message-ID: <20120210043357.253AC4742B@hg.openjdk.java.net> Changeset: 0f653ee93477 Author: alanb Date: 2012-01-24 09:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/0f653ee93477 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties Changeset: bd3fcc98c5d2 Author: lana Date: 2012-01-28 20:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/bd3fcc98c5d2 Merge Changeset: 221a378e06a3 Author: lana Date: 2012-02-07 10:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/221a378e06a3 Merge Changeset: 2accafff224a Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/2accafff224a Added tag jdk8-b25 for changeset 221a378e06a3 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:34:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:34:03 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b25 for changeset e45d6b406d5f Message-ID: <20120210043407.5DB994742C@hg.openjdk.java.net> Changeset: 79f709a099f4 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/79f709a099f4 Added tag jdk8-b25 for changeset e45d6b406d5f ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:34:13 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:34:13 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b25 for changeset bb694c151fc7 Message-ID: <20120210043414.041724742D@hg.openjdk.java.net> Changeset: dbb7283c197b Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/dbb7283c197b Added tag jdk8-b25 for changeset bb694c151fc7 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:34:20 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:34:20 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b25 for changeset b376d901e006 Message-ID: <20120210043420.EC3084742E@hg.openjdk.java.net> Changeset: 3518639eab6c Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/3518639eab6c Added tag jdk8-b25 for changeset b376d901e006 ! .hgtags From john.coomes at oracle.com Thu Feb 9 20:35:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 04:35:26 +0000 Subject: hg: hsx/hotspot-main/jdk: 47 new changesets Message-ID: <20120210044559.0B21247433@hg.openjdk.java.net> Changeset: ad9f1c8970da Author: prr Date: 2012-01-19 12:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ad9f1c8970da 7131153: GetDC called way too many times - causes bad performance. Reviewed-by: igor, jgodinez ! src/windows/native/sun/font/fontpath.c Changeset: f7dda4bbf1f9 Author: lana Date: 2012-01-28 22:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f7dda4bbf1f9 Merge - test/java/io/File/BlockIsDirectory.java Changeset: 84b153cd9bd4 Author: denis Date: 2012-01-19 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84b153cd9bd4 7121761: creation of java.awt.DataFlavour fails for turkish locale Reviewed-by: anthony ! src/share/classes/java/awt/datatransfer/MimeType.java Changeset: e32db6535c05 Author: alexsch Date: 2012-01-23 13:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e32db6535c05 7112854: [macosx] closed/javax/swing/JPopupMenu/Test6827786.java unstable on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6827786/bug6827786.java Changeset: cc88a9c0474f Author: alexsch Date: 2012-01-23 13:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc88a9c0474f 7116634: [macosx] closed/javax/swing/JTree/6263446/bug6263446Tree.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JTree/6263446/bug6263446.java Changeset: 19431d07bc19 Author: denis Date: 2012-01-23 17:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/19431d07bc19 7130140: using horizontal scroll button on mouse causes a message to be printed on stdout Reviewed-by: art ! src/share/classes/java/awt/event/MouseEvent.java Changeset: 5255fd5b0418 Author: denis Date: 2012-01-24 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5255fd5b0418 7078460: JDialog is shown as separate icon on the taskbar Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b4589ff4457c Author: malenkov Date: 2012-01-24 19:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4589ff4457c 7121905: grammatically incorrect apostrophe in BeanInfo javadoc Reviewed-by: rupashka ! src/share/classes/java/beans/BeanInfo.java Changeset: 4f2a2bf0ce84 Author: rupashka Date: 2012-01-26 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4f2a2bf0ce84 7010561: Tab text position with Synth based LaF is different to Java 5/6 Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7010561/bug7010561.java Changeset: cc9ff174a1c3 Author: alexsch Date: 2012-01-27 16:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc9ff174a1c3 7122173: [macosx] Several Regression tests fail on MacOS Reviewed-by: rupashka + test/javax/swing/SwingUtilities/4917669/bug4917669.java + test/javax/swing/plaf/basic/BasicHTML/4251579/bug4251579.java + test/javax/swing/text/html/CSS/4530474/bug4530474.java + test/javax/swing/text/html/CSS/4530474/test.css + test/javax/swing/text/html/CSS/4530474/test.html Changeset: 96b5999af66b Author: alexsch Date: 2012-01-27 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/96b5999af66b 7109962: [macosx] closed/javax/swing/JList/6462008/bug6462008.java fails on MacOS Reviewed-by: rupashka + test/javax/swing/JList/6462008/bug6462008.java Changeset: 6a7109f52966 Author: alexsch Date: 2012-01-27 17:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6a7109f52966 7105040: [macosx] closed/javax/swing/JPopupMenu/4966112/bug4966112.java deadlocks on MacOS Reviewed-by: rupashka + test/javax/swing/JPopupMenu/4966112/bug4966112.java Changeset: bc1c20ac8676 Author: chegar Date: 2012-01-27 13:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc1c20ac8676 7110002: Rename xawt/libmawt.so and headless/libmawt.so so they can be colocated with libawt Reviewed-by: art, prr, dholmes, alanb ! make/common/Release-embedded.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/jawt/Makefile ! make/sun/xawt/Makefile ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: 5dab2d55bc5b Author: lana Date: 2012-01-28 22:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5dab2d55bc5b Merge - test/java/io/File/BlockIsDirectory.java Changeset: 39b661c5867a Author: alexsch Date: 2012-01-30 12:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/39b661c5867a 7122149: [macosx] closed/javax/swing/UITest/UITest.java fails on MacOS Reviewed-by: rupashka ! src/share/classes/sun/awt/OSInfo.java + test/javax/swing/UITest/UITest.java Changeset: 7d6c7dd72e25 Author: malenkov Date: 2012-01-31 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d6c7dd72e25 7122138: IAE thrown because Introspector ignores synthetic methods Reviewed-by: rupashka ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/7122138/Test7122138.java + test/java/beans/Introspector/7122138/pack/Sub.java + test/java/beans/Introspector/7122138/pack/Super.java Changeset: c5c78f293ff8 Author: rupashka Date: 2012-01-31 17:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c5c78f293ff8 7082443: JComboBox not backward compatible (with Java 6) Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java + test/javax/swing/JComboBox/7082443/bug7082443.java Changeset: 363086137375 Author: lana Date: 2012-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/363086137375 Merge Changeset: 313da5d059bf Author: valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: 71200c517524 Author: darcy Date: 2012-01-20 17:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71200c517524 4504839: Java libraries should provide support for unsigned integer arithmetic 4215269: Some Integer.toHexString(int) results cannot be decoded back to an int 6322074: Converting integers to string as if unsigned Reviewed-by: mduigou, emcmanus, flar ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Integer/Unsigned.java + test/java/lang/Long/Unsigned.java Changeset: d383b5d128e3 Author: xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java Changeset: 3df0bd3ed880 Author: mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author: mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5e1ad6ad41b7 Merge Changeset: 914711cccc60 Author: darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/914711cccc60 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java Changeset: 237319a01a9a Author: alanb Date: 2012-01-24 09:09 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/237319a01a9a 7132204: Default testset in JPRT should not run all tests Reviewed-by: ohair ! make/jprt.properties ! test/ProblemList.txt Changeset: 718bca4e685f Author: rbackman Date: 2012-01-17 16:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/718bca4e685f 7132386: makefile support for tracing/Java Flight Recorder framework phase I Reviewed-by: ohair, dholmes, rottenha Contributed-by: Markus Gronlund , Erik Gahlin , Nils Loodin , Rickard Backman , Staffan Larsen ! make/com/oracle/Makefile + make/com/oracle/jfr/Makefile ! make/common/Defs.gmk ! make/common/Release.gmk Changeset: f64ea40293db Author: ksrini Date: 2012-01-24 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f64ea40293db 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win) Reviewed-by: alanb, chegar ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/TestHelper.java Changeset: 303b67074666 Author: lancea Date: 2012-01-24 15:13 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/303b67074666 7132879: address Findbugs issue in WebRowSetXmlWriter Reviewed-by: forax ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Changeset: ceab7e149581 Author: peytoia Date: 2012-01-26 17:06 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ceab7e149581 7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug7017458.java Changeset: 350971f50949 Author: rbackman Date: 2012-01-26 09:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/350971f50949 7133124: Remove redundant packages from JAR command line Reviewed-by: acorn, alanb, dholmes, rottenha ! make/common/Release.gmk Changeset: b518b160607f Author: lancea Date: 2012-01-26 19:41 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b518b160607f 7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl Reviewed-by: forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/BaseRow.java ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 5ee30ab905db Author: wetmore Date: 2012-01-26 17:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ee30ab905db 7126889: Incorrect SSLEngine debug output Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/EngineArgs.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh Changeset: 7aa5ddfa3c9d Author: okutsu Date: 2012-01-27 14:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7aa5ddfa3c9d 7130335: Problem with timezone in a SimpleDateFormat Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java + test/java/text/Format/DateFormat/Bug7130335.java Changeset: ff24779c147f Author: valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of "secrity". Reviewed-by: wetmore ! test/Makefile Changeset: 7dbc129d8e5c Author: ksrini Date: 2012-01-28 10:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7dbc129d8e5c 7127906: (launcher) convert the launcher regression tests to java Reviewed-by: darcy, naoto ! test/tools/launcher/Arrrghs.java + test/tools/launcher/ChangeDataModel.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java ! test/tools/launcher/DefaultLocaleTestRun.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/I18NJarTest.java + test/tools/launcher/I18NTest.java ! test/tools/launcher/MiscTests.java ! test/tools/launcher/Settings.java - test/tools/launcher/SomeException.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java - test/tools/launcher/UnicodeCleanup.java ! test/tools/launcher/UnicodeTest.java - test/tools/launcher/UnicodeTest.sh ! test/tools/launcher/UnresolvedExceptions.java - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 7a25b72b3644 Author: lana Date: 2012-01-28 20:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7a25b72b3644 Merge Changeset: f9fb8c4b4550 Author: dl Date: 2012-01-30 11:44 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f9fb8c4b4550 7132378: Race in FutureTask if used with explicit set ( not Runnable ) Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/FutureTask.java + test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java + test/java/util/concurrent/FutureTask/ExplicitSet.java Changeset: 863a20b0bf08 Author: ngmr Date: 2012-01-10 00:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/863a20b0bf08 7123229: (coll) EnumMap.containsValue(null) returns true Summary: java.util.EnumMap.NULL equals() must only be true for itself Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/UniqueNullValue.java Changeset: 13978750cb87 Author: ngmr Date: 2012-01-31 10:31 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/13978750cb87 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h Reviewed-by: alanb Contributed-by: Jonathan Lu ! src/solaris/native/java/lang/UNIXProcess_md.c Changeset: 431bc327f34a Author: sla Date: 2012-01-31 10:46 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/431bc327f34a 7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms Summary: Make sure HotSpot and JDK looks for well-known files in the same location Reviewed-by: dholmes, dsamersoff ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! test/ProblemList.txt Changeset: 663a6333105d Author: sla Date: 2012-01-31 04:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/663a6333105d Merge Changeset: 533bc0a10233 Author: lana Date: 2012-01-31 19:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/533bc0a10233 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: ce62fb7aa1b8 Author: lana Date: 2012-02-07 10:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce62fb7aa1b8 Merge - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 1a99dad28223 Author: yhuang Date: 2012-02-06 18:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a99dad28223 7129382: change minor unit of VND to 0 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! test/java/util/Currency/tablea1.txt Changeset: 930756e55285 Author: yhuang Date: 2012-02-06 18:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/930756e55285 Merge Changeset: ec17fbe5b8fb Author: katleman Date: 2012-02-08 19:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ec17fbe5b8fb Merge Changeset: 5aca406e87cb Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5aca406e87cb Added tag jdk8-b25 for changeset ec17fbe5b8fb ! .hgtags From john.coomes at oracle.com Thu Feb 9 21:27:57 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 05:27:57 +0000 Subject: hg: hsx/hotspot-main/langtools: 7 new changesets Message-ID: <20120210052815.8C31B47444@hg.openjdk.java.net> Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref Changeset: 7d412606d641 Author: lana Date: 2012-01-28 20:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7d412606d641 Merge Changeset: 520c30f85bb5 Author: lana Date: 2012-02-07 10:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/520c30f85bb5 Merge Changeset: b556aa8a99c3 Author: katleman Date: 2012-02-09 12:56 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b556aa8a99c3 Added tag jdk8-b25 for changeset 520c30f85bb5 ! .hgtags From john.r.rose at oracle.com Fri Feb 10 00:21:15 2012 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 10 Feb 2012 08:21:15 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120210082125.7C96F47454@hg.openjdk.java.net> Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2f985b6ce7ff Merge From christian.thalinger at oracle.com Fri Feb 10 02:48:36 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Feb 2012 11:48:36 +0100 Subject: RFR (S): 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk In-Reply-To: <165C8110-D994-4FD3-87A6-8232359BFFB3@oracle.com> References: <165C8110-D994-4FD3-87A6-8232359BFFB3@oracle.com> Message-ID: On Feb 8, 2012, at 8:14 PM, John Rose wrote: > Consider rolling in this debug help so "make gamma" works. > > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f21b335377b0 Done. I also added the target for Solaris and Linux, FWIW. webrev updated. -- Chris > > -- John (on my iPhone) > > On Feb 8, 2012, at 5:50 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7143766/ >> >> 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk >> Reviewed-by: >> >> I'd like to add the possibility to specify JDK_IMAGE_DIR via >> ALT_JDK_IMAGE_DIR. This is very helpful during development since it's >> possible to copy a JDK into a specified directory and export different >> VM builds to the same JDK. Doing this you don't have to change any >> paths (or command line arguments) but use the same java command, e.g.: >> >> $ make copy_product_jdk ALT_JDK_IMAGE_DIR=/foo/jdk >> $ make jvmg export_debug ALT_EXPORT_DIR=/foo/jdk >> >> And after all your bugs are fixed do a product build, export that and >> use the same java command: >> >> $ make product export_product ALT_EXPORT_DIR=/foo/jdk >> >> The changes for test_jdk make sure that the right VM is tested. This >> might not be the case when you are doing 64-bit builds on Solaris, >> export the VM and do a test_jdk: >> >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) Server VM (build 23.0-b12, mixed mode) >> >> What you actually want is to run the just-built 64-bit VM, like: >> >> $ make test_jdk LP64=1 >> INFO: no objcopy cmd found so cannot create .debuginfo files. >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -Xinternalversion >> Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-jvmg) for solaris-amd64 JRE (1.8.0), built on Feb 8 2012 04:26:02 by "ct232829" with Sun Studio 12u1 >> /export/twisti/build/hsx/hotspot-comp/hotspot/build/jdk-solaris/bin/java -d64 -server -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b24) >> Java HotSpot(TM) 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) >> >> I also added printing -Xinternalversion to test_jdk. This makes it >> easier to verify the installed VM is the one you just built (and want >> to test). >> >> make/Makefile >> make/bsd/makefiles/defs.make >> make/defs.make >> From christian.thalinger at oracle.com Fri Feb 10 07:10:29 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 10 Feb 2012 16:10:29 +0100 Subject: Request for review 7141200: log some interesting information in ring buffers for crashes In-Reply-To: <3554A634-9664-4DFA-BBC4-537008DC316B@oracle.com> References: <190D13C4-541E-470A-901F-EACB0D6A148C@oracle.com> <89EE5D00-CC05-4093-B149-A5173C281BDB@oracle.com> <3554A634-9664-4DFA-BBC4-537008DC316B@oracle.com> Message-ID: On Jan 31, 2012, at 6:05 PM, Tom Rodriguez wrote: > > On Jan 31, 2012, at 3:01 AM, Christian Thalinger wrote: > >> >> On Jan 31, 2012, at 8:50 AM, Tom Rodriguez wrote: >> >>> http://cr.openjdk.java.net/~never/7141200 >>> 664 lines changed: 389 ins; 185 del; 90 mod; 37188 unchg >>> >>> 7141200: log some interesting information in ring buffers for crashes >>> Reviewed-by: >> >> This looks good. Since you removed the debug methods to print the events I guess now the way to print them is to call Events::print_all. Could we have a default outputStream for easier calling in the debugger: >> >> + static void print_all(outputStream* out = tty); >> >> (Although in my experience this doesn't work very good in GDB.) > > I'll add something like that, probably Events::print. I think we should move the implementation of print to the .cpp file: (dbx) p Events::print() dbx: Events::print is missing in this scope (never defined or an inlined function) (dbx) p Events::print_all(tty) Compilation events (10 events): ... If you want I can add it to 7143766. -- Chris > >>> >>> There are some EventMarks in GC code that I'm tempted to delete. Any >>> objections? >>> >>> I put a couple example logs at: >>> >>> http://cr.openjdk.java.net/~never/7141200/example1.log >>> http://cr.openjdk.java.net/~never/7141200/example2.log >> >> Unfortunately these are not there. > > I think they got deleted by rsync. They are there now. > > tom > >> >> -- Chris >> >>> >>> I can produce others if needed. >>> >>> Performance seems to be largely unchanged according to refworkload but >>> I'm still running some benchmarks. Tested with JCK vm and lang, and >>> the nsk tests. >>> >>> >> > From tom.rodriguez at oracle.com Fri Feb 10 09:44:17 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 10 Feb 2012 09:44:17 -0800 Subject: Request for review 7141200: log some interesting information in ring buffers for crashes In-Reply-To: References: <190D13C4-541E-470A-901F-EACB0D6A148C@oracle.com> <89EE5D00-CC05-4093-B149-A5173C281BDB@oracle.com> <3554A634-9664-4DFA-BBC4-537008DC316B@oracle.com> Message-ID: On Feb 10, 2012, at 7:10 AM, Christian Thalinger wrote: > > On Jan 31, 2012, at 6:05 PM, Tom Rodriguez wrote: > >> >> On Jan 31, 2012, at 3:01 AM, Christian Thalinger wrote: >> >>> >>> On Jan 31, 2012, at 8:50 AM, Tom Rodriguez wrote: >>> >>>> http://cr.openjdk.java.net/~never/7141200 >>>> 664 lines changed: 389 ins; 185 del; 90 mod; 37188 unchg >>>> >>>> 7141200: log some interesting information in ring buffers for crashes >>>> Reviewed-by: >>> >>> This looks good. Since you removed the debug methods to print the events I guess now the way to print them is to call Events::print_all. Could we have a default outputStream for easier calling in the debugger: >>> >>> + static void print_all(outputStream* out = tty); >>> >>> (Although in my experience this doesn't work very good in GDB.) >> >> I'll add something like that, probably Events::print. > > I think we should move the implementation of print to the .cpp file: > > (dbx) p Events::print() > dbx: Events::print is missing in this scope (never defined or an inlined function) > (dbx) p Events::print_all(tty) > Compilation events (10 events): > ... > > If you want I can add it to 7143766. I've got a couple minor fixes for this so I'll include it there. tom > > -- Chris > >> >>>> >>>> There are some EventMarks in GC code that I'm tempted to delete. Any >>>> objections? >>>> >>>> I put a couple example logs at: >>>> >>>> http://cr.openjdk.java.net/~never/7141200/example1.log >>>> http://cr.openjdk.java.net/~never/7141200/example2.log >>> >>> Unfortunately these are not there. >> >> I think they got deleted by rsync. They are there now. >> >> tom >> >>> >>> -- Chris >>> >>>> >>>> I can produce others if needed. >>>> >>>> Performance seems to be largely unchanged according to refworkload but >>>> I'm still running some benchmarks. Tested with JCK vm and lang, and >>>> the nsk tests. >>>> >>>> >>> >> > From vladimir.danushevsky at oracle.com Fri Feb 10 11:40:55 2012 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Fri, 10 Feb 2012 19:40:55 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20120210194109.E6EE34746D@hg.openjdk.java.net> Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp From john.coomes at oracle.com Fri Feb 10 13:35:28 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Feb 2012 21:35:28 +0000 Subject: hg: hsx/hsx23/hotspot: 18 new changesets Message-ID: <20120210213606.4DD9047474@hg.openjdk.java.net> Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags Changeset: 3c4621be5149 Author: amurillo Date: 2012-02-06 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3c4621be5149 7143122: new hotspot build - hs23-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 869be5c8882e Author: phh Date: 2012-02-03 17:21 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/869be5c8882e 7142586: Cannot build on Solaris 11 due to use of ia_nice Summary: Delete the single use of ia_nice in os_solaris.cpp Reviewed-by: kamg, kvn ! src/os/solaris/vm/os_solaris.cpp Changeset: c77d473e71f7 Author: ohrstrom Date: 2012-01-31 13:12 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c77d473e71f7 7132779: build-infra merge: Enable ccache to work for most developer builds. Summary: When a build number is not specified, the JRE_RELEASE_VERSION define contains a date and timestamp. Thus ccache cannot cache the object files for longer than a minute since the define is passed to the compilation of all source files. This change passes JRE_RELEASE_VERSION only to vm_version.cpp and adds a function jre_release_version() to Abstract_VM_Version. This allows all other source files to be ccached. Reviewed-by: ohair, rottenha Contributed-by: fredrik.ohrstrom at oracle.com ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/vm.make ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 719f7007c8e8 Author: erikj Date: 2012-02-06 09:14 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/719f7007c8e8 7141242: build-infra merge: Rename CPP->CXX and LINK->LD Summary: Cleaned up make variables for compilers and linker to consistently use CXX for C++ compiler, CC for C compiler and LD for linker. Reviewed-by: dholmes, ohrstrom ! make/bsd/makefiles/adlc.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/launcher.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/rules.make ! make/bsd/makefiles/sparcWorks.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/launcher.make ! make/linux/makefiles/product.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sparcWorks.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/launcher.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/vm.make ! make/windows/build_vm_def.sh ! make/windows/get_msc_ver.sh ! make/windows/makefiles/adlc.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/launcher.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/shared.make ! make/windows/makefiles/vm.make Changeset: ea677dbdd883 Author: fparain Date: 2012-02-07 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ea677dbdd883 Merge Changeset: 5e9fba4e8718 Author: kvn Date: 2012-02-07 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/5e9fba4e8718 7142167: MAC: _get_previous_fp broken on bsd with llvm-gcc Summary: LLVM-GCC (__llvm__) should use the same _get_previous_fp implementation as __clang__ (as is the case for os::current_stack_pointer). Reviewed-by: twisti, never, dcubed ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: b9bc6cae88f2 Author: kvn Date: 2012-02-07 16:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b9bc6cae88f2 7143491: G1 C2 CTW: assert(p2x->outcnt() == 2) failed: expects 2 users: Xor and URShift nodes Summary: Adjust the assert and code in eliminate_card_mark() method for case when stored value is NULL. Reviewed-by: iveresov, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp Changeset: c742b0b47fe5 Author: roland Date: 2012-02-08 09:52 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c742b0b47fe5 7119286: JSR292: SIGSEGV in JNIHandleBlock::release_block(JNIHandleBlock*, Thread*)+0x3c Summary: unaligned stack in throw_NullPointerException_at_call_entry(). Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 2f985b6ce7ff Author: jrose Date: 2012-02-09 18:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2f985b6ce7ff Merge Changeset: 1ac084126285 Author: dlong Date: 2012-01-24 18:00 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1ac084126285 7130319: C2: running with -XX:+PrintOptoAssembly crashes the VM with assert(false) failed: bad tag in log Summary: Relax assert to allow the VMThread to close the log while the compiler thread is still writing to it. Reviewed-by: dholmes, never Contributed-by: dean.long at oracle.com ! src/share/vm/utilities/xmlstream.cpp Changeset: d851f3714641 Author: dholmes Date: 2012-01-25 19:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d851f3714641 Merge - src/os/bsd/vm/decoder_bsd.cpp Changeset: a79cb7c55012 Author: jiangli Date: 2012-01-25 17:40 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a79cb7c55012 7132690: InstanceKlass:_reference_type should be u1 type Summary: Change InstanceKlass::_reference_type to u1 type. Reviewed-by: dholmes, coleenp, acorn Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f3fa16bd7159 Author: bobv Date: 2012-01-25 21:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f3fa16bd7159 Merge Changeset: b7b8b6d2f97d Author: bpittore Date: 2012-02-06 10:57 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b7b8b6d2f97d Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f174909614bd Author: bpittore Date: 2012-02-10 10:55 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f174909614bd Merge ! src/share/vm/opto/library_call.cpp Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags From john.coomes at oracle.com Fri Feb 10 17:17:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 11 Feb 2012 01:17:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120211011751.5FF9547475@hg.openjdk.java.net> Changeset: aaceb8ddf2e2 Author: katleman Date: 2012-02-09 12:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aaceb8ddf2e2 Added tag jdk8-b25 for changeset 9ad8feb5afbd ! .hgtags Changeset: d71e662fe037 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d71e662fe037 Merge Changeset: fd3060701216 Author: amurillo Date: 2012-02-10 11:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd3060701216 Added tag hs23-b15 for changeset d71e662fe037 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version From christian.thalinger at oracle.com Mon Feb 13 02:34:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 13 Feb 2012 11:34:43 +0100 Subject: Request for review 7141200: log some interesting information in ring buffers for crashes In-Reply-To: References: <190D13C4-541E-470A-901F-EACB0D6A148C@oracle.com> <89EE5D00-CC05-4093-B149-A5173C281BDB@oracle.com> <3554A634-9664-4DFA-BBC4-537008DC316B@oracle.com> Message-ID: <4662DCE3-36F8-49F3-A56E-D75F52250F8E@oracle.com> On Feb 10, 2012, at 6:44 PM, Tom Rodriguez wrote: > > On Feb 10, 2012, at 7:10 AM, Christian Thalinger wrote: > >> >> On Jan 31, 2012, at 6:05 PM, Tom Rodriguez wrote: >> >>> >>> On Jan 31, 2012, at 3:01 AM, Christian Thalinger wrote: >>> >>>> >>>> On Jan 31, 2012, at 8:50 AM, Tom Rodriguez wrote: >>>> >>>>> http://cr.openjdk.java.net/~never/7141200 >>>>> 664 lines changed: 389 ins; 185 del; 90 mod; 37188 unchg >>>>> >>>>> 7141200: log some interesting information in ring buffers for crashes >>>>> Reviewed-by: >>>> >>>> This looks good. Since you removed the debug methods to print the events I guess now the way to print them is to call Events::print_all. Could we have a default outputStream for easier calling in the debugger: >>>> >>>> + static void print_all(outputStream* out = tty); >>>> >>>> (Although in my experience this doesn't work very good in GDB.) >>> >>> I'll add something like that, probably Events::print. >> >> I think we should move the implementation of print to the .cpp file: >> >> (dbx) p Events::print() >> dbx: Events::print is missing in this scope (never defined or an inlined function) >> (dbx) p Events::print_all(tty) >> Compilation events (10 events): >> ... >> >> If you want I can add it to 7143766. > > I've got a couple minor fixes for this so I'll include it there. You can also remove the event stuff from debug.cpp: diff --git a/src/share/vm/utilities/debug.cpp b/src/share/vm/utilities/debug.cpp --- a/src/share/vm/utilities/debug.cpp +++ b/src/share/vm/utilities/debug.cpp @@ -47,7 +47,6 @@ #include "runtime/vframe.hpp" #include "services/heapDumper.hpp" #include "utilities/defaultStream.hpp" -#include "utilities/events.hpp" #include "utilities/top.hpp" #include "utilities/vmError.hpp" #ifdef TARGET_OS_FAMILY_linux @@ -759,8 +758,6 @@ tty->print_cr("misc."); tty->print_cr(" flush() - flushes the log file"); - tty->print_cr(" events() - dump last 50 events"); - tty->print_cr("compiler debugging"); tty->print_cr(" debug() - to set things up for compiler debugging"); -- Chris > > tom > >> >> -- Chris >> >>> >>>>> >>>>> There are some EventMarks in GC code that I'm tempted to delete. Any >>>>> objections? >>>>> >>>>> I put a couple example logs at: >>>>> >>>>> http://cr.openjdk.java.net/~never/7141200/example1.log >>>>> http://cr.openjdk.java.net/~never/7141200/example2.log >>>> >>>> Unfortunately these are not there. >>> >>> I think they got deleted by rsync. They are there now. >>> >>> tom >>> >>>> >>>> -- Chris >>>> >>>>> >>>>> I can produce others if needed. >>>>> >>>>> Performance seems to be largely unchanged according to refworkload but >>>>> I'm still running some benchmarks. Tested with JCK vm and lang, and >>>>> the nsk tests. >>>>> >>>>> >>>> >>> >> > From gotischerose at yahoo.de Tue Feb 14 04:25:32 2012 From: gotischerose at yahoo.de (Maxym Pendyshchuk) Date: Tue, 14 Feb 2012 12:25:32 +0000 (GMT) Subject: PrintCFGToFile jvm option.. where to find a file printed? Message-ID: <1329222332.11051.YahooMailNeo@web24604.mail.ird.yahoo.com> I made a debug build of OPENJDK 7.0.2 (for Ubuntu 11.10 OS, if matters). Now I want to see a control flow graph information, I run a command: java -XX:+PrintCFGToFile Test in console I get "VM option '+PrintCFGToFile'", but no file is created... In CFGPrinter (if I'm not wrong with class), I see that file has name output.cfg, I looked for such a file on the file system, but didn't find it. Do I miss additional options? In documentation I saw examples only with one option... Is it a bug, or I do something wrong? Thank you for any information.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120214/ed10a11c/attachment.html From christian.thalinger at oracle.com Tue Feb 14 04:45:43 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 14 Feb 2012 13:45:43 +0100 Subject: PrintCFGToFile jvm option.. where to find a file printed? In-Reply-To: <1329222332.11051.YahooMailNeo@web24604.mail.ird.yahoo.com> References: <1329222332.11051.YahooMailNeo@web24604.mail.ird.yahoo.com> Message-ID: <289F2E5E-CA28-4E28-9E47-1B523ADA51A7@oracle.com> On Feb 14, 2012, at 1:25 PM, Maxym Pendyshchuk wrote: > I made a debug build of OPENJDK 7.0.2 (for Ubuntu 11.10 OS, if matters). Now I want to see a control flow graph information, I run a command: > > java -XX:+PrintCFGToFile Test > > in console I get "VM option '+PrintCFGToFile'", but no file is created... In CFGPrinter (if I'm not wrong with class), I see that file has name output.cfg, I looked for such a file on the file system, but didn't find it. Do I miss additional options? In documentation I saw examples only with one option... Is it a bug, or I do something wrong? Thank you for any information.. It works for me: $ java -XX:+PrintCompilation -XX:+PrintCFGToFile -version 718 1 3 java.lang.String::equals (88 bytes) openjdk version "1.7.0-ea" OpenJDK Runtime Environment (build 1.7.0-ea-b221) OpenJDK 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) $ cat output.cfg begin_compilation name " java.lang.String::equals" method "virtual jboolean java.lang.String.equals(jobject)" date 1329223300664 end_compilation begin_cfg name "BlockListBuilder virtual jboolean java.lang.String.equals(jobject)" begin_block name "B0" from_bci 0 to_bci -1 predecessors successors "B1" "B2" xhandlers flags "std" end_block Are you actually using C1? -- Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120214/1b3c6508/attachment.html From rednaxelafx at gmail.com Tue Feb 14 05:01:16 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 14 Feb 2012 21:01:16 +0800 Subject: PrintCFGToFile jvm option.. where to find a file printed? In-Reply-To: <289F2E5E-CA28-4E28-9E47-1B523ADA51A7@oracle.com> References: <1329222332.11051.YahooMailNeo@web24604.mail.ird.yahoo.com> <289F2E5E-CA28-4E28-9E47-1B523ADA51A7@oracle.com> Message-ID: Hi Maxym, +1 with Christian. If you're running OpenJDK 7 on 64-bit Ubuntu, you're probably using only the server compiler (C2) instead of the client compiler (C1). PrintCFGToFile is only for C1. You might want to turn on -XX:+TieredCompilation if you really want to see this flag working, on you're current platform. - Kris On Tue, Feb 14, 2012 at 8:45 PM, Christian Thalinger < christian.thalinger at oracle.com> wrote: > > On Feb 14, 2012, at 1:25 PM, Maxym Pendyshchuk wrote: > > I made a debug build of OPENJDK 7.0.2 (for Ubuntu 11.10 OS, if matters). > Now I want to see a control flow graph information, I run a command: > > java -XX:+PrintCFGToFile Test > > in console I get "VM option '+PrintCFGToFile'", but no file is created... > In CFGPrinter (if I'm not wrong with class), I see that file has name > output.cfg, I looked for such a file on the file system, but didn't find > it. Do I miss additional options? In documentation I saw examples only with > one option... Is it a bug, or I do something wrong? Thank you for any > information.. > > > It works for me: > > $ java -XX:+PrintCompilation -XX:+PrintCFGToFile -version > 718 1 3 java.lang.String::equals (88 bytes) > openjdk version "1.7.0-ea" > OpenJDK Runtime Environment (build 1.7.0-ea-b221) > OpenJDK 64-Bit Server VM (build 23.0-b15-internal-jvmg, mixed mode) > $ cat output.cfg > begin_compilation > name " java.lang.String::equals" > method "virtual jboolean java.lang.String.equals(jobject)" > date 1329223300664 > end_compilation > begin_cfg > name "BlockListBuilder virtual jboolean java.lang.String.equals(jobject)" > begin_block > name "B0" > from_bci 0 > to_bci -1 > predecessors > successors "B1" "B2" > xhandlers > flags "std" > end_block > > > Are you actually using C1? > > -- Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120214/33b14ddd/attachment.html From vladimir.danushevsky at oracle.com Wed Feb 15 18:56:19 2012 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Thu, 16 Feb 2012 02:56:19 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20120216025628.E38E54750F@hg.openjdk.java.net> Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f9961b6498f9 Merge From james.melvin at oracle.com Thu Feb 16 11:43:51 2012 From: james.melvin at oracle.com (James Melvin) Date: Thu, 16 Feb 2012 14:43:51 -0500 Subject: RFR (XXS): 7118647: compressed oops crashes on MacOS X with JPRT GCBasher test Message-ID: <4F3D5C77.6010200@oracle.com> Hi, Please review this change to fix and re-enable Compressed OOPs support on Mac OS X. The solution for now is to relax the problem assertion to simply check for COOP mode rather than an exact address. This should be sufficient until zero-based addressing logic can be refined. WEBREV: http://cr.openjdk.java.net/~jmelvin/7118647/webrev.00 TESTS: Successfully reran the failing testcase Confirmed COOPs was enabled with and without -XX:+UseCompressedOops Thanks to Vladimir Kozlov and Coleen Phillimore for their support! Jim From vladimir.kozlov at oracle.com Thu Feb 16 11:48:25 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Feb 2012 11:48:25 -0800 Subject: RFR (XXS): 7118647: compressed oops crashes on MacOS X with JPRT GCBasher test In-Reply-To: <4F3D5C77.6010200@oracle.com> References: <4F3D5C77.6010200@oracle.com> Message-ID: <4F3D5D89.2000606@oracle.com> Looks good. Vladimir James Melvin wrote: > Hi, > > Please review this change to fix and re-enable Compressed OOPs support > on Mac OS X. The solution for now is to relax the problem assertion to > simply check for COOP mode rather than an exact address. This should be > sufficient until zero-based addressing logic can be refined. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7118647/webrev.00 > > TESTS: > Successfully reran the failing testcase > Confirmed COOPs was enabled with and without -XX:+UseCompressedOops > > Thanks to Vladimir Kozlov and Coleen Phillimore for their support! > > Jim From paul.hohensee at oracle.com Thu Feb 16 12:05:00 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Thu, 16 Feb 2012 15:05:00 -0500 Subject: RFR (XXS): 7118647: compressed oops crashes on MacOS X with JPRT GCBasher test In-Reply-To: <4F3D5C77.6010200@oracle.com> References: <4F3D5C77.6010200@oracle.com> Message-ID: <4F3D616C.9050301@oracle.com> Looks good. Paul On 2/16/12 2:43 PM, James Melvin wrote: > Hi, > > Please review this change to fix and re-enable Compressed OOPs support > on Mac OS X. The solution for now is to relax the problem assertion to > simply check for COOP mode rather than an exact address. This should be > sufficient until zero-based addressing logic can be refined. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7118647/webrev.00 > > TESTS: > Successfully reran the failing testcase > Confirmed COOPs was enabled with and without -XX:+UseCompressedOops > > Thanks to Vladimir Kozlov and Coleen Phillimore for their support! > > Jim From daniel.daugherty at oracle.com Thu Feb 16 12:36:00 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Feb 2012 13:36:00 -0700 Subject: RFR (XXS): 7118647: compressed oops crashes on MacOS X with JPRT GCBasher test In-Reply-To: <4F3D5C77.6010200@oracle.com> References: <4F3D5C77.6010200@oracle.com> Message-ID: <4F3D68B0.2050707@oracle.com> Please change copyright year in virtualspace.cpp. Thumbs up. Dan On 2/16/12 12:43 PM, James Melvin wrote: > Hi, > > Please review this change to fix and re-enable Compressed OOPs support > on Mac OS X. The solution for now is to relax the problem assertion to > simply check for COOP mode rather than an exact address. This should be > sufficient until zero-based addressing logic can be refined. > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7118647/webrev.00 > > TESTS: > Successfully reran the failing testcase > Confirmed COOPs was enabled with and without -XX:+UseCompressedOops > > Thanks to Vladimir Kozlov and Coleen Phillimore for their support! > > Jim From ysr1729 at gmail.com Thu Feb 16 12:42:45 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 16 Feb 2012 12:42:45 -0800 Subject: cost of Java "assert" when disabled? Message-ID: A Java language newbie question: Does anyone have any ballpark numbers on the cost (and its scaling) of peppering assert's in your Java code, but with asserts disabled (-da) ? In other words, is the disabled cost so vanishingly small that we need not think twice when using them, or should one be careful because the cost is non-negligible and can affect (bytecode) footprint or rutime performace even when switched off? thanks for any advice. -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/65f8f48c/attachment.html From john.pampuch at oracle.com Thu Feb 16 13:41:15 2012 From: john.pampuch at oracle.com (John Pampuch) Date: Thu, 16 Feb 2012 13:41:15 -0800 Subject: cost of Java "assert" when disabled? In-Reply-To: References: Message-ID: <4F3D77FB.1050500@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/18a5cfa0/attachment.html From vitalyd at gmail.com Thu Feb 16 13:59:36 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Feb 2012 16:59:36 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: <4F3D77FB.1050500@oracle.com> References: <4F3D77FB.1050500@oracle.com> Message-ID: I think one problem with them is that they count towards the inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays. Sent from my phone On Feb 16, 2012 4:44 PM, "John Pampuch" wrote: > ** > Ramki- > > My rather ancient understanding is that properly structured assertions are > near zero cost when they are turned off. Perhaps someone knows of some > tests that confirm this? > > -John > > On 2/16/12 12:42 PM, Srinivas Ramakrishna wrote: > > A Java language newbie question: > > Does anyone have any ballpark numbers on the cost (and its scaling) of > peppering assert's in your Java code, but with asserts disabled (-da) ? > In other words, is the disabled cost so vanishingly small that we need not > think twice when using them, or should one be > careful because the cost is non-negligible and can affect (bytecode) > footprint or rutime performace even when switched off? > > thanks for any advice. > -- ramki > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/d64c09bf/attachment.html From john.r.rose at oracle.com Thu Feb 16 14:14:48 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Feb 2012 14:14:48 -0800 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> Message-ID: <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > I think one problem with them is that they count towards the inlining budget since their bytecodes still take up space. Not sure if newer C1/C2 compiler builds are "smarter" about this nowadays. Optimized object code has (probably) no trace of the assertions themselves, but as Vitaly said, they perturb the inlining budget. Larger methods have a tendency to "discourage" the inliner from inlining, causing more out-of-line calls and a rough net slowdown. Currently, the non-executed bytecodes for assertions (which can be arbitrarily complex) make methods look bigger than they really are. This is (IMO) a bug in the inlining heuristics, which should be fixed by examining inlining candidates with a little more care. Since the escape analysis does a similar method summarization, there isn't necessarily even a need for an extra pass over the methods. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/d3039070/attachment.html From gotischerose at yahoo.de Thu Feb 16 14:20:18 2012 From: gotischerose at yahoo.de (Maxym Pendyshchuk) Date: Thu, 16 Feb 2012 22:20:18 +0000 (GMT) Subject: cost of Java "assert" when disabled? In-Reply-To: References: Message-ID: <1329430818.5914.YahooMailNeo@web24601.mail.ird.yahoo.com> In "A Simple Assertion Facility For the Javatm Programming Language" ( java.sun.com/docs/books/jls/assert-spec.html ) is mentioned (Appendix IV, Implementation Notes), that assert is actually just a sugar (ok, that's my understanding of what is mentioned there), You write SomeClass { ??? public void someMethod() { ??? ??? assert condition : message; ??? } } and compiler does: SomeClass { ??? static final boolean $assertionsDisabled = !SomeClass.class.desiredAssertionStatus(); ??? public void someMethod() { ??? ??? if ( ! ( $assertionsDisabled || condition ) ) ??? ??? ??? throw new java.lang.AssertionError( message ); ??? ??? } ??? } } so you still have if-block even if assert is disabled, but HotSpot quickly can find out that this block is never executed, and in runtime it will be thrown away if this method is "hot", otherwise if this method is not executed frequently, then there is no drawback anyway... hope somebody will correct me if I am wrong Max ________________________________ Von: Srinivas Ramakrishna An: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Gesendet: 22:42 Donnerstag, 16.Februar 2012 Betreff: cost of Java "assert" when disabled? A Java language newbie question: Does anyone have any ballpark numbers on the cost (and its scaling) of peppering assert's in your Java code, but with asserts disabled (-da) ? In other words, is the disabled cost so vanishingly small that we need not think twice when using them, or should one be careful because the cost is non-negligible and can affect (bytecode) footprint or rutime performace even when switched off? thanks for any advice. -- ramki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/ec77f641/attachment-0001.html From vitalyd at gmail.com Thu Feb 16 14:21:56 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Feb 2012 17:21:56 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: Don't want to sidetrack this thread but I really wish javac had proper conditional compilation support, which would make this issue mostly moot. Sent from my phone On Feb 16, 2012 5:14 PM, "John Rose" wrote: > On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > > I think one problem with them is that they count towards the inlining > budget since their bytecodes still take up space. Not sure if newer C1/C2 > compiler builds are "smarter" about this nowadays. > > > Optimized object code has (probably) no trace of the assertions > themselves, but as Vitaly said, they perturb the inlining budget. Larger > methods have a tendency to "discourage" the inliner from inlining, causing > more out-of-line calls and a rough net slowdown. Currently, the > non-executed bytecodes for assertions (which can be arbitrarily complex) > make methods look bigger than they really are. This is (IMO) a bug in the > inlining heuristics, which should be fixed by examining inlining candidates > with a little more care. Since the escape analysis does a similar method > summarization, there isn't necessarily even a need for an extra pass over > the methods. > > -- John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/e62f9131/attachment.html From david.holmes at oracle.com Thu Feb 16 15:15:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 09:15:39 +1000 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: <4F3D8E1B.8000305@oracle.com> The corelibs side of things seems to have gotten dropped from the cc list - added back. On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > Don't want to sidetrack this thread but I really wish javac had proper > conditional compilation support, which would make this issue mostly moot. But the whole point of Java assertions is to make them available at runtime. I seem to recall a very similar question only recently on the core-libs mailing list. So summary is: - Every assert requires checking if asserts are enabled - JIT Compiler can elide the checks - Presence of assert related bytecodes can impact JIT compiler inlining decisions David > Sent from my phone > > On Feb 16, 2012 5:14 PM, "John Rose" > wrote: > > On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > >> I think one problem with them is that they count towards the >> inlining budget since their bytecodes still take up space. Not >> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. > > Optimized object code has (probably) no trace of the assertions > themselves, but as Vitaly said, they perturb the inlining budget. > Larger methods have a tendency to "discourage" the inliner from > inlining, causing more out-of-line calls and a rough net slowdown. > Currently, the non-executed bytecodes for assertions (which can be > arbitrarily complex) make methods look bigger than they really are. > This is (IMO) a bug in the inlining heuristics, which should be > fixed by examining inlining candidates with a little more care. > Since the escape analysis does a similar method summarization, > there isn't necessarily even a need for an extra pass over the methods. > > -- John > From vitalyd at gmail.com Thu Feb 16 15:40:04 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 16 Feb 2012 18:40:04 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: <4F3D8E1B.8000305@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: The asserts can be enabled/disabled at startup time, but I don't consider that an advantage over conditional compilation. In fact, it's less convenient in some cases, e.g. you can't conditionally add/remove class fields, can't surround blocks of code with condition, etc. There are workarounds, but it's not ideal. C#/.Net have conditional compilation (conditional blocks + assert statements) and it's a handy tool and no need to worry about dead IL code causing opto issues - don't see a reason why java couldn't have done the same from the beginning. Sent from my phone On Feb 16, 2012 6:16 PM, "David Holmes" wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > >> Don't want to sidetrack this thread but I really wish javac had proper >> conditional compilation support, which would make this issue mostly moot. >> > > But the whole point of Java assertions is to make them available at > runtime. I seem to recall a very similar question only recently on the > core-libs mailing list. > > So summary is: > > - Every assert requires checking if asserts are enabled > - JIT Compiler can elide the checks > - Presence of assert related bytecodes can impact JIT compiler inlining > decisions > > David > > Sent from my phone >> >> On Feb 16, 2012 5:14 PM, "John Rose" > > wrote: >> >> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >> >> I think one problem with them is that they count towards the >>> inlining budget since their bytecodes still take up space. Not >>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>> >> >> Optimized object code has (probably) no trace of the assertions >> themselves, but as Vitaly said, they perturb the inlining budget. >> Larger methods have a tendency to "discourage" the inliner from >> inlining, causing more out-of-line calls and a rough net slowdown. >> Currently, the non-executed bytecodes for assertions (which can be >> arbitrarily complex) make methods look bigger than they really are. >> This is (IMO) a bug in the inlining heuristics, which should be >> fixed by examining inlining candidates with a little more care. >> Since the escape analysis does a similar method summarization, >> there isn't necessarily even a need for an extra pass over the methods. >> >> -- John >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/87c5304c/attachment.html From ysr1729 at gmail.com Thu Feb 16 16:39:48 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Thu, 16 Feb 2012 16:39:48 -0800 Subject: cost of Java "assert" when disabled? In-Reply-To: <4F3D8E1B.8000305@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: Thanks to all for the prompt and enlightening discussion, and especially to David for the succinct summary. -- ramki On Thu, Feb 16, 2012 at 3:15 PM, David Holmes wrote: > The corelibs side of things seems to have gotten dropped from the cc list > - added back. > > > On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: > >> Don't want to sidetrack this thread but I really wish javac had proper >> conditional compilation support, which would make this issue mostly moot. >> > > But the whole point of Java assertions is to make them available at > runtime. I seem to recall a very similar question only recently on the > core-libs mailing list. > > So summary is: > > - Every assert requires checking if asserts are enabled > - JIT Compiler can elide the checks > - Presence of assert related bytecodes can impact JIT compiler inlining > decisions > > David > > Sent from my phone >> >> On Feb 16, 2012 5:14 PM, "John Rose" > > wrote: >> >> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >> >> I think one problem with them is that they count towards the >>> inlining budget since their bytecodes still take up space. Not >>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>> >> >> Optimized object code has (probably) no trace of the assertions >> themselves, but as Vitaly said, they perturb the inlining budget. >> Larger methods have a tendency to "discourage" the inliner from >> inlining, causing more out-of-line calls and a rough net slowdown. >> Currently, the non-executed bytecodes for assertions (which can be >> arbitrarily complex) make methods look bigger than they really are. >> This is (IMO) a bug in the inlining heuristics, which should be >> fixed by examining inlining candidates with a little more care. >> Since the escape analysis does a similar method summarization, >> there isn't necessarily even a need for an extra pass over the methods. >> >> -- John >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120216/f3d06788/attachment.html From david.holmes at oracle.com Thu Feb 16 17:27:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Feb 2012 11:27:36 +1000 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> <4F3D8E1B.8000305@oracle.com> Message-ID: <4F3DAD08.9020502@oracle.com> On 17/02/2012 9:40 AM, Vitaly Davidovich wrote: > The asserts can be enabled/disabled at startup time, but I don't consider > that an advantage over conditional compilation. In fact, it's less > convenient in some cases, e.g. you can't conditionally add/remove class > fields, can't surround blocks of code with condition, etc. There are > workarounds, but it's not ideal. I'm not going to get drawn into the whole "conditional compilation is [not] evil" debate. :) If I recall correctly the suggested buld-time idiom was to do: static final boolean ASSERT = true; // or false ... if (ASSERT) assert ... that way you could compile with ASSERT set true to get assertions in the code; or false to have them elided by javac. > C#/.Net have conditional compilation (conditional blocks + assert > statements) and it's a handy tool and no need to worry about dead IL code > causing opto issues - don't see a reason why java couldn't have done the > same from the beginning. Simply because the people defining the language didn't want it. I suspect there's a blog or two out there somewhere discussing this. David ----- > > Sent from my phone > On Feb 16, 2012 6:16 PM, "David Holmes" wrote: > >> The corelibs side of things seems to have gotten dropped from the cc list >> - added back. >> >> On 17/02/2012 8:21 AM, Vitaly Davidovich wrote: >> >>> Don't want to sidetrack this thread but I really wish javac had proper >>> conditional compilation support, which would make this issue mostly moot. >>> >> >> But the whole point of Java assertions is to make them available at >> runtime. I seem to recall a very similar question only recently on the >> core-libs mailing list. >> >> So summary is: >> >> - Every assert requires checking if asserts are enabled >> - JIT Compiler can elide the checks >> - Presence of assert related bytecodes can impact JIT compiler inlining >> decisions >> >> David >> >> Sent from my phone >>> >>> On Feb 16, 2012 5:14 PM, "John Rose">> > wrote: >>> >>> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >>> >>> I think one problem with them is that they count towards the >>>> inlining budget since their bytecodes still take up space. Not >>>> sure if newer C1/C2 compiler builds are "smarter" about this nowadays. >>>> >>> >>> Optimized object code has (probably) no trace of the assertions >>> themselves, but as Vitaly said, they perturb the inlining budget. >>> Larger methods have a tendency to "discourage" the inliner from >>> inlining, causing more out-of-line calls and a rough net slowdown. >>> Currently, the non-executed bytecodes for assertions (which can be >>> arbitrarily complex) make methods look bigger than they really are. >>> This is (IMO) a bug in the inlining heuristics, which should be >>> fixed by examining inlining candidates with a little more care. >>> Since the escape analysis does a similar method summarization, >>> there isn't necessarily even a need for an extra pass over the methods. >>> >>> -- John >>> >>> From john.coomes at oracle.com Thu Feb 16 20:32:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:32:31 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b26 for changeset 2accafff224a Message-ID: <20120217043231.24B454753B@hg.openjdk.java.net> Changeset: 1533dfab9903 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/1533dfab9903 Added tag jdk8-b26 for changeset 2accafff224a ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:32:37 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:32:37 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b26 for changeset 79f709a099f4 Message-ID: <20120217043240.E9F864753C@hg.openjdk.java.net> Changeset: 4fffe75e4edd Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4fffe75e4edd Added tag jdk8-b26 for changeset 79f709a099f4 ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:32:47 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:32:47 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b26 for changeset dbb7283c197b Message-ID: <20120217043247.D6B604753D@hg.openjdk.java.net> Changeset: 80c47eb83d24 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/80c47eb83d24 Added tag jdk8-b26 for changeset dbb7283c197b ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:32:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:32:54 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b26 for changeset 3518639eab6c Message-ID: <20120217043254.AA4274753E@hg.openjdk.java.net> Changeset: 329ace7198ac Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/329ace7198ac Added tag jdk8-b26 for changeset 3518639eab6c ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:33:03 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:33:03 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b26 for changeset 5aca406e87cb Message-ID: <20120217043350.0CFF84753F@hg.openjdk.java.net> Changeset: 4196fc971f65 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4196fc971f65 Added tag jdk8-b26 for changeset 5aca406e87cb ! .hgtags From john.coomes at oracle.com Thu Feb 16 20:35:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 17 Feb 2012 04:35:07 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b26 for changeset b556aa8a99c3 Message-ID: <20120217043513.53EF747540@hg.openjdk.java.net> Changeset: fba3cbee0fa3 Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fba3cbee0fa3 Added tag jdk8-b26 for changeset b556aa8a99c3 ! .hgtags From Dmitry.Samersoff at oracle.com Fri Feb 17 02:49:09 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 17 Feb 2012 14:49:09 +0400 Subject: cost of Java "assert" when disabled? In-Reply-To: References: Message-ID: <4F3E30A5.2050603@oracle.com> Ramki, Please notice: a) asserts causes new object allocation, stackmaptable and exception table grows. Bytecodes for: int value = 10; assert false : value; 0: bipush 10 2: istore_1 3: getstatic #2; //Field $assertionsDisabled:Z 6: ifne 18 9: new #3; //class java/lang/AssertionError 12: dup 13: iload_1 14: invokespecial #4; //Method java/lang/AssertionError."":(I)V 17: athrow b) assert MyClass.openFile(); cause that openFile() will never be executed if assertions is disabled. So you have to write: bool value = MyClass.openFile(); assert value; c) code below assert false : System.err.println("False"); will not ever compile, because System.err.println is void. so you have to write try{ assert false : "False"; } catch(AssertionError ex){ System.err.println(ex); } and then rely on C1/C2 to eliminate useless code. ** IMHO, counting all above it's better to write your own function MyAssert doing exactly what you need rather than use build-in one. ** Sidestepping to conditional compilation - I vote for it with both hands. -Dmitry On 2012-02-17 00:42, Srinivas Ramakrishna wrote: > A Java language newbie question: > > Does anyone have any ballpark numbers on the cost (and its scaling) of > peppering assert's in your Java code, but with asserts disabled (-da) ? > In other words, is the disabled cost so vanishingly small that we need > not think twice when using them, or should one be > careful because the cost is non-negligible and can affect (bytecode) > footprint or rutime performace even when switched off? > > thanks for any advice. > -- ramki -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From nils.loodin at oracle.com Fri Feb 17 03:21:37 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Fri, 17 Feb 2012 12:21:37 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4F15951D.7080508@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> Message-ID: <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> Sooo, what happened with this? I think that testing this framework would be an excellent fit for using in testing our diagnostic framework. But it kind of depends on this being actually checked in :) /Nisse On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: > David, > > On 2012-01-13 00:00, David Holmes wrote: >> Hi Mikael, >> >> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>> wbapi.java: normal Java naming style is to use camel-case for class >>>> names. Though as WB is itself an acronym I'd be okay with WBApi. In fact >>>> I'd be happy with anything other than initial lower-case :) >>> >>> Many of our existing tests have lower-case names so I guess I thought >>> that was some sort of convention, it does not really matter to me. >> >> I think those tests must have been written by C programers ;-) >> >>> WBApi it is then. >> >> Thanks.There is a slight typo in that the file is WBapi.java not WBApi.java > > Fixed. > > I also re-ran JPRT to verify that it still builds on all platforms and found that the size of a region in G1 had changed to size_t, so I added a cast to jint (region sizes of >2G seems to be unreasonable). > > I also tried with Jim Melvin's patch to run OS X and verified that "wbapitest" works on OS X as well. > > /Mikael > >> >> David >> ----- >> >>> >>>> >>>> --- >>>> >>>> test/Makefile: does wbapitest need to be added to the phoney list? >>> >>> Yes, fixed. >>> >>> New webrev at: >>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>> Incremental at: >>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>> >>> /Mikael >>> >>>> >>>> --- >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> >>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>> Hi all >>>>> >>>>> Back from vacations now with an updated version of the webrev based on >>>>> the feedback received in this thread. >>>>> Changes include: >>>>> * removed install target from makefiles >>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add wb.jar to >>>>> the boot class path from inside the VM. >>>>> >>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>> >>>>> Thanks >>>>> Mikael Gerdin >>>>> >>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>> Hi >>>>>> >>>>>> I've been working on a white box testing API for HotSpot in order to >>>>>> allow for improved precision in vm testing. >>>>>> >>>>>> The basic idea is to open up the possibility for tests written in Java >>>>>> to call native methods which query or poke the vm in some way. >>>>>> >>>>>> The API is accessible by using the class sun/hotspot/WhiteBox which is >>>>>> not intended to be available in public builds. >>>>>> In order to allow the WhiteBox class access to the VM the >>>>>> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. >>>>>> That >>>>>> function then links all the implementation functions using normal JNI >>>>>> RegisterNatives. >>>>>> >>>>>> The API is not meant to be used by end users for any intent or purpose >>>>>> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions >>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will not be >>>>>> present in an end user build of a JDK. >>>>>> If the VM crashes after this API has been accessed a note will be >>>>>> written in the hs_err file to signal that the API has been used. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>> (thanks to stefank for hosting my webrev :) >>>>>> >>>>>> CR: >>>>>> I'll file a CR tomorrow. >>>>>> >>>>>> Change comments: >>>>>> >>>>>> make/jprt.properties >>>>>> >>>>>> Add a test target to make sure that the API is available on all >>>>>> supported platforms >>>>>> >>>>>> make/** >>>>>> >>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>>>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>>>> targets. >>>>>> The BSD makefile changes are not tested since I don't have access to >>>>>> any >>>>>> BSD/OSX machine to test them on. >>>>>> >>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>> >>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>> link it >>>>>> to JVM_RegisterWhiteBoxMethods >>>>>> >>>>>> src/share/vm/prims/whitebox.* >>>>>> >>>>>> The implementation of the white box API. The actual API functions are >>>>>> only examples of what we want to be able to do using the API. >>>>>> >>>>>> src/share/vm/runtime/globals.hpp >>>>>> >>>>>> Add the command line flag >>>>>> >>>>>> src/share/vm/utilities/vmError.cpp >>>>>> >>>>>> Print a message in hs_err files when white box API has been used. >>>>>> >>>>>> test/Makefile >>>>>> >>>>>> Add a makefile test target for the white box API test >>>>>> >>>>>> test/sanity/wbapi.java >>>>>> >>>>>> JTreg test to ensure that the API works. >>>>>> >>>>>> >>>>>> Thanks >>>>>> /Mikael Gerdin >>>>> From stefan.karlsson at oracle.com Fri Feb 17 06:29:06 2012 From: stefan.karlsson at oracle.com (stefan.karlsson at oracle.com) Date: Fri, 17 Feb 2012 14:29:06 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20120217142920.E859C47563@hg.openjdk.java.net> Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/be398bba40e9 Merge From vitalyd at gmail.com Fri Feb 17 06:37:58 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Feb 2012 09:37:58 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: John, Doing smarter analysis for inlining decisions would be great. The other problem today is that people sometimes create "unnecessary" locals with SuppressWarnings annotation when cleaning up generics usage (this was discussed during Oracle's warning cleanup day). I guess more generally, some locals can be be folded or optimized out in the generated machine code, but currently can prevent inlining. Is this something that you guys are planning on enhancing? You mention that you think it's a bug, but unclear on whether there's commitment to fixing it. :) Also, is the (default) 35 bc length fixed or is it adjusted higher for very hot methods? The perf wiki mentions that inlining decision is made at parse time, which sounds like it's fixed but just wanted to double check. Thanks Sent from my phone On Feb 16, 2012 5:14 PM, "John Rose" wrote: > On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: > > I think one problem with them is that they count towards the inlining > budget since their bytecodes still take up space. Not sure if newer C1/C2 > compiler builds are "smarter" about this nowadays. > > > Optimized object code has (probably) no trace of the assertions > themselves, but as Vitaly said, they perturb the inlining budget. Larger > methods have a tendency to "discourage" the inliner from inlining, causing > more out-of-line calls and a rough net slowdown. Currently, the > non-executed bytecodes for assertions (which can be arbitrarily complex) > make methods look bigger than they really are. This is (IMO) a bug in the > inlining heuristics, which should be fixed by examining inlining candidates > with a little more care. Since the escape analysis does a similar method > summarization, there isn't necessarily even a need for an extra pass over > the methods. > > -- John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/e120243c/attachment.html From ionionascu at gmail.com Fri Feb 17 06:44:12 2012 From: ionionascu at gmail.com (Ion Ionascu) Date: Fri, 17 Feb 2012 14:44:12 +0000 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: Hi Vitaly, There are command line arguments which control the behavior of the inlining process (see http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html- e.g. XX:MaxInlineSize). Regards, Ion www.ionionascu.eu On Fri, Feb 17, 2012 at 2:37 PM, Vitaly Davidovich wrote: > John, > > Doing smarter analysis for inlining decisions would be great. The other > problem today is that people sometimes create "unnecessary" locals with > SuppressWarnings annotation when cleaning up generics usage (this was > discussed during Oracle's warning cleanup day). I guess more generally, > some locals can be be folded or optimized out in the generated machine > code, but currently can prevent inlining. Is this something that you guys > are planning on enhancing? You mention that you think it's a bug, but > unclear on whether there's commitment to fixing it. :) > > Also, is the (default) 35 bc length fixed or is it adjusted higher for > very hot methods? The perf wiki mentions that inlining decision is made at > parse time, which sounds like it's fixed but just wanted to double check. > > Thanks > > Sent from my phone > On Feb 16, 2012 5:14 PM, "John Rose" wrote: > >> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >> >> I think one problem with them is that they count towards the inlining >> budget since their bytecodes still take up space. Not sure if newer C1/C2 >> compiler builds are "smarter" about this nowadays. >> >> >> Optimized object code has (probably) no trace of the assertions >> themselves, but as Vitaly said, they perturb the inlining budget. Larger >> methods have a tendency to "discourage" the inliner from inlining, causing >> more out-of-line calls and a rough net slowdown. Currently, the >> non-executed bytecodes for assertions (which can be arbitrarily complex) >> make methods look bigger than they really are. This is (IMO) a bug in the >> inlining heuristics, which should be fixed by examining inlining candidates >> with a little more care. Since the escape analysis does a similar method >> summarization, there isn't necessarily even a need for an extra pass over >> the methods. >> >> -- John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/c7fece24/attachment.html From vitalyd at gmail.com Fri Feb 17 06:48:25 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 17 Feb 2012 09:48:25 -0500 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: Yes I know (hence I said 35 is default) but wanted to know if there actually is any dynamic adjustment for hot methods - I don't think there is but wanted to double check. Thanks Sent from my phone On Feb 17, 2012 9:44 AM, "Ion Ionascu" wrote: > Hi Vitaly, > > > There are command line arguments which control the behavior of the > inlining process (see > http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html- e.g. XX:MaxInlineSize). > > > Regards, > Ion > > www.ionionascu.eu > > > On Fri, Feb 17, 2012 at 2:37 PM, Vitaly Davidovich wrote: > >> John, >> >> Doing smarter analysis for inlining decisions would be great. The other >> problem today is that people sometimes create "unnecessary" locals with >> SuppressWarnings annotation when cleaning up generics usage (this was >> discussed during Oracle's warning cleanup day). I guess more generally, >> some locals can be be folded or optimized out in the generated machine >> code, but currently can prevent inlining. Is this something that you guys >> are planning on enhancing? You mention that you think it's a bug, but >> unclear on whether there's commitment to fixing it. :) >> >> Also, is the (default) 35 bc length fixed or is it adjusted higher for >> very hot methods? The perf wiki mentions that inlining decision is made at >> parse time, which sounds like it's fixed but just wanted to double check. >> >> Thanks >> >> Sent from my phone >> On Feb 16, 2012 5:14 PM, "John Rose" wrote: >> >>> On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote: >>> >>> I think one problem with them is that they count towards the inlining >>> budget since their bytecodes still take up space. Not sure if newer C1/C2 >>> compiler builds are "smarter" about this nowadays. >>> >>> >>> Optimized object code has (probably) no trace of the assertions >>> themselves, but as Vitaly said, they perturb the inlining budget. Larger >>> methods have a tendency to "discourage" the inliner from inlining, causing >>> more out-of-line calls and a rough net slowdown. Currently, the >>> non-executed bytecodes for assertions (which can be arbitrarily complex) >>> make methods look bigger than they really are. This is (IMO) a bug in the >>> inlining heuristics, which should be fixed by examining inlining candidates >>> with a little more care. Since the escape analysis does a similar method >>> summarization, there isn't necessarily even a need for an extra pass over >>> the methods. >>> >>> -- John >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/ba14d50f/attachment.html From mikael.gerdin at oracle.com Fri Feb 17 07:12:12 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 17 Feb 2012 16:12:12 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> Message-ID: <4F3E6E4C.2050308@oracle.com> I gave up on getting this into HS23 and was busy doing other stuff for HS23. Anyway, there were some issues with the last patch so here's a rebased webrev that actually compiles :) http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.5/ /Mikael On 2012-02-17 12:21, Nils Loodin wrote: > Sooo, what happened with this? > > I think that testing this framework would be an excellent fit for using in testing our diagnostic framework. > But it kind of depends on this being actually checked in :) > > /Nisse > > On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: > >> David, >> >> On 2012-01-13 00:00, David Holmes wrote: >>> Hi Mikael, >>> >>> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>>> wbapi.java: normal Java naming style is to use camel-case for class >>>>> names. Though as WB is itself an acronym I'd be okay with WBApi. In fact >>>>> I'd be happy with anything other than initial lower-case :) >>>> >>>> Many of our existing tests have lower-case names so I guess I thought >>>> that was some sort of convention, it does not really matter to me. >>> >>> I think those tests must have been written by C programers ;-) >>> >>>> WBApi it is then. >>> >>> Thanks.There is a slight typo in that the file is WBapi.java not WBApi.java >> >> Fixed. >> >> I also re-ran JPRT to verify that it still builds on all platforms and found that the size of a region in G1 had changed to size_t, so I added a cast to jint (region sizes of>2G seems to be unreasonable). >> >> I also tried with Jim Melvin's patch to run OS X and verified that "wbapitest" works on OS X as well. >> >> /Mikael >> >>> >>> David >>> ----- >>> >>>> >>>>> >>>>> --- >>>>> >>>>> test/Makefile: does wbapitest need to be added to the phoney list? >>>> >>>> Yes, fixed. >>>> >>>> New webrev at: >>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>>> Incremental at: >>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>>> >>>> /Mikael >>>> >>>>> >>>>> --- >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>>> Hi all >>>>>> >>>>>> Back from vacations now with an updated version of the webrev based on >>>>>> the feedback received in this thread. >>>>>> Changes include: >>>>>> * removed install target from makefiles >>>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add wb.jar to >>>>>> the boot class path from inside the VM. >>>>>> >>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>>> >>>>>> Thanks >>>>>> Mikael Gerdin >>>>>> >>>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>>> Hi >>>>>>> >>>>>>> I've been working on a white box testing API for HotSpot in order to >>>>>>> allow for improved precision in vm testing. >>>>>>> >>>>>>> The basic idea is to open up the possibility for tests written in Java >>>>>>> to call native methods which query or poke the vm in some way. >>>>>>> >>>>>>> The API is accessible by using the class sun/hotspot/WhiteBox which is >>>>>>> not intended to be available in public builds. >>>>>>> In order to allow the WhiteBox class access to the VM the >>>>>>> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. >>>>>>> That >>>>>>> function then links all the implementation functions using normal JNI >>>>>>> RegisterNatives. >>>>>>> >>>>>>> The API is not meant to be used by end users for any intent or purpose >>>>>>> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions >>>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will not be >>>>>>> present in an end user build of a JDK. >>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>> >>>>>>> CR: >>>>>>> I'll file a CR tomorrow. >>>>>>> >>>>>>> Change comments: >>>>>>> >>>>>>> make/jprt.properties >>>>>>> >>>>>>> Add a test target to make sure that the API is available on all >>>>>>> supported platforms >>>>>>> >>>>>>> make/** >>>>>>> >>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put it in a >>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the export >>>>>>> targets. >>>>>>> The BSD makefile changes are not tested since I don't have access to >>>>>>> any >>>>>>> BSD/OSX machine to test them on. >>>>>>> >>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>> >>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>> link it >>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>> >>>>>>> src/share/vm/prims/whitebox.* >>>>>>> >>>>>>> The implementation of the white box API. The actual API functions are >>>>>>> only examples of what we want to be able to do using the API. >>>>>>> >>>>>>> src/share/vm/runtime/globals.hpp >>>>>>> >>>>>>> Add the command line flag >>>>>>> >>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>> >>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>> >>>>>>> test/Makefile >>>>>>> >>>>>>> Add a makefile test target for the white box API test >>>>>>> >>>>>>> test/sanity/wbapi.java >>>>>>> >>>>>>> JTreg test to ensure that the API works. >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> /Mikael Gerdin >>>>>> > From frederic.parain at oracle.com Fri Feb 17 08:38:39 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Fri, 17 Feb 2012 16:38:39 +0000 Subject: hg: hsx/hotspot-main/hotspot: 21 new changesets Message-ID: <20120217163921.1429147564@hg.openjdk.java.net> Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ea527c5cde03 Merge Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1bb2838e2fc1 Merge Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a9ac4910e7f2 Merge Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cf772dff4bfd Merge Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/91a81502a27d Merge Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/64fc5ac1b770 Merge Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/df4927a3b82e Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d3384450b649 Merge From ionionascu at gmail.com Fri Feb 17 08:47:19 2012 From: ionionascu at gmail.com (Ion Ionascu) Date: Fri, 17 Feb 2012 16:47:19 +0000 Subject: Inline and methods with annotations Message-ID: Hi, I noticed in a previous email that somebody mentioned that it might be a good idea not to use annotations on method variables as they influence the length of the method, which influences the decision whether to inline the method or not. So, I have the following curiosity: do method-level annotations also affect the "inline"-ability of a method? Thank you, Ion Ionascu www.ionionascu.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/b48eea76/attachment.html From john.r.rose at oracle.com Fri Feb 17 12:25:18 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 17 Feb 2012 12:25:18 -0800 Subject: cost of Java "assert" when disabled? In-Reply-To: References: <4F3D77FB.1050500@oracle.com> <28976D11-F026-4335-9BED-06E0EB9487E3@oracle.com> Message-ID: <0D977CCD-27B9-46FB-8A47-37DD4BDDEDE1@oracle.com> On Feb 17, 2012, at 6:48 AM, Vitaly Davidovich wrote: > dynamic adjustment for hot methods Yes, see gnarly details in bytecodeInfo.cpp. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/4a252804/attachment.html From tom.rodriguez at oracle.com Fri Feb 17 12:32:41 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 17 Feb 2012 12:32:41 -0800 Subject: Inline and methods with annotations In-Reply-To: References: Message-ID: <9D3EFEFD-7582-45B2-88EA-2A0CEA93184E@oracle.com> On Feb 17, 2012, at 8:47 AM, Ion Ionascu wrote: > Hi, > > > I noticed in a previous email that somebody mentioned that it might be a good idea not to use annotations on method variables as they influence the length of the method, which influences the decision whether to inline the method or not. > > So, I have the following curiosity: do method-level annotations also affect the "inline"-ability of a method? They shouldn't. They only reference values from the constant pool so they shouldn't effect the actual bytecodes generated, which is the only thing the JIT really cares about. tom > > > Thank you, > Ion Ionascu > > www.ionionascu.eu From tom.rodriguez at oracle.com Fri Feb 17 14:31:29 2012 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 17 Feb 2012 22:31:29 +0000 Subject: hg: hsx/hotspot-main/hotspot: 16 new changesets Message-ID: <20120217223201.889534756B@hg.openjdk.java.net> Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp From paul.hohensee at oracle.com Fri Feb 17 14:54:05 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 17 Feb 2012 17:54:05 -0500 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4F3E6E4C.2050308@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> <4F3E6E4C.2050308@oracle.com> Message-ID: <4F3EDA8D.9040505@oracle.com> Thanks for doing this, it's something I've been wanting to see in Hotspot for quite awhile. :) Looks good. You'll need a GC reviewer for the whitebox.cpp method content. A few small things: In globals.hpp, add a blank line ending in '\' before the declaration of WhiteBoxAPI. The copyright year in the all the new files should be 2012. Same with all the old files except make/Makefile, nativeLookup.cpp, make/bsd/makefiles/defs.make, arguments.cpp, globals.hpp and vmError.cpp, which already have 2012. What's the rationale for the directory path (' ||src/share/tools/whitebox/src/classes/ sun/hotspot') used to get to WhiteBox.java? Seems a bit long. In whitebox.hpp, use SHARE_VM_PRIMS_WHITEBOX_HPP instead of SHARE_VM_PRIMS_WHITEBOX_H. Thanks, Paul On 2/17/12 10:12 AM, Mikael Gerdin wrote: > I gave up on getting this into HS23 and was busy doing other stuff for > HS23. > Anyway, there were some issues with the last patch so here's a rebased > webrev that actually compiles :) > > http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.5/ > > /Mikael > > On 2012-02-17 12:21, Nils Loodin wrote: >> Sooo, what happened with this? >> >> I think that testing this framework would be an excellent fit for >> using in testing our diagnostic framework. >> But it kind of depends on this being actually checked in :) >> >> /Nisse >> >> On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: >> >>> David, >>> >>> On 2012-01-13 00:00, David Holmes wrote: >>>> Hi Mikael, >>>> >>>> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>>>> wbapi.java: normal Java naming style is to use camel-case for class >>>>>> names. Though as WB is itself an acronym I'd be okay with WBApi. >>>>>> In fact >>>>>> I'd be happy with anything other than initial lower-case :) >>>>> >>>>> Many of our existing tests have lower-case names so I guess I thought >>>>> that was some sort of convention, it does not really matter to me. >>>> >>>> I think those tests must have been written by C programers ;-) >>>> >>>>> WBApi it is then. >>>> >>>> Thanks.There is a slight typo in that the file is WBapi.java not >>>> WBApi.java >>> >>> Fixed. >>> >>> I also re-ran JPRT to verify that it still builds on all platforms >>> and found that the size of a region in G1 had changed to size_t, so >>> I added a cast to jint (region sizes of>2G seems to be unreasonable). >>> >>> I also tried with Jim Melvin's patch to run OS X and verified that >>> "wbapitest" works on OS X as well. >>> >>> /Mikael >>> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> test/Makefile: does wbapitest need to be added to the phoney list? >>>>> >>>>> Yes, fixed. >>>>> >>>>> New webrev at: >>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>>>> Incremental at: >>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>>>> Hi all >>>>>>> >>>>>>> Back from vacations now with an updated version of the webrev >>>>>>> based on >>>>>>> the feedback received in this thread. >>>>>>> Changes include: >>>>>>> * removed install target from makefiles >>>>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add >>>>>>> wb.jar to >>>>>>> the boot class path from inside the VM. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>>>> >>>>>>> Thanks >>>>>>> Mikael Gerdin >>>>>>> >>>>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I've been working on a white box testing API for HotSpot in >>>>>>>> order to >>>>>>>> allow for improved precision in vm testing. >>>>>>>> >>>>>>>> The basic idea is to open up the possibility for tests written >>>>>>>> in Java >>>>>>>> to call native methods which query or poke the vm in some way. >>>>>>>> >>>>>>>> The API is accessible by using the class sun/hotspot/WhiteBox >>>>>>>> which is >>>>>>>> not intended to be available in public builds. >>>>>>>> In order to allow the WhiteBox class access to the VM the >>>>>>>> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. >>>>>>>> That >>>>>>>> function then links all the implementation functions using >>>>>>>> normal JNI >>>>>>>> RegisterNatives. >>>>>>>> >>>>>>>> The API is not meant to be used by end users for any intent or >>>>>>>> purpose >>>>>>>> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions >>>>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will >>>>>>>> not be >>>>>>>> present in an end user build of a JDK. >>>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>> >>>>>>>> CR: >>>>>>>> I'll file a CR tomorrow. >>>>>>>> >>>>>>>> Change comments: >>>>>>>> >>>>>>>> make/jprt.properties >>>>>>>> >>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>> supported platforms >>>>>>>> >>>>>>>> make/** >>>>>>>> >>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put >>>>>>>> it in a >>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>> export >>>>>>>> targets. >>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>> access to >>>>>>>> any >>>>>>>> BSD/OSX machine to test them on. >>>>>>>> >>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>> >>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>> link it >>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>> >>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>> >>>>>>>> The implementation of the white box API. The actual API >>>>>>>> functions are >>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>> >>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>> >>>>>>>> Add the command line flag >>>>>>>> >>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>> >>>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>>> >>>>>>>> test/Makefile >>>>>>>> >>>>>>>> Add a makefile test target for the white box API test >>>>>>>> >>>>>>>> test/sanity/wbapi.java >>>>>>>> >>>>>>>> JTreg test to ensure that the API works. >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> /Mikael Gerdin >>>>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/c04fb250/attachment-0001.html From john.coomes at oracle.com Fri Feb 17 20:29:19 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 18 Feb 2012 04:29:19 +0000 Subject: hg: hsx/hsx23/hotspot: 50 new changesets Message-ID: <20120218043103.9C78847577@hg.openjdk.java.net> Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: 094138495da4 Author: amurillo Date: 2012-02-10 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/094138495da4 7144322: new hotspot build - hs23-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 77a488cd4af2 Author: dlong Date: 2012-02-15 00:51 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/77a488cd4af2 7140866: assert(covered) failed: Card for end of new region not committed Summary: resize covered region only after successfully mapping shared archive Reviewed-by: brutisso, ysr Contributed-by: dean.long at oracle.com ! src/share/vm/memory/compactingPermGenGen.cpp Changeset: f9961b6498f9 Author: bpittore Date: 2012-02-15 16:09 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f9961b6498f9 Merge Changeset: 95f6641e38e0 Author: iveresov Date: 2012-02-10 17:40 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/95f6641e38e0 7144296: PS: Optimize nmethods processing Summary: Prunes scavenge roots in code list every young GC, promote objects directly pointed by the code immediately Reviewed-by: johnc, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp Changeset: caa4652b4414 Author: tonyp Date: 2012-02-14 08:21 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/caa4652b4414 7129892: G1: explicit marking cycle initiation might fail to initiate a marking cycle Summary: If we try to schedule an initial-mark GC in order to explicit start a conc mark cycle and it gets pre-empted by antoher GC, we should retry the attempt as long as it's appropriate for the GC cause. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: d903bf750e9f Author: johnc Date: 2012-01-18 09:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d903bf750e9f 7129514: time warp warnings after 7117303 Summary: Replace calls to os::javaTimeMillis() that are used to update the milliseconds since the last GC to an equivalent that uses a monotonically non-decreasing time source. Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genMarkSweep.cpp Changeset: a9647476d1a4 Author: tonyp Date: 2012-02-15 13:06 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a9647476d1a4 7132029: G1: mixed GC phase lasts for longer than it should Summary: Revamp of the mechanism that chooses old regions for inclusion in the CSet. It simplifies the code and introduces min and max bounds on the number of old regions added to the CSet at each mixed GC to avoid pathological cases. It also ensures that when we do a mixed GC we'll always find old regions to add to the CSet (i.e., it eliminates the case where a mixed GC will collect no old regions which can happen today). Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: ab4422d0ed59 Author: jcoomes Date: 2012-02-16 13:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ab4422d0ed59 7146343: PS invoke methods should indicate the type of gc done Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp Changeset: 23c0eb012d6f Author: jcoomes Date: 2012-02-16 13:13 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/23c0eb012d6f 6330863: vm/gc/InfiniteList.java fails intermittently due to timeout Summary: in some cases, allocate from the old gen before doing a full gc Reviewed-by: stefank, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.inline.hpp Changeset: be398bba40e9 Author: stefank Date: 2012-02-17 13:23 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/be398bba40e9 Merge Changeset: 1b0e0f8be510 Author: minqi Date: 2012-02-09 00:51 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1b0e0f8be510 7131006: java/lang/management/ThreadMXBean/ThreadLists.java Reviewed-by: dholmes, acorn ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/utilities/preserveException.cpp Changeset: db006a85bf91 Author: zgu Date: 2012-02-09 10:16 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/db006a85bf91 7141259: Native stack is missing in hs_err Summary: Code cleanup and creating a private decoder for error handler, since it can be triggered from in signal handler, where no lock can be taken Reviewed-by: dholmes, kamg, acorn, coleenp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp ! src/share/vm/utilities/vmError.hpp Changeset: ea527c5cde03 Author: zgu Date: 2012-02-09 07:35 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ea527c5cde03 Merge Changeset: 54d3535a6dd3 Author: poonam Date: 2012-02-12 19:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/54d3535a6dd3 7009098: SA cannot open core files larger than 2GB on Linux 32-bit Summary: Added Large File Support by compiling libsaproc.so with -D_FILE_OFFSET_BITS=64, and a small change with which SA should first load libraries from the path specified with SA_ALTROOT. Reviewed-by: dholmes, kevinw, dcubed, minqi ! agent/src/os/linux/Makefile ! agent/src/os/linux/libproc_impl.c ! make/linux/makefiles/saproc.make Changeset: 1bb2838e2fc1 Author: fparain Date: 2012-02-13 06:24 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1bb2838e2fc1 Merge Changeset: 849412a95e45 Author: coleenp Date: 2012-02-13 12:30 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/849412a95e45 7059899: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh ! src/cpu/x86/vm/globals_x86.hpp Changeset: 1891640ca63f Author: fparain Date: 2012-02-14 06:54 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/1891640ca63f 7143760: Memory leak in GarbageCollectionNotifications Reviewed-by: dholmes, dcubed, kamg ! src/share/vm/services/gcNotifier.cpp ! src/share/vm/services/gcNotifier.hpp Changeset: a9831b955a0a Author: kamg Date: 2012-02-13 14:03 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a9831b955a0a 7069991: Setup make/jprt.properties files for jdk8 Summary: Change default release value to jdk8 (but overrideable) Reviewed-by: phh, jcoomes, dholmes, ohair ! make/jprt.properties Changeset: a9ac4910e7f2 Author: kamg Date: 2012-02-14 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/a9ac4910e7f2 Merge Changeset: 28d91e43ab6d Author: coleenp Date: 2012-02-14 16:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/28d91e43ab6d 7145587: Stack overflows in Java code cause 64-bit JVMs to exit due to SIGSEGV (sparc version) Summary: Increase StackShadowPages to accomodate the JDK changes to increase buffer size in socketWrite Reviewed-by: acorn, phh, dcubed, kamg, dsamersoff ! src/cpu/sparc/vm/globals_sparc.hpp Changeset: cf772dff4bfd Author: coleenp Date: 2012-02-14 18:35 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cf772dff4bfd Merge Changeset: b8a4e1d372a0 Author: kamg Date: 2012-02-14 20:02 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b8a4e1d372a0 7145589: First JSDT provider creation fails Summary: 0 is a successful return from an ioctl() call Reviewed-by: dcubed, phh, dsamersoff ! src/share/vm/runtime/dtraceJSDT.cpp Changeset: 91a81502a27d Author: kamg Date: 2012-02-15 00:09 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/91a81502a27d Merge Changeset: 2b150750d53d Author: sspitsyn Date: 2012-02-14 17:04 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/2b150750d53d 7130993: nsk/jdi/ReferenceType/instances/instances004 fails with JFR: assert(ServiceUtil::visible_oop(obj)) Summary: Skip reporting invisible refs in iterate_over_object to avoid assert(ServiceUtil::visible_oop(obj)) Reviewed-by: dcubed, mgronlun, rbackman Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: cd239a88b90c Author: minqi Date: 2012-02-14 20:54 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cd239a88b90c Merge Changeset: 64fc5ac1b770 Author: minqi Date: 2012-02-14 23:50 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/64fc5ac1b770 Merge Changeset: f1cb6f9cfe21 Author: fparain Date: 2012-02-15 12:17 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f1cb6f9cfe21 7145243: Need additional specializations for argument parsing framework Reviewed-by: acorn, fparain Contributed-by: nils.loodin at oracle.com ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticArgument.hpp ! src/share/vm/services/diagnosticFramework.cpp ! src/share/vm/services/diagnosticFramework.hpp Changeset: 4a24c4f648bd Author: phh Date: 2012-02-16 13:50 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/4a24c4f648bd 7142113: Add Ivy Bridge to the known Intel x86 cpu families Summary: In vm_version_x86.hpp, add and use CPU_MODEL_IVYBRIDGE_EP, and restrict is_intel_tsc_synced_at_init() to EP models. Reviewed-by: kvn, acorn ! src/cpu/x86/vm/vm_version_x86.hpp Changeset: 7df3125953cb Author: coleenp Date: 2012-02-16 15:52 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/7df3125953cb 7146354: Re-enable Compressed OOPs after 7118647 is resolved Summary: Relax the assertion to simply check for COOP mode rather than an exact address. Reviewed-by: coleenp, kvn, phh, dcubed Contributed-by: james.melvin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/virtualspace.cpp Changeset: df4927a3b82e Author: coleenp Date: 2012-02-16 17:19 -0500 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/df4927a3b82e Merge Changeset: d3384450b649 Author: fparain Date: 2012-02-17 06:34 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/d3384450b649 Merge Changeset: 73df3733f2eb Author: kvn Date: 2012-02-10 12:53 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/73df3733f2eb 7129284: +DoEscapeAnalysis regression w/ early build of 7u4 (HotSpot 23) on Linux Summary: Removed code which tried to create edges from fields of destination objects of arraycopy to fields of source objects. Added 30 sec time limit for EA graph construction. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: de34c646c3f7 Author: kvn Date: 2012-02-10 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/de34c646c3f7 7140985: HSDIS does not handle caller options correctly Summary: Fix typo. Reviewed-by: jrose, kvn Contributed-by: Andrew Haley ! src/share/tools/hsdis/hsdis.c Changeset: 45a1bf98f1bb Author: twisti Date: 2012-02-13 02:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/45a1bf98f1bb 7141329: Strange values of stack_size in -XX:+TraceMethodHandles output Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: f09ae3853e3b Author: twisti Date: 2012-02-13 04:30 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f09ae3853e3b 7143766: add ALT_JDK_IMAGE_DIR and improve test_jdk Reviewed-by: rbackman, jrose, dholmes ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/top.make ! make/defs.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/top.make Changeset: b522995d91f0 Author: roland Date: 2012-02-14 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/b522995d91f0 7144405: JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found Summary: oop map needs pc stored in frame anchor in StubGenerator::generate_throw_exception() Reviewed-by: twisti, never, kvn ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 8f4eb44b3b76 Author: never Date: 2012-02-14 15:43 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/8f4eb44b3b76 7143061: nsk/stress/stack/b4525850 crash VM Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp Changeset: 80107dc493db Author: roland Date: 2012-02-15 09:43 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/80107dc493db 7126041: jdk7u4 b05 and b06 crash with RubyMine 3.2.4, works well with b04 Summary: Goto that replaces a If mistaken to be a back branch and triggers erroneous OSR compilation. Reviewed-by: never, iveresov ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: 09d00c18e323 Author: never Date: 2012-02-15 10:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/09d00c18e323 7145537: minor tweaks to LogEvents Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/events.hpp Changeset: cfdfbeac0a5b Author: iveresov Date: 2012-02-15 12:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cfdfbeac0a5b 7145345: Code cache sweeper must cooperate with safepoints Summary: Safepoint in the sweeper loop in necessary Reviewed-by: kvn, never ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: 69333a2fbae2 Author: iveresov Date: 2012-02-15 16:29 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/69333a2fbae2 7142680: default GC affected by jvm path Summary: Removed old tiered code Reviewed-by: never, kvn ! src/share/vm/runtime/arguments.cpp Changeset: fd8114661503 Author: kvn Date: 2012-02-15 21:37 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/fd8114661503 7125136: SIGILL on linux amd64 in gc/ArrayJuggle/Juggle29 Summary: For C2 moved saving EBP after ESP adjustment. For C1 generated 5 byte nop instruction first if needed. Reviewed-by: never, twisti, azeemj ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/output.cpp Changeset: c7401dcad8bf Author: roland Date: 2012-02-16 09:20 +0100 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/c7401dcad8bf 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num Summary: forced exit may destory global objects that are still in use. Reviewed-by: twisti, never, kvn ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp Changeset: ad3b47344802 Author: never Date: 2012-02-16 11:33 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/ad3b47344802 7144318: GCLocker assert failure: assert(_needs_gc || SafepointSynchronize::is_at_safepoint( Reviewed-by: kvn, twisti ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/gcLocker.inline.hpp Changeset: 9b8ce46870df Author: kvn Date: 2012-02-16 17:12 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/9b8ce46870df 7145346: VerifyStackAtCalls is broken Summary: Replace call_epilog() encoding with macroassembler use. Moved duplicated code to x86.ad. Fixed return_addr() definition. Reviewed-by: never ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/bsd_x86_64.ad ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/os_cpu/linux_x86/vm/linux_x86_64.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_32.ad ! src/os_cpu/solaris_x86/vm/solaris_x86_64.ad ! src/os_cpu/windows_x86/vm/windows_x86_32.ad ! src/os_cpu/windows_x86/vm/windows_x86_64.ad ! src/share/vm/opto/chaitin.cpp Changeset: 72c425c46102 Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/72c425c46102 7146729: nightly failure after 7141200: tty is sometimes null during shutdown of main thread Reviewed-by: kvn ! src/share/vm/utilities/events.hpp Changeset: 15085a6eb50c Author: never Date: 2012-02-17 12:18 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/15085a6eb50c Merge ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags From john.coomes at oracle.com Fri Feb 17 22:23:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 18 Feb 2012 06:23:11 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120218062322.439BE4757A@hg.openjdk.java.net> Changeset: 087daaec688d Author: katleman Date: 2012-02-16 13:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/087daaec688d Added tag jdk8-b26 for changeset fd3060701216 ! .hgtags Changeset: f92a171cf007 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f92a171cf007 Merge Changeset: 98cd09d11a21 Author: amurillo Date: 2012-02-17 15:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98cd09d11a21 Added tag hs23-b16 for changeset f92a171cf007 ! .hgtags Changeset: 4ab89de75552 Author: amurillo Date: 2012-02-17 15:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4ab89de75552 7146700: new hotspot build - hs24-b01 Reviewed-by: jcoomes ! make/hotspot_version From aph at redhat.com Mon Feb 20 05:26:45 2012 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Feb 2012 13:26:45 +0000 Subject: Default UseTLAB on Zero Message-ID: <4F424A15.4080507@redhat.com> I noticed that, on Zero, UseTLAB defaults to false, because of this code: #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) define_pd_global(bool, BackgroundCompilation, false); define_pd_global(bool, UseTLAB, false); ... I don't understand why this is. Surely it only pointlessly slows down Zero. Any ideas? Thanks, Andrew. From mikael.gerdin at oracle.com Mon Feb 20 07:43:37 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 20 Feb 2012 16:43:37 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4F3EDA8D.9040505@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> <4F3E6E4C.2050308@oracle.com> <4F3EDA8D.9040505@oracle.com> Message-ID: <4F426A29.7030805@oracle.com> Hi Paul, On 2012-02-17 23:54, Paul Hohensee wrote: > Thanks for doing this, it's something I've been wanting to see in Hotspot > for quite awhile. :) > > Looks good. You'll need a GC reviewer for the whitebox.cpp method content. Right. Some of the GC functions were more or less examples of what could be done and were not very useful besides that. I removed the most obscure ones at least but I'll keep some core functions. > > A few small things: > > In globals.hpp, add a blank line ending in '\' before the declaration of > WhiteBoxAPI. Done > > The copyright year in the all the new files should be 2012. Same with > all the old files except make/Makefile, nativeLookup.cpp, > make/bsd/makefiles/defs.make, > arguments.cpp, globals.hpp and vmError.cpp, which already have 2012. I think I updated all of them. > > What's the rationale for the directory path (' > ||src/share/tools/whitebox/src/classes/ > sun/hotspot') used to get to WhiteBox.java? Seems a bit long. It made more sense when there was a native library part living in src/share/tools/whitebox/src/native I changed it to src/share/tools/whitebox > > In whitebox.hpp, use SHARE_VM_PRIMS_WHITEBOX_HPP instead of > SHARE_VM_PRIMS_WHITEBOX_H. Done New webrev at: http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.7/ Thanks for looking at this. /Mikael > > Thanks, > > Paul > > On 2/17/12 10:12 AM, Mikael Gerdin wrote: >> I gave up on getting this into HS23 and was busy doing other stuff for >> HS23. >> Anyway, there were some issues with the last patch so here's a rebased >> webrev that actually compiles :) >> >> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.5/ >> >> /Mikael >> >> On 2012-02-17 12:21, Nils Loodin wrote: >>> Sooo, what happened with this? >>> >>> I think that testing this framework would be an excellent fit for >>> using in testing our diagnostic framework. >>> But it kind of depends on this being actually checked in :) >>> >>> /Nisse >>> >>> On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: >>> >>>> David, >>>> >>>> On 2012-01-13 00:00, David Holmes wrote: >>>>> Hi Mikael, >>>>> >>>>> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>>>>> wbapi.java: normal Java naming style is to use camel-case for class >>>>>>> names. Though as WB is itself an acronym I'd be okay with WBApi. >>>>>>> In fact >>>>>>> I'd be happy with anything other than initial lower-case :) >>>>>> >>>>>> Many of our existing tests have lower-case names so I guess I thought >>>>>> that was some sort of convention, it does not really matter to me. >>>>> >>>>> I think those tests must have been written by C programers ;-) >>>>> >>>>>> WBApi it is then. >>>>> >>>>> Thanks.There is a slight typo in that the file is WBapi.java not >>>>> WBApi.java >>>> >>>> Fixed. >>>> >>>> I also re-ran JPRT to verify that it still builds on all platforms >>>> and found that the size of a region in G1 had changed to size_t, so >>>> I added a cast to jint (region sizes of>2G seems to be unreasonable). >>>> >>>> I also tried with Jim Melvin's patch to run OS X and verified that >>>> "wbapitest" works on OS X as well. >>>> >>>> /Mikael >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> test/Makefile: does wbapitest need to be added to the phoney list? >>>>>> >>>>>> Yes, fixed. >>>>>> >>>>>> New webrev at: >>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>>>>> Incremental at: >>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>>>>> Hi all >>>>>>>> >>>>>>>> Back from vacations now with an updated version of the webrev >>>>>>>> based on >>>>>>>> the feedback received in this thread. >>>>>>>> Changes include: >>>>>>>> * removed install target from makefiles >>>>>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add >>>>>>>> wb.jar to >>>>>>>> the boot class path from inside the VM. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Mikael Gerdin >>>>>>>> >>>>>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I've been working on a white box testing API for HotSpot in >>>>>>>>> order to >>>>>>>>> allow for improved precision in vm testing. >>>>>>>>> >>>>>>>>> The basic idea is to open up the possibility for tests written >>>>>>>>> in Java >>>>>>>>> to call native methods which query or poke the vm in some way. >>>>>>>>> >>>>>>>>> The API is accessible by using the class sun/hotspot/WhiteBox >>>>>>>>> which is >>>>>>>>> not intended to be available in public builds. >>>>>>>>> In order to allow the WhiteBox class access to the VM the >>>>>>>>> registerNatives function is linked to JVM_RegisterWhiteBoxMethods. >>>>>>>>> That >>>>>>>>> function then links all the implementation functions using >>>>>>>>> normal JNI >>>>>>>>> RegisterNatives. >>>>>>>>> >>>>>>>>> The API is not meant to be used by end users for any intent or >>>>>>>>> purpose >>>>>>>>> and as such it is both guarded by "-XX:+UnlockDiagnosticVMOptions >>>>>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will >>>>>>>>> not be >>>>>>>>> present in an end user build of a JDK. >>>>>>>>> If the VM crashes after this API has been accessed a note will be >>>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>>> >>>>>>>>> CR: >>>>>>>>> I'll file a CR tomorrow. >>>>>>>>> >>>>>>>>> Change comments: >>>>>>>>> >>>>>>>>> make/jprt.properties >>>>>>>>> >>>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>>> supported platforms >>>>>>>>> >>>>>>>>> make/** >>>>>>>>> >>>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put >>>>>>>>> it in a >>>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>>> export >>>>>>>>> targets. >>>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>>> access to >>>>>>>>> any >>>>>>>>> BSD/OSX machine to test them on. >>>>>>>>> >>>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>>> >>>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>>> link it >>>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>>> >>>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>>> >>>>>>>>> The implementation of the white box API. The actual API >>>>>>>>> functions are >>>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>>> >>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>> >>>>>>>>> Add the command line flag >>>>>>>>> >>>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>>> >>>>>>>>> Print a message in hs_err files when white box API has been used. >>>>>>>>> >>>>>>>>> test/Makefile >>>>>>>>> >>>>>>>>> Add a makefile test target for the white box API test >>>>>>>>> >>>>>>>>> test/sanity/wbapi.java >>>>>>>>> >>>>>>>>> JTreg test to ensure that the API works. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /Mikael Gerdin >>>>>>>> >>> From xerxes at zafena.se Mon Feb 20 07:47:24 2012 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Mon, 20 Feb 2012 16:47:24 +0100 Subject: Default UseTLAB on Zero In-Reply-To: <4F424A15.4080507@redhat.com> References: <4F424A15.4080507@redhat.com> Message-ID: <4F426B0C.1020004@zafena.se> 2012-02-20 14:26, Andrew Haley skrev: > I noticed that, on Zero, UseTLAB defaults to false, because of this > code: > > #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) > define_pd_global(bool, BackgroundCompilation, false); > define_pd_global(bool, UseTLAB, false); > ... > > I don't understand why this is. Surely it only pointlessly slows > down Zero. Any ideas? > > Thanks, > Andrew. OK! I checked the jdk6 hotspot log http://hg.openjdk.java.net/jdk6/jdk6/hotspot/annotate/20dbc199874e/src/share/vm/runtime/globals.hpp it have been turned off since the initial duke at 0 commit. Shark have always used UseTLAB and ResizeTLAB true in its shark_globals_zero.hpp . I think this part have simply been missed to be turned ON for Zero builds. Xerxes From paul.hohensee at oracle.com Mon Feb 20 07:56:16 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 20 Feb 2012 10:56:16 -0500 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4F426A29.7030805@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> <4F3E6E4C.2050308@oracle.com> <4F3EDA8D.9040505@oracle.com> <4F426A29.7030805@oracle.com> Message-ID: <4F426D20.5030009@oracle.com> Not quite there yet. The copyright year in the new files is now "2011, 2012" when it should just be "2012". The new code didn't get pushed in 2011. :) make/jprt.properties still needs a copyright year of 2012 instead of 2011. Paul On 2/20/12 10:43 AM, Mikael Gerdin wrote: > Hi Paul, > > On 2012-02-17 23:54, Paul Hohensee wrote: >> Thanks for doing this, it's something I've been wanting to see in >> Hotspot >> for quite awhile. :) >> >> Looks good. You'll need a GC reviewer for the whitebox.cpp method >> content. > > Right. Some of the GC functions were more or less examples of what > could be done and were not very useful besides that. I removed the > most obscure ones at least but I'll keep some core functions. > >> >> A few small things: >> >> In globals.hpp, add a blank line ending in '\' before the declaration of >> WhiteBoxAPI. > > Done > >> >> The copyright year in the all the new files should be 2012. Same with >> all the old files except make/Makefile, nativeLookup.cpp, >> make/bsd/makefiles/defs.make, >> arguments.cpp, globals.hpp and vmError.cpp, which already have 2012. > > I think I updated all of them. > >> >> What's the rationale for the directory path (' >> ||src/share/tools/whitebox/src/classes/ >> sun/hotspot') used to get to WhiteBox.java? Seems a bit long. > > It made more sense when there was a native library part living in > src/share/tools/whitebox/src/native > I changed it to > src/share/tools/whitebox > > >> >> In whitebox.hpp, use SHARE_VM_PRIMS_WHITEBOX_HPP instead of >> SHARE_VM_PRIMS_WHITEBOX_H. > > Done > > New webrev at: http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.7/ > > Thanks for looking at this. > > /Mikael > >> >> Thanks, >> >> Paul >> >> On 2/17/12 10:12 AM, Mikael Gerdin wrote: >>> I gave up on getting this into HS23 and was busy doing other stuff for >>> HS23. >>> Anyway, there were some issues with the last patch so here's a rebased >>> webrev that actually compiles :) >>> >>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.5/ >>> >>> /Mikael >>> >>> On 2012-02-17 12:21, Nils Loodin wrote: >>>> Sooo, what happened with this? >>>> >>>> I think that testing this framework would be an excellent fit for >>>> using in testing our diagnostic framework. >>>> But it kind of depends on this being actually checked in :) >>>> >>>> /Nisse >>>> >>>> On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: >>>> >>>>> David, >>>>> >>>>> On 2012-01-13 00:00, David Holmes wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>>>>>> wbapi.java: normal Java naming style is to use camel-case for >>>>>>>> class >>>>>>>> names. Though as WB is itself an acronym I'd be okay with WBApi. >>>>>>>> In fact >>>>>>>> I'd be happy with anything other than initial lower-case :) >>>>>>> >>>>>>> Many of our existing tests have lower-case names so I guess I >>>>>>> thought >>>>>>> that was some sort of convention, it does not really matter to me. >>>>>> >>>>>> I think those tests must have been written by C programers ;-) >>>>>> >>>>>>> WBApi it is then. >>>>>> >>>>>> Thanks.There is a slight typo in that the file is WBapi.java not >>>>>> WBApi.java >>>>> >>>>> Fixed. >>>>> >>>>> I also re-ran JPRT to verify that it still builds on all platforms >>>>> and found that the size of a region in G1 had changed to size_t, so >>>>> I added a cast to jint (region sizes of>2G seems to be unreasonable). >>>>> >>>>> I also tried with Jim Melvin's patch to run OS X and verified that >>>>> "wbapitest" works on OS X as well. >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> test/Makefile: does wbapitest need to be added to the phoney list? >>>>>>> >>>>>>> Yes, fixed. >>>>>>> >>>>>>> New webrev at: >>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>>>>>> Incremental at: >>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>>>>>> Hi all >>>>>>>>> >>>>>>>>> Back from vacations now with an updated version of the webrev >>>>>>>>> based on >>>>>>>>> the feedback received in this thread. >>>>>>>>> Changes include: >>>>>>>>> * removed install target from makefiles >>>>>>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>>>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add >>>>>>>>> wb.jar to >>>>>>>>> the boot class path from inside the VM. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Mikael Gerdin >>>>>>>>> >>>>>>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I've been working on a white box testing API for HotSpot in >>>>>>>>>> order to >>>>>>>>>> allow for improved precision in vm testing. >>>>>>>>>> >>>>>>>>>> The basic idea is to open up the possibility for tests written >>>>>>>>>> in Java >>>>>>>>>> to call native methods which query or poke the vm in some way. >>>>>>>>>> >>>>>>>>>> The API is accessible by using the class sun/hotspot/WhiteBox >>>>>>>>>> which is >>>>>>>>>> not intended to be available in public builds. >>>>>>>>>> In order to allow the WhiteBox class access to the VM the >>>>>>>>>> registerNatives function is linked to >>>>>>>>>> JVM_RegisterWhiteBoxMethods. >>>>>>>>>> That >>>>>>>>>> function then links all the implementation functions using >>>>>>>>>> normal JNI >>>>>>>>>> RegisterNatives. >>>>>>>>>> >>>>>>>>>> The API is not meant to be used by end users for any intent or >>>>>>>>>> purpose >>>>>>>>>> and as such it is both guarded by >>>>>>>>>> "-XX:+UnlockDiagnosticVMOptions >>>>>>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will >>>>>>>>>> not be >>>>>>>>>> present in an end user build of a JDK. >>>>>>>>>> If the VM crashes after this API has been accessed a note >>>>>>>>>> will be >>>>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>>>> >>>>>>>>>> CR: >>>>>>>>>> I'll file a CR tomorrow. >>>>>>>>>> >>>>>>>>>> Change comments: >>>>>>>>>> >>>>>>>>>> make/jprt.properties >>>>>>>>>> >>>>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>>>> supported platforms >>>>>>>>>> >>>>>>>>>> make/** >>>>>>>>>> >>>>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put >>>>>>>>>> it in a >>>>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>>>> export >>>>>>>>>> targets. >>>>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>>>> access to >>>>>>>>>> any >>>>>>>>>> BSD/OSX machine to test them on. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>>>> >>>>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>>>> link it >>>>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>>>> >>>>>>>>>> The implementation of the white box API. The actual API >>>>>>>>>> functions are >>>>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>>> >>>>>>>>>> Add the command line flag >>>>>>>>>> >>>>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>>>> >>>>>>>>>> Print a message in hs_err files when white box API has been >>>>>>>>>> used. >>>>>>>>>> >>>>>>>>>> test/Makefile >>>>>>>>>> >>>>>>>>>> Add a makefile test target for the white box API test >>>>>>>>>> >>>>>>>>>> test/sanity/wbapi.java >>>>>>>>>> >>>>>>>>>> JTreg test to ensure that the API works. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /Mikael Gerdin >>>>>>>>> >>>> From james.melvin at oracle.com Mon Feb 20 13:02:13 2012 From: james.melvin at oracle.com (James Melvin) Date: Mon, 20 Feb 2012 16:02:13 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 Message-ID: <4F42B4D5.2000004@oracle.com> Hi, To maintain compatibility with Apple JDKs, a proposal will be made to change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS X. Minor changes are required to the following repositories, for which I've provided webrevs... WEBREV: http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 TESTING: JPRT job (2012-02-20-203901.jmelvin.hotspot) Notepad, SwingSet2, SPECjbb2005 This change will also impact a small number of internal tests and RE scripts. The bundle names will also reflect the change amd64 -> x86_64. HotSpot changes can be integrated first, with the JDK changes in the following promotion. Should the proposal be rejected for 7u4, I obviously withdraw the bugfix. Feedback welcome, Jim From john.coomes at oracle.com Tue Feb 21 01:19:33 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Tue, 21 Feb 2012 09:19:33 +0000 Subject: hg: hsx/hsx23/hotspot: 2 new changesets Message-ID: <20120221091942.3C5C8475B0@hg.openjdk.java.net> Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags From michael.x.mcmahon at oracle.com Tue Feb 21 02:41:46 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 21 Feb 2012 10:41:46 +0000 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F43710A.30001@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F43710A.30001@oracle.com> Message-ID: <4F4374EA.2090806@oracle.com> Jim, Thanks for doing this. Some minor comments on the JDK changes. 1) the amd64 definitions in make/common/Defs-macosx.gmk are redundant now. Maybe we should just delete them (though I agree with keeping the runtime checks in the .java sources) 2) the (Mac) checks for os.name have generally been using String.startsWith() instead of equals() so they will work with a future "Mac OS X Server" (java/awt/GraphicsEnvironment.java). I think there are similar checks in hotspot too. I see Mike Swingler is suggesting String.contains("OS X"). I'd be ok with that too. 3) one other location where a check needs to be added is: java/nio/Bits.java Also, I don't see any code in Hotspot that checks for the new "x86_64" value. So, is it actually necessary for the hotspot change to be integrated first? - Michael, On 20/02/12 21:02, James Melvin wrote: > Hi, > > To maintain compatibility with Apple JDKs, a proposal will be made to > change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS > X. Minor changes are required to the following repositories, for which > I've provided webrevs... > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 > > TESTING: > JPRT job (2012-02-20-203901.jmelvin.hotspot) > Notepad, SwingSet2, SPECjbb2005 > > This change will also impact a small number of internal tests and RE > scripts. The bundle names will also reflect the change amd64 -> x86_64. > HotSpot changes can be integrated first, with the JDK changes in the > following promotion. Should the proposal be rejected for 7u4, I > obviously withdraw the bugfix. > > Feedback welcome, > > Jim From james.melvin at oracle.com Tue Feb 21 11:36:43 2012 From: james.melvin at oracle.com (James Melvin) Date: Tue, 21 Feb 2012 14:36:43 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F4374EA.2090806@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F43710A.30001@oracle.com> <4F4374EA.2090806@oracle.com> Message-ID: <4F43F24B.9080305@oracle.com> Comments inline... updated webrev a bit later today... On 2/21/12 5:41 AM, Michael McMahon wrote: > Jim, > > Thanks for doing this. Some minor comments on the JDK changes. > > 1) the amd64 definitions in make/common/Defs-macosx.gmk are redundant now. > Maybe we should just delete them (though I agree with keeping the > runtime checks > in the .java sources) Good point. I've deleted the old amd64 references that have been replaced. > 2) the (Mac) checks for os.name have generally been using > String.startsWith() instead of equals() > so they will work with a future "Mac OS X Server" > (java/awt/GraphicsEnvironment.java). > I think there are similar checks in hotspot too. I see Mike Swingler is > suggesting > String.contains("OS X"). I'd be ok with that too. For these set of changes, I've switched to Mike's suggestion. Perhaps we can switch the other callsites (unrelated to this change) as part of a general cleanup in JDK8. > 3) one other location where a check needs to be added is: > java/nio/Bits.java Done! > Also, I don't see any code in Hotspot that checks for the new "x86_64" > value. > So, is it actually necessary for the hotspot change to be integrated first? Yup, still necessary. There is a reference in ... agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java - Jim > > - Michael, > > On 20/02/12 21:02, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From james.melvin at oracle.com Tue Feb 21 15:08:56 2012 From: james.melvin at oracle.com (James Melvin) Date: Tue, 21 Feb 2012 18:08:56 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F42B4D5.2000004@oracle.com> References: <4F42B4D5.2000004@oracle.com> Message-ID: <4F442408.3070807@oracle.com> Thanks for the reviews! Updated webrevs with all comments... http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 Main changes were to refine the use of string compares for Mac OS X... < osName.startsWith("Mac OS") > osName.contains("OS X") Any final comments? A decision has not yet been made to include this change or not. I'll provide an update when there's progress. - Jim On 2/20/12 4:02 PM, James Melvin wrote: > Hi, > > To maintain compatibility with Apple JDKs, a proposal will be made to > change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS > X. Minor changes are required to the following repositories, for which > I've provided webrevs... > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 > > TESTING: > JPRT job (2012-02-20-203901.jmelvin.hotspot) > Notepad, SwingSet2, SPECjbb2005 > > This change will also impact a small number of internal tests and RE > scripts. The bundle names will also reflect the change amd64 -> x86_64. > HotSpot changes can be integrated first, with the JDK changes in the > following promotion. Should the proposal be rejected for 7u4, I > obviously withdraw the bugfix. > > Feedback welcome, > > Jim From mikael.gerdin at oracle.com Wed Feb 22 00:44:36 2012 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 22 Feb 2012 09:44:36 +0100 Subject: Review request: White box testing API for HotSpot In-Reply-To: <4F426D20.5030009@oracle.com> References: <4ED50287.3070102@oracle.com> <4F0C910A.5070205@oracle.com> <4F0E8B10.3030600@oracle.com> <4F0F0850.8050402@oracle.com> <4F0F6605.5080900@oracle.com> <4F15951D.7080508@oracle.com> <5439AE12-6AC7-4DE4-B8B2-2626DE876965@oracle.com> <4F3E6E4C.2050308@oracle.com> <4F3EDA8D.9040505@oracle.com> <4F426A29.7030805@oracle.com> <4F426D20.5030009@oracle.com> Message-ID: <4F44AAF4.2070400@oracle.com> Forgot to reply-all.. On 2012-02-20 16:56, Paul Hohensee wrote: > Not quite there yet. > > The copyright year in the new files is now "2011, 2012" when it should > just be "2012". The new code didn't get pushed in 2011. :) > > make/jprt.properties still needs a copyright year of 2012 instead of 2011. Ok, new webrev at http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.8/ Thanks /Mikael > > Paul > > On 2/20/12 10:43 AM, Mikael Gerdin wrote: >> Hi Paul, >> >> On 2012-02-17 23:54, Paul Hohensee wrote: >>> Thanks for doing this, it's something I've been wanting to see in >>> Hotspot >>> for quite awhile. :) >>> >>> Looks good. You'll need a GC reviewer for the whitebox.cpp method >>> content. >> >> Right. Some of the GC functions were more or less examples of what >> could be done and were not very useful besides that. I removed the >> most obscure ones at least but I'll keep some core functions. >> >>> >>> A few small things: >>> >>> In globals.hpp, add a blank line ending in '\' before the declaration of >>> WhiteBoxAPI. >> >> Done >> >>> >>> The copyright year in the all the new files should be 2012. Same with >>> all the old files except make/Makefile, nativeLookup.cpp, >>> make/bsd/makefiles/defs.make, >>> arguments.cpp, globals.hpp and vmError.cpp, which already have 2012. >> >> I think I updated all of them. >> >>> >>> What's the rationale for the directory path (' >>> ||src/share/tools/whitebox/src/classes/ >>> sun/hotspot') used to get to WhiteBox.java? Seems a bit long. >> >> It made more sense when there was a native library part living in >> src/share/tools/whitebox/src/native >> I changed it to >> src/share/tools/whitebox >> >> >>> >>> In whitebox.hpp, use SHARE_VM_PRIMS_WHITEBOX_HPP instead of >>> SHARE_VM_PRIMS_WHITEBOX_H. >> >> Done >> >> New webrev at: http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.7/ >> >> Thanks for looking at this. >> >> /Mikael >> >>> >>> Thanks, >>> >>> Paul >>> >>> On 2/17/12 10:12 AM, Mikael Gerdin wrote: >>>> I gave up on getting this into HS23 and was busy doing other stuff for >>>> HS23. >>>> Anyway, there were some issues with the last patch so here's a rebased >>>> webrev that actually compiles :) >>>> >>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.5/ >>>> >>>> /Mikael >>>> >>>> On 2012-02-17 12:21, Nils Loodin wrote: >>>>> Sooo, what happened with this? >>>>> >>>>> I think that testing this framework would be an excellent fit for >>>>> using in testing our diagnostic framework. >>>>> But it kind of depends on this being actually checked in :) >>>>> >>>>> /Nisse >>>>> >>>>> On Jan 17, 2012, at 16:34 , Mikael Gerdin wrote: >>>>> >>>>>> David, >>>>>> >>>>>> On 2012-01-13 00:00, David Holmes wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> On 13/01/2012 2:20 AM, Mikael Gerdin wrote: >>>>>>>>> wbapi.java: normal Java naming style is to use camel-case for >>>>>>>>> class >>>>>>>>> names. Though as WB is itself an acronym I'd be okay with WBApi. >>>>>>>>> In fact >>>>>>>>> I'd be happy with anything other than initial lower-case :) >>>>>>>> >>>>>>>> Many of our existing tests have lower-case names so I guess I >>>>>>>> thought >>>>>>>> that was some sort of convention, it does not really matter to me. >>>>>>> >>>>>>> I think those tests must have been written by C programers ;-) >>>>>>> >>>>>>>> WBApi it is then. >>>>>>> >>>>>>> Thanks.There is a slight typo in that the file is WBapi.java not >>>>>>> WBApi.java >>>>>> >>>>>> Fixed. >>>>>> >>>>>> I also re-ran JPRT to verify that it still builds on all platforms >>>>>> and found that the size of a region in G1 had changed to size_t, so >>>>>> I added a cast to jint (region sizes of>2G seems to be unreasonable). >>>>>> >>>>>> I also tried with Jim Melvin's patch to run OS X and verified that >>>>>> "wbapitest" works on OS X as well. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> test/Makefile: does wbapitest need to be added to the phoney list? >>>>>>>> >>>>>>>> Yes, fixed. >>>>>>>> >>>>>>>> New webrev at: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.3/ >>>>>>>> Incremental at: >>>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2-to-3/webrev/ >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/01/2012 5:27 AM, Mikael Gerdin wrote: >>>>>>>>>> Hi all >>>>>>>>>> >>>>>>>>>> Back from vacations now with an updated version of the webrev >>>>>>>>>> based on >>>>>>>>>> the feedback received in this thread. >>>>>>>>>> Changes include: >>>>>>>>>> * removed install target from makefiles >>>>>>>>>> * renamed flag form EnableWhiteBoxAPI to remove redundant Enable >>>>>>>>>> * installs wb.jar into jre/lib and made -XX:+WhiteBoxAPI add >>>>>>>>>> wb.jar to >>>>>>>>>> the boot class path from inside the VM. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~mgerdin/wbapi/webrev.2/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Mikael Gerdin >>>>>>>>>> >>>>>>>>>> On 2011-11-29 17:04, Mikael Gerdin wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> I've been working on a white box testing API for HotSpot in >>>>>>>>>>> order to >>>>>>>>>>> allow for improved precision in vm testing. >>>>>>>>>>> >>>>>>>>>>> The basic idea is to open up the possibility for tests written >>>>>>>>>>> in Java >>>>>>>>>>> to call native methods which query or poke the vm in some way. >>>>>>>>>>> >>>>>>>>>>> The API is accessible by using the class sun/hotspot/WhiteBox >>>>>>>>>>> which is >>>>>>>>>>> not intended to be available in public builds. >>>>>>>>>>> In order to allow the WhiteBox class access to the VM the >>>>>>>>>>> registerNatives function is linked to >>>>>>>>>>> JVM_RegisterWhiteBoxMethods. >>>>>>>>>>> That >>>>>>>>>>> function then links all the implementation functions using >>>>>>>>>>> normal JNI >>>>>>>>>>> RegisterNatives. >>>>>>>>>>> >>>>>>>>>>> The API is not meant to be used by end users for any intent or >>>>>>>>>>> purpose >>>>>>>>>>> and as such it is both guarded by >>>>>>>>>>> "-XX:+UnlockDiagnosticVMOptions >>>>>>>>>>> -XX:+EnableWhiteboxAPI" and the fact that the class files will >>>>>>>>>>> not be >>>>>>>>>>> present in an end user build of a JDK. >>>>>>>>>>> If the VM crashes after this API has been accessed a note >>>>>>>>>>> will be >>>>>>>>>>> written in the hs_err file to signal that the API has been used. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~stefank/mgerdin/wbapi.0/webrev/ >>>>>>>>>>> (thanks to stefank for hosting my webrev :) >>>>>>>>>>> >>>>>>>>>>> CR: >>>>>>>>>>> I'll file a CR tomorrow. >>>>>>>>>>> >>>>>>>>>>> Change comments: >>>>>>>>>>> >>>>>>>>>>> make/jprt.properties >>>>>>>>>>> >>>>>>>>>>> Add a test target to make sure that the API is available on all >>>>>>>>>>> supported platforms >>>>>>>>>>> >>>>>>>>>>> make/** >>>>>>>>>>> >>>>>>>>>>> Makefile changes to build the class sun/hotspot/WhiteBox, put >>>>>>>>>>> it in a >>>>>>>>>>> JAR file and copy it to the jre/lib/endorsed directory in the >>>>>>>>>>> export >>>>>>>>>>> targets. >>>>>>>>>>> The BSD makefile changes are not tested since I don't have >>>>>>>>>>> access to >>>>>>>>>>> any >>>>>>>>>>> BSD/OSX machine to test them on. >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/nativeLookup.cpp >>>>>>>>>>> >>>>>>>>>>> Special-case the method sun/hotspot/WhiteBox/registerNatives and >>>>>>>>>>> link it >>>>>>>>>>> to JVM_RegisterWhiteBoxMethods >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/whitebox.* >>>>>>>>>>> >>>>>>>>>>> The implementation of the white box API. The actual API >>>>>>>>>>> functions are >>>>>>>>>>> only examples of what we want to be able to do using the API. >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/globals.hpp >>>>>>>>>>> >>>>>>>>>>> Add the command line flag >>>>>>>>>>> >>>>>>>>>>> src/share/vm/utilities/vmError.cpp >>>>>>>>>>> >>>>>>>>>>> Print a message in hs_err files when white box API has been >>>>>>>>>>> used. >>>>>>>>>>> >>>>>>>>>>> test/Makefile >>>>>>>>>>> >>>>>>>>>>> Add a makefile test target for the white box API test >>>>>>>>>>> >>>>>>>>>>> test/sanity/wbapi.java >>>>>>>>>>> >>>>>>>>>>> JTreg test to ensure that the API works. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> /Mikael Gerdin >>>>>>>>>> >>>>> From swingler at apple.com Tue Feb 21 15:36:50 2012 From: swingler at apple.com (Mike Swingler) Date: Tue, 21 Feb 2012 15:36:50 -0800 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F442408.3070807@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <904960FF-4162-473B-B8D0-EDD33158506B@apple.com> Looks good to me. Regards, Mike Swingler Apple Inc. On Feb 21, 2012, at 3:08 PM, James Melvin wrote: > Thanks for the reviews! Updated webrevs with all comments... > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 > > Main changes were to refine the use of string compares for Mac OS X... > > < osName.startsWith("Mac OS") > > osName.contains("OS X") > > Any final comments? A decision has not yet been made to include this > change or not. I'll provide an update when there's progress. > > - Jim > > > > On 2/20/12 4:02 PM, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From paul.hohensee at oracle.com Wed Feb 22 09:49:56 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 22 Feb 2012 12:49:56 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F442408.3070807@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <4F452AC4.10504@oracle.com> Looks good. Paul On 2/21/12 6:08 PM, James Melvin wrote: > Thanks for the reviews! Updated webrevs with all comments... > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 > > Main changes were to refine the use of string compares for Mac OS X... > > < osName.startsWith("Mac OS") > > osName.contains("OS X") > > Any final comments? A decision has not yet been made to include this > change or not. I'll provide an update when there's progress. > > - Jim > > > > On 2/20/12 4:02 PM, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From kelly.ohair at oracle.com Wed Feb 22 09:51:34 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 22 Feb 2012 09:51:34 -0800 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F442408.3070807@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: Sorry I'm slow on the review. Just a few comments, not sure any of it would cause me to reject your changes. On Feb 21, 2012, at 3:08 PM, James Melvin wrote: > Thanks for the reviews! Updated webrevs with all comments... > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 Just FYI. I use startsWith("Mac"). But I'm not sure I have an opinion what you should use. Seems like this comment was wrong to begin with, and is wrong now: 55 /* Returns "sparc" if on SPARC, "x86" if on x86. */ 56 public static String getCPU() throws UnsupportedPlatformException { It returns a wide variety of values. :^( > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 There are 4 critical ARCH weapons, all of them have inconsistencies and risks when sharpened or changed: 1. LIBARCH or the name in the install trees, e.g. lib/sparc, lib/i386, lib/amd64 2. os.arch, or what the Java property value is, e.g. x86, sparc, i586, i386?, sparcv9, amd64, x86_64,... 3. The arch name used in the bundle names, e.g. sparc, x86, x64, etc. 4. The arch name used in the build directories, e.g. build/solaris-sparc, build/solaris-x64, ... However, like the Monty Python Spanish Inquisition, http://www.youtube.com/watch?v=vt0Y39eMvpI, nobody really remembers what the real weapon list is. :^( But I digress... In the Makefiles, I was trying to limit the ARCH values, and for 64bit x86 I have tried to use x64 or X64 and have been trying to avoid amd64 or x86_64. This is separate from the above weapon list, they all do not and probably can never all be the same, but where we can avoid repeating the same ARCH with a different spelling, we should. I think the bottom line is that the Defs-macos.gmk and Platform.gmk file probably could be trimmed down for Mac, but I don;t see a pressing need right now. > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 Not sure this change is necessary, corba no longer compiles any native code. But it seems harmless. -kto > > Main changes were to refine the use of string compares for Mac OS X... > > < osName.startsWith("Mac OS") > > osName.contains("OS X") > > Any final comments? A decision has not yet been made to include this > change or not. I'll provide an update when there's progress. > > - Jim > > > > On 2/20/12 4:02 PM, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From swingler at apple.com Wed Feb 22 10:09:38 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 22 Feb 2012 10:09:38 -0800 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <975DB5D1-ADBE-48B0-995F-AEC8661B3DD5@apple.com> On Feb 22, 2012, at 9:51 AM, Kelly O'Hair wrote: > On Feb 21, 2012, at 3:08 PM, James Melvin wrote: > >> Thanks for the reviews! Updated webrevs with all comments... >> >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > > Just FYI. I use startsWith("Mac"). But I'm not sure I have an opinion what you should use. To this point, everyone should use .contains("OS X") now: Regards, Mike Swingler Apple Inc. From tom.rodriguez at oracle.com Wed Feb 22 11:37:21 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Feb 2012 11:37:21 -0800 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <4F452B53.9050600@oracle.com> References: <4F452B53.9050600@oracle.com> Message-ID: <29958905-6866-43E5-BCB4-EF85DE4376BE@oracle.com> On Feb 22, 2012, at 9:52 AM, Joe Provino wrote: > Webrev is here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ > > These changes allow the JVM to be built without optional functional areas. > > Individual functional areas can be added back in as desired. > > Do you have any data on the resulting library size reductions? I haven't reviewed the makefile changes but I looked at all the code. Overall the idea seems ok but I have a lot of comments on the details. Instead of sprinkling #ifdef INCLUDE_JVMTI I think it would be cleaner to factor those chunks out as much as possible and ifdef them in JvmtiExport. So something like this: + #ifdef INCLUDE_JVMTI if (JvmtiExport::should_post_data_dump()) { JvmtiExport::post_data_dump(); } + #endif // INCLUDE_JVMTI would be: JvmtiExport::maybe_post_data_dump(); with: class JvmtiExport { ? void maybe_post_data_dump() { #ifdef INCLUDE_JVMTI if (should_post_data_dump()) { post_data_dump(); } + #endif // INCLUDE_JVMTI } or if should_post_data_dump always returned false and post_data_dump was empty then the outer ifdef wouldn't be needed all. Either way would concentrate the ifdef's without cluttering up the rest of the source so much. I think in cases where they are larger chunks inside the if, then that should be moved into JvmtiExport as well. It won't work for everything but it will work for most things. In macros.hpp, most (all?) of the new _RETURN macros have their sense inverted from the norm. PRODUCT_RETURN means ifdef PRODUCT then return. The new ones do if !macro then return. MINIMAL_JVM_RETURN has the proper sense. I would also like to avoid ifdefs in the middle of expressions. Can't those be handled by NOT_JVMTI_RETURN_(false)? I think the changes in deoptimization.cpp don't look right. I think can_pop_frame should return false if JVMTI is disabled. The ifdefs act as if it returned true. The ifdef in instanceKlassKlass.cpp seems to cover too much code. Why are you keeping the ifdef KERNEL code in systemDictionary.cpp? It can always be resurrected from the history if it's needed. I see changes in templateTable_x86_32.cpp but not in the other platform dependent templateTable code. Why is that? tom From nils.eliasson at oracle.com Wed Feb 22 12:55:09 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 22 Feb 2012 21:55:09 +0100 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <4F452B53.9050600@oracle.com> References: <4F452B53.9050600@oracle.com> Message-ID: <4F45562D.7040407@oracle.com> Hi, You need to change kernel -> minimal in src/share/tools/ProjectCreator/BuildConfig.java line 580-597, otherwise the vcprojs for kernel/minimal will stop working. Regards, Nils Joe Provino skrev 2012-02-22 18:52: > Webrev is > here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ > > > These changes allow the JVM to be built without optional functional > areas. > > Individual functional areas can be added back in as desired. > > -- Oracle Nils Eliasson | Senior Member of Technical Staff Oracle Java Platform Group, JVM Engineering ORACLE Sweden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120222/69542639/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120222/69542639/oracle_sig_logo.gif From artem.ananiev at oracle.com Wed Feb 22 11:37:59 2012 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Wed, 22 Feb 2012 23:37:59 +0400 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F442408.3070807@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <4F454417.2020202@oracle.com> Hi, Jim, as we discussed in another thread, the DISPLAY variable should not be checked on Mac OS X in GraphicsEnvironment.java, so please remove it from the webrev. Thanks, Artem On 2/22/2012 3:08 AM, James Melvin wrote: > Thanks for the reviews! Updated webrevs with all comments... > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 > > Main changes were to refine the use of string compares for Mac OS X... > > < osName.startsWith("Mac OS") > > osName.contains("OS X") > > Any final comments? A decision has not yet been made to include this > change or not. I'll provide an update when there's progress. > > - Jim > > > > On 2/20/12 4:02 PM, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From joseph.provino at oracle.com Wed Feb 22 09:52:19 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 22 Feb 2012 12:52:19 -0500 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" Message-ID: <4F452B53.9050600@oracle.com> Webrev is here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ These changes allow the JVM to be built without optional functional areas. Individual functional areas can be added back in as desired. From joseph.provino at oracle.com Wed Feb 22 13:05:01 2012 From: joseph.provino at oracle.com (Joe Provino) Date: Wed, 22 Feb 2012 16:05:01 -0500 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <4F45562D.7040407@oracle.com> References: <4F452B53.9050600@oracle.com> <4F45562D.7040407@oracle.com> Message-ID: <4F45587D.3080005@oracle.com> On 02/22/2012 03:55 PM, Nils Eliasson wrote: > Hi, > > You need to change kernel -> minimal in > src/share/tools/ProjectCreator/BuildConfig.java line 580-597, > otherwise the vcprojs for kernel/minimal will stop working. okay, thanks. joe > > Regards, > Nils > > Joe Provino skrev 2012-02-22 18:52: >> Webrev is >> here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ >> >> >> These changes allow the JVM to be built without optional functional >> areas. >> >> Individual functional areas can be added back in as desired. >> >> > > > -- > Oracle > Nils Eliasson | Senior Member of Technical Staff > Oracle Java Platform Group, JVM Engineering > ORACLE Sweden > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120222/6d854ec8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 658 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120222/6d854ec8/attachment.gif From frederic.parain at oracle.com Wed Feb 22 14:44:27 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 22 Feb 2012 22:44:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120222224439.6AEDB47633@hg.openjdk.java.net> Changeset: 86ce3208eb18 Author: dcubed Date: 2012-02-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/86ce3208eb18 7145798: System.loadLibrary does not search current working directory Summary: Append "." to java.library.path on MacOS X to ease migration from Apple's Java6 to OpenJDK7. Reviewed-by: phh, jmelvin, coleenp ! src/os/bsd/vm/os_bsd.cpp Changeset: 0368109684cb Author: sla Date: 2012-02-19 13:11 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0368109684cb 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX Summary: Change OSThread to use mach thread_t Reviewed-by: phh, dcubed ! src/cpu/x86/vm/vm_version_x86.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: 38fd165da001 Author: poonam Date: 2012-02-20 21:27 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/38fd165da001 7145358: SA throws ClassCastException for partially loaded ConstantPool Summary: In printValueOn() in ConstantPool.java check if the poolHolder is a valid Klass and only then print it. Reviewed-by: sla, sspitsyn Contributed-by: Krystal Mok ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java Changeset: 1a4e5feb63c4 Author: fparain Date: 2012-02-22 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a4e5feb63c4 Merge From james.melvin at oracle.com Wed Feb 22 15:03:35 2012 From: james.melvin at oracle.com (James Melvin) Date: Wed, 22 Feb 2012 18:03:35 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <4F457447.2000504@oracle.com> Thanks Kelly. See below for some follow ups... On 2/22/12 12:51 PM, Kelly O'Hair wrote: > Sorry I'm slow on the review. > > Just a few comments, not sure any of it would cause me to reject your changes. > > > On Feb 21, 2012, at 3:08 PM, James Melvin wrote: > >> Thanks for the reviews! Updated webrevs with all comments... >> >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > > Just FYI. I use startsWith("Mac"). But I'm not sure I have an opinion what you should use. Based on Mike Swingler's advice, I've changed all the affected callsites for this change to use .contains("OS X"). > > Seems like this comment was wrong to begin with, and is wrong now: > > 55 /* Returns "sparc" if on SPARC, "x86" if on x86. */ > 56 public static String getCPU() throws UnsupportedPlatformException { > It returns a wide variety of values. :^( Good observation. Let me update the comment with something more appropriate. > > >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 > > There are 4 critical ARCH weapons, all of them have inconsistencies and risks when sharpened or changed: > 1. LIBARCH or the name in the install trees, e.g. lib/sparc, lib/i386, lib/amd64 > 2. os.arch, or what the Java property value is, e.g. x86, sparc, i586, i386?, sparcv9, amd64, x86_64,... > 3. The arch name used in the bundle names, e.g. sparc, x86, x64, etc. > 4. The arch name used in the build directories, e.g. build/solaris-sparc, build/solaris-x64, ... > > However, like the Monty Python Spanish Inquisition, http://www.youtube.com/watch?v=vt0Y39eMvpI, > nobody really remembers what the real weapon list is. :^( > > But I digress... In the Makefiles, I was trying to limit the ARCH values, and for 64bit x86 > I have tried to use x64 or X64 and have been trying to avoid amd64 or x86_64. > This is separate from the above weapon list, they all do not and probably can never all be the > same, but where we can avoid repeating the same ARCH with a different spelling, we should. > > I think the bottom line is that the Defs-macos.gmk and Platform.gmk file probably could be trimmed > down for Mac, but I don;t see a pressing need right now. Agreed. The likely time to consolidate is when we reconcile the Unix platforms. I imagine we'll commit to this at some point. > >> http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 > > Not sure this change is necessary, corba no longer compiles any native code. > But it seems harmless. Although it's unlikely corba will revert to using native code, so this change is mainly to be consistent with the jdk repo. - Jim > > -kto > > >> >> Main changes were to refine the use of string compares for Mac OS X... >> >> < osName.startsWith("Mac OS") >>> osName.contains("OS X") >> >> Any final comments? A decision has not yet been made to include this >> change or not. I'll provide an update when there's progress. >> >> - Jim >> >> >> >> On 2/20/12 4:02 PM, James Melvin wrote: >>> Hi, >>> >>> To maintain compatibility with Apple JDKs, a proposal will be made to >>> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >>> X. Minor changes are required to the following repositories, for which >>> I've provided webrevs... >>> >>> WEBREV: >>> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >>> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >>> >>> TESTING: >>> JPRT job (2012-02-20-203901.jmelvin.hotspot) >>> Notepad, SwingSet2, SPECjbb2005 >>> >>> This change will also impact a small number of internal tests and RE >>> scripts. The bundle names will also reflect the change amd64 -> x86_64. >>> HotSpot changes can be integrated first, with the JDK changes in the >>> following promotion. Should the proposal be rejected for 7u4, I >>> obviously withdraw the bugfix. >>> >>> Feedback welcome, >>> >>> Jim > From james.melvin at oracle.com Wed Feb 22 15:10:05 2012 From: james.melvin at oracle.com (James Melvin) Date: Wed, 22 Feb 2012 18:10:05 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F442408.3070807@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> Message-ID: <4F4575CD.7050708@oracle.com> Updated to include latest comments... http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.02 http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 Changed... hotspot: agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java - refined method comment to be more appropriate jdk: src/share/classes/java/awt/GraphicsEnvironment.java - revert changes based on an offline discussion with AWT - Jim On 2/21/12 6:08 PM, James Melvin wrote: > Thanks for the reviews! Updated webrevs with all comments... > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.01 > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.01 > > Main changes were to refine the use of string compares for Mac OS X... > > < osName.startsWith("Mac OS") > > osName.contains("OS X") > > Any final comments? A decision has not yet been made to include this > change or not. I'll provide an update when there's progress. > > - Jim > > > > On 2/20/12 4:02 PM, James Melvin wrote: >> Hi, >> >> To maintain compatibility with Apple JDKs, a proposal will be made to >> change the 'os.arch' system property from 'amd64' to 'x86_64' on Mac OS >> X. Minor changes are required to the following repositories, for which >> I've provided webrevs... >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.00 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.00 >> >> TESTING: >> JPRT job (2012-02-20-203901.jmelvin.hotspot) >> Notepad, SwingSet2, SPECjbb2005 >> >> This change will also impact a small number of internal tests and RE >> scripts. The bundle names will also reflect the change amd64 -> x86_64. >> HotSpot changes can be integrated first, with the JDK changes in the >> following promotion. Should the proposal be rejected for 7u4, I >> obviously withdraw the bugfix. >> >> Feedback welcome, >> >> Jim From mark.reinhold at oracle.com Wed Feb 22 15:13:24 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 22 Feb 2012 15:13:24 -0800 (PST) Subject: JEP 142: Reduce Cache Contention on Specified Fields Message-ID: <20120222231324.B7B20E00@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/142 - Mark From stephen.bannasch at deanbrook.org Wed Feb 22 16:39:34 2012 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 22 Feb 2012 19:39:34 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F4575CD.7050708@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> <4F4575CD.7050708@oracle.com> Message-ID: At 6:10 PM -0500 2/22/12, James Melvin wrote: >Updated to include latest comments... > >http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 line 46 still uses: os.startsWith("Mac OS X") instead of os.contains("OS X") http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java.html From david.holmes at oracle.com Wed Feb 22 18:54:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2012 12:54:49 +1000 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <29958905-6866-43E5-BCB4-EF85DE4376BE@oracle.com> References: <4F452B53.9050600@oracle.com> <29958905-6866-43E5-BCB4-EF85DE4376BE@oracle.com> Message-ID: <4F45AA79.8030505@oracle.com> Tom, On 23/02/2012 5:37 AM, Tom Rodriguez wrote: > > On Feb 22, 2012, at 9:52 AM, Joe Provino wrote: > >> Webrev is here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ >> >> These changes allow the JVM to be built without optional functional areas. >> >> Individual functional areas can be added back in as desired. >> >> > > Do you have any data on the resulting library size reductions? > > I haven't reviewed the makefile changes but I looked at all the code. Overall the idea seems ok but I have a lot of comments on the details. > > Instead of sprinkling #ifdef INCLUDE_JVMTI I think it would be cleaner to factor those chunks out as much as possible and ifdef them in JvmtiExport. So something like this: > > + #ifdef INCLUDE_JVMTI > if (JvmtiExport::should_post_data_dump()) { > JvmtiExport::post_data_dump(); > } > + #endif // INCLUDE_JVMTI > > would be: > > JvmtiExport::maybe_post_data_dump(); The idea is to completely elide the jvmti*.cpp files from the build so there can be no JvmtiExport wrapper functions to hide the ifdef'd code. David ----- > with: > > class JvmtiExport { > ? > void maybe_post_data_dump() { > #ifdef INCLUDE_JVMTI > if (should_post_data_dump()) { > post_data_dump(); > } > + #endif // INCLUDE_JVMTI > } > > or if should_post_data_dump always returned false and post_data_dump was empty then the outer ifdef wouldn't be needed all. Either way would concentrate the ifdef's without cluttering up the rest of the source so much. I think in cases where they are larger chunks inside the if, then that should be moved into JvmtiExport as well. It won't work for everything but it will work for most things. > > In macros.hpp, most (all?) of the new _RETURN macros have their sense inverted from the norm. PRODUCT_RETURN means ifdef PRODUCT then return. The new ones do if !macro then return. MINIMAL_JVM_RETURN has the proper sense. > > I would also like to avoid ifdefs in the middle of expressions. Can't those be handled by NOT_JVMTI_RETURN_(false)? > > I think the changes in deoptimization.cpp don't look right. I think can_pop_frame should return false if JVMTI is disabled. The ifdefs act as if it returned true. > > The ifdef in instanceKlassKlass.cpp seems to cover too much code. > > Why are you keeping the ifdef KERNEL code in systemDictionary.cpp? It can always be resurrected from the history if it's needed. > > I see changes in templateTable_x86_32.cpp but not in the other platform dependent templateTable code. Why is that? > > tom From tom.rodriguez at oracle.com Wed Feb 22 18:59:26 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Feb 2012 18:59:26 -0800 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <4F45AA79.8030505@oracle.com> References: <4F452B53.9050600@oracle.com> <29958905-6866-43E5-BCB4-EF85DE4376BE@oracle.com> <4F45AA79.8030505@oracle.com> Message-ID: <5FCFB16E-BAE8-41D0-98ED-0D341247A9D1@oracle.com> On Feb 22, 2012, at 6:54 PM, David Holmes wrote: > Tom, > > On 23/02/2012 5:37 AM, Tom Rodriguez wrote: >> >> On Feb 22, 2012, at 9:52 AM, Joe Provino wrote: >> >>> Webrev is here:http://cr.openjdk.java.net/~jprovino/webrev/minimal-jvm.feb21/ >>> >>> These changes allow the JVM to be built without optional functional areas. >>> >>> Individual functional areas can be added back in as desired. >>> >>> >> >> Do you have any data on the resulting library size reductions? >> >> I haven't reviewed the makefile changes but I looked at all the code. Overall the idea seems ok but I have a lot of comments on the details. >> >> Instead of sprinkling #ifdef INCLUDE_JVMTI I think it would be cleaner to factor those chunks out as much as possible and ifdef them in JvmtiExport. So something like this: >> >> + #ifdef INCLUDE_JVMTI >> if (JvmtiExport::should_post_data_dump()) { >> JvmtiExport::post_data_dump(); >> } >> + #endif // INCLUDE_JVMTI >> >> would be: >> >> JvmtiExport::maybe_post_data_dump(); > > The idea is to completely elide the jvmti*.cpp files from the build so there can be no JvmtiExport wrapper functions to hide the ifdef'd code. I guess I was confused by all the changes in jvmtiExport.hpp. If the file isn't included in the build then why have any ifdefs in there at all? You could still do what I'm suggesting and just keep jvmtiExport.hpp around as the empty shell that produces no code. tom > > David > ----- > >> with: >> >> class JvmtiExport { >> ? >> void maybe_post_data_dump() { >> #ifdef INCLUDE_JVMTI >> if (should_post_data_dump()) { >> post_data_dump(); >> } >> + #endif // INCLUDE_JVMTI >> } >> >> or if should_post_data_dump always returned false and post_data_dump was empty then the outer ifdef wouldn't be needed all. Either way would concentrate the ifdef's without cluttering up the rest of the source so much. I think in cases where they are larger chunks inside the if, then that should be moved into JvmtiExport as well. It won't work for everything but it will work for most things. >> >> In macros.hpp, most (all?) of the new _RETURN macros have their sense inverted from the norm. PRODUCT_RETURN means ifdef PRODUCT then return. The new ones do if !macro then return. MINIMAL_JVM_RETURN has the proper sense. >> >> I would also like to avoid ifdefs in the middle of expressions. Can't those be handled by NOT_JVMTI_RETURN_(false)? >> >> I think the changes in deoptimization.cpp don't look right. I think can_pop_frame should return false if JVMTI is disabled. The ifdefs act as if it returned true. >> >> The ifdef in instanceKlassKlass.cpp seems to cover too much code. >> >> Why are you keeping the ifdef KERNEL code in systemDictionary.cpp? It can always be resurrected from the history if it's needed. >> >> I see changes in templateTable_x86_32.cpp but not in the other platform dependent templateTable code. Why is that? >> >> tom From david.holmes at oracle.com Wed Feb 22 19:48:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2012 13:48:50 +1000 Subject: Review request for "Enabling conditional inclusion of functional areas into the VM" In-Reply-To: <5FCFB16E-BAE8-41D0-98ED-0D341247A9D1@oracle.com> References: <4F452B53.9050600@oracle.com> <29958905-6866-43E5-BCB4-EF85DE4376BE@oracle.com> <4F45AA79.8030505@oracle.com> <5FCFB16E-BAE8-41D0-98ED-0D341247A9D1@oracle.com> Message-ID: <4F45B722.4000404@oracle.com> On 23/02/2012 12:59 PM, Tom Rodriguez wrote: > On Feb 22, 2012, at 6:54 PM, David Holmes wrote: >> On 23/02/2012 5:37 AM, Tom Rodriguez wrote: >>> Instead of sprinkling #ifdef INCLUDE_JVMTI I think it would be cleaner to factor those chunks out as much as possible and ifdef them in JvmtiExport. So something like this: >>> >>> + #ifdef INCLUDE_JVMTI >>> if (JvmtiExport::should_post_data_dump()) { >>> JvmtiExport::post_data_dump(); >>> } >>> + #endif // INCLUDE_JVMTI >>> >>> would be: >>> >>> JvmtiExport::maybe_post_data_dump(); >> >> The idea is to completely elide the jvmti*.cpp files from the build so there can be no JvmtiExport wrapper functions to hide the ifdef'd code. > > I guess I was confused by all the changes in jvmtiExport.hpp. If the file isn't included in the build then why have any ifdefs in there at all? Sorry my mistake. We can't completely elide all the jvmti* files as we need to be able to report that JVMTI is not supported. > You could still do what I'm suggesting and just keep jvmtiExport.hpp around as the empty shell that produces no code. Such a refactoring would look somewhat cleaner. David > tom > >> >> David >> ----- >> >>> with: >>> >>> class JvmtiExport { >>> ? >>> void maybe_post_data_dump() { >>> #ifdef INCLUDE_JVMTI >>> if (should_post_data_dump()) { >>> post_data_dump(); >>> } >>> + #endif // INCLUDE_JVMTI >>> } >>> >>> or if should_post_data_dump always returned false and post_data_dump was empty then the outer ifdef wouldn't be needed all. Either way would concentrate the ifdef's without cluttering up the rest of the source so much. I think in cases where they are larger chunks inside the if, then that should be moved into JvmtiExport as well. It won't work for everything but it will work for most things. >>> >>> In macros.hpp, most (all?) of the new _RETURN macros have their sense inverted from the norm. PRODUCT_RETURN means ifdef PRODUCT then return. The new ones do if !macro then return. MINIMAL_JVM_RETURN has the proper sense. >>> >>> I would also like to avoid ifdefs in the middle of expressions. Can't those be handled by NOT_JVMTI_RETURN_(false)? >>> >>> I think the changes in deoptimization.cpp don't look right. I think can_pop_frame should return false if JVMTI is disabled. The ifdefs act as if it returned true. >>> >>> The ifdef in instanceKlassKlass.cpp seems to cover too much code. >>> >>> Why are you keeping the ifdef KERNEL code in systemDictionary.cpp? It can always be resurrected from the history if it's needed. >>> >>> I see changes in templateTable_x86_32.cpp but not in the other platform dependent templateTable code. Why is that? >>> >>> tom > From kirk at kodewerk.com Wed Feb 22 20:40:56 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 23 Feb 2012 05:40:56 +0100 Subject: JEP 142: Reduce Cache Contention on Specified Fields In-Reply-To: <20120222231324.B7B20E00@eggemoggin.niobe.net> References: <20120222231324.B7B20E00@eggemoggin.niobe.net> Message-ID: Hi all, Very nice development!. A common problem for hand rolled solutions is that the padding gets DVE'd. How do you plan on "telling" the compiler to split fields? Will there be a diagnostic for the feature? FYI, a couple of us are working on jPCM (on java.net) which is an extension of some Intel code that peeks down into CPU counters for L2/L3 cache hit/miss ratios. We also plan on exposing the TLAB hit/miss ratios for predicting usefulness of large pages as well as (cpu) socket read write rates for other potential optimizations. I've started on a VisualVM plugin for the module Regards, Kirk From david.holmes at oracle.com Wed Feb 22 21:08:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2012 15:08:32 +1000 Subject: JEP 142: Reduce Cache Contention on Specified Fields In-Reply-To: <20120222231324.B7B20E00@eggemoggin.niobe.net> References: <20120222231324.B7B20E00@eggemoggin.niobe.net> Message-ID: <4F45C9D0.2030902@oracle.com> On 23/02/2012 9:13 AM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/142 Is this the @Contended proposal which has often been mentioned on the concurrency-interest list? David From paul.hohensee at oracle.com Fri Feb 24 08:57:30 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Fri, 24 Feb 2012 11:57:30 -0500 Subject: CFV: New HSX Reviewer: Bengt Rutisson Message-ID: <4F47C17A.2080609@oracle.com> I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. Bengt has been a Committer on the HSX project for some time and is also a Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in Hotspot's GC group, working on G1 primarily, and is involved in all aspects of GC work and planning. He's pushed 30 significant changesets, been proxy for four more, and has been a de-facto in-depth GC reviewer for quite awhile. The GC group relies on his expertise. Bengt is thus well- qualified to be a Reviewer on the HSX project. Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 (two week voting period). Only current HSX project Reviewers [2] are eligible to vote on this nomination. For Three-Vote Consensus voting instructions, see [3]. Regards, Paul Hohensee [0] http://openjdk.java.net/census/#hsx [1] http://openjdk.java.net/bylaws#reviewer [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://openjdk.java.net/bylaws#three-vote-consensus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120224/bf96704f/attachment.html From daniel.daugherty at oracle.com Fri Feb 24 09:09:12 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 24 Feb 2012 10:09:12 -0700 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F47C438.3050804@oracle.com> Vote: yes Dan On 2/24/12 9:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all > aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120224/9d49d72c/attachment.html From keith.mcguigan at oracle.com Fri Feb 24 09:10:31 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 24 Feb 2012 12:10:31 -0500 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F47C487.3070005@oracle.com> Vote: yes On 2/24/2012 11:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From vladimir.kozlov at oracle.com Fri Feb 24 09:24:10 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Feb 2012 09:24:10 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F47C7BA.3070007@oracle.com> Vote: yes On 2/24/12 8:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From jon.masamitsu at oracle.com Fri Feb 24 09:47:47 2012 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 24 Feb 2012 09:47:47 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F47CD43.5080003@oracle.com> Vote: yes On 2/24/2012 8:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all > aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > > From tom.rodriguez at oracle.com Fri Feb 24 10:00:51 2012 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 24 Feb 2012 10:00:51 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <06664F28-763A-4C53-84B8-FD2B19B35AAC@oracle.com> Vote: yes On Feb 24, 2012, at 8:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From John.Coomes at oracle.com Fri Feb 24 11:35:20 2012 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 24 Feb 2012 11:35:20 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <20295.59000.476640.960290@oracle.com> Vote: yes From john.r.rose at oracle.com Fri Feb 24 11:46:18 2012 From: john.r.rose at oracle.com (John Rose) Date: Fri, 24 Feb 2012 11:46:18 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <6596AC15-9C04-4BED-B6B7-8D17C5366A28@oracle.com> Vote: yes From Dmitry.Samersoff at oracle.com Fri Feb 24 11:50:06 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 24 Feb 2012 23:50:06 +0400 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <6596AC15-9C04-4BED-B6B7-8D17C5366A28@oracle.com> References: <4F47C17A.2080609@oracle.com> <6596AC15-9C04-4BED-B6B7-8D17C5366A28@oracle.com> Message-ID: <4F47E9EE.6070806@oracle.com> Vote: yes -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From karen.kinnear at oracle.com Fri Feb 24 12:40:55 2012 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 24 Feb 2012 15:40:55 -0500 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: Vote: yes Karen On Feb 24, 2012, at 11:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120224/b839969b/attachment.html From tony.printezis at oracle.com Fri Feb 24 13:05:26 2012 From: tony.printezis at oracle.com (Tony Printezis) Date: Fri, 24 Feb 2012 16:05:26 -0500 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F47FB96.6070507@oracle.com> Vote: yes (gee, that was an easy one!!!) Tony On 2/24/2012 11:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all > aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120224/9684c017/attachment.html From ysr1729 at gmail.com Fri Feb 24 13:28:48 2012 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 24 Feb 2012 13:28:48 -0800 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: Vote: yes - ramki (openjdk: ysr) On Fri, Feb 24, 2012 at 8:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120224/758cc481/attachment.html From david.holmes at oracle.com Fri Feb 24 14:18:23 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Feb 2012 08:18:23 +1000 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: <4F480CAF.1060302@oracle.com> Vote: Yes David On 25/02/2012 2:57 AM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project > Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this > nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > From vladimir.danushevsky at oracle.com Fri Feb 24 17:33:14 2012 From: vladimir.danushevsky at oracle.com (vladimir.danushevsky at oracle.com) Date: Sat, 25 Feb 2012 01:33:14 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20120225013322.D642C476A7@hg.openjdk.java.net> Changeset: d9b93445a67c Author: vladidan Date: 2012-02-15 20:26 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d9b93445a67c 7129401: PPC: runtime/7100935/TestShortArraycopy.java fails Summary: pass assembler switches for PPC Reviewed-by: dholmes ! make/linux/makefiles/ppc.make Changeset: d79f8393df2b Author: bpittore Date: 2012-02-22 14:00 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d79f8393df2b Merge Changeset: 701a83c86f28 Author: jiangli Date: 2012-02-21 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/701a83c86f28 7120481: storeStore barrier in constructor with final field Summary: Issue storestore barrier before constructor return if the constructor write final field. Reviewed-by: dholmes, jrose, roland, coleenp Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 398c5d0fb0ae Author: bpittore Date: 2012-02-23 21:10 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/398c5d0fb0ae Merge From john.coomes at oracle.com Fri Feb 24 20:05:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 25 Feb 2012 04:05:59 +0000 Subject: hg: hsx/hsx24/hotspot: 13 new changesets Message-ID: <20120225040625.08A61476AA@hg.openjdk.java.net> Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags Changeset: 0ed0960af27d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0ed0960af27d Added tag jdk8-b27 for changeset 3b24e7e01d20 ! .hgtags Changeset: 86ce3208eb18 Author: dcubed Date: 2012-02-17 15:55 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/86ce3208eb18 7145798: System.loadLibrary does not search current working directory Summary: Append "." to java.library.path on MacOS X to ease migration from Apple's Java6 to OpenJDK7. Reviewed-by: phh, jmelvin, coleenp ! src/os/bsd/vm/os_bsd.cpp Changeset: 0368109684cb Author: sla Date: 2012-02-19 13:11 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/0368109684cb 7132070: Use a mach_port_t as the OSThread thread_id rather than pthread_t on BSD/OSX Summary: Change OSThread to use mach thread_t Reviewed-by: phh, dcubed ! src/cpu/x86/vm/vm_version_x86.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: 38fd165da001 Author: poonam Date: 2012-02-20 21:27 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/38fd165da001 7145358: SA throws ClassCastException for partially loaded ConstantPool Summary: In printValueOn() in ConstantPool.java check if the poolHolder is a valid Klass and only then print it. Reviewed-by: sla, sspitsyn Contributed-by: Krystal Mok ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java Changeset: 1a4e5feb63c4 Author: fparain Date: 2012-02-22 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1a4e5feb63c4 Merge Changeset: d9b93445a67c Author: vladidan Date: 2012-02-15 20:26 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d9b93445a67c 7129401: PPC: runtime/7100935/TestShortArraycopy.java fails Summary: pass assembler switches for PPC Reviewed-by: dholmes ! make/linux/makefiles/ppc.make Changeset: d79f8393df2b Author: bpittore Date: 2012-02-22 14:00 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/d79f8393df2b Merge Changeset: 701a83c86f28 Author: jiangli Date: 2012-02-21 13:14 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/701a83c86f28 7120481: storeStore barrier in constructor with final field Summary: Issue storestore barrier before constructor return if the constructor write final field. Reviewed-by: dholmes, jrose, roland, coleenp Contributed-by: Jiangli Zhou ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 398c5d0fb0ae Author: bpittore Date: 2012-02-23 21:10 -0500 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/398c5d0fb0ae Merge Changeset: 975c4105f1e2 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/975c4105f1e2 Merge Changeset: b183b0863611 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b183b0863611 Added tag hs24-b01 for changeset 975c4105f1e2 ! .hgtags From john.coomes at oracle.com Fri Feb 24 23:51:35 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 25 Feb 2012 07:51:35 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20120225075149.D4E41476B4@hg.openjdk.java.net> Changeset: 931e5f39e365 Author: kvn Date: 2012-02-20 13:11 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/931e5f39e365 7147064: assert(allocates2(pc)) failed: not in CodeBuffer memory: 0xffffffff778d9d60 <= 0xffffffff778da69c Summary: Increase size of deopt_blob and uncommon_trap_blob by size of stack bang code (SPARC). Reviewed-by: azeemj, iveresov, never, phh ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: 3b24e7e01d20 Author: jcoomes Date: 2012-02-20 22:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3b24e7e01d20 Added tag hs23-b16 for changeset 931e5f39e365 ! .hgtags Changeset: 0ed0960af27d Author: katleman Date: 2012-02-23 12:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0ed0960af27d Added tag jdk8-b27 for changeset 3b24e7e01d20 ! .hgtags Changeset: 975c4105f1e2 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/975c4105f1e2 Merge Changeset: b183b0863611 Author: amurillo Date: 2012-02-24 18:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b183b0863611 Added tag hs24-b01 for changeset 975c4105f1e2 ! .hgtags Changeset: 694fd3171eb0 Author: amurillo Date: 2012-02-24 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/694fd3171eb0 7148664: new hotspot build - hs24-b02 Reviewed-by: jcoomes ! make/hotspot_version From jesper.wilhelmsson at oracle.com Sun Feb 26 14:31:26 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sun, 26 Feb 2012 23:31:26 +0100 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: Vote: yes /Jesper 24 feb 2012 kl. 17:57 skrev Paul Hohensee : > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120226/5d496cc0/attachment.html From james.melvin at oracle.com Sun Feb 26 19:57:06 2012 From: james.melvin at oracle.com (James Melvin) Date: Sun, 26 Feb 2012 22:57:06 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> <4F4575CD.7050708@oracle.com> Message-ID: <4F4AFF12.5010105@oracle.com> Hi Stephen, The scope of the work for 7130404 is to... 1) Convert os.arch callsites to use 'x86_64' instead of 'amd64' 2) Add *missing* os.name callsites for Mac OS X I did not originally plan to fixup *existing* os.name callsites. However, your review has inspired me to expand the scope of 7130404 to do just that. I walked the ~300 os.name/os.arch callsites and it turns out that only a couple dozen need fixing up to use .contains() instead of .startsWith(). I've updated the webrevs to reflect this additional work. Might as well get it over now and get on to bigger and better things. :) WEBREV: http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.03 http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.04 http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.02 TESTING: JPRT hotspot and jdk builds and smoke tests on all platforms Notepad, SwingSet2, SPECjbb2005 on Mac OS X Any final comments would be appreciated. - Jim On 2/22/12 7:39 PM, Stephen Bannasch wrote: > At 6:10 PM -0500 2/22/12, James Melvin wrote: >> Updated to include latest comments... >> >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 > > line 46 still uses: os.startsWith("Mac OS X") instead of os.contains("OS X") > > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java.html From christian.thalinger at oracle.com Mon Feb 27 05:30:24 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Feb 2012 14:30:24 +0100 Subject: Default UseTLAB on Zero In-Reply-To: <4F426B0C.1020004@zafena.se> References: <4F424A15.4080507@redhat.com> <4F426B0C.1020004@zafena.se> Message-ID: <139A0918-E2F3-48BC-A385-09F5C000F819@oracle.com> On Feb 20, 2012, at 4:47 PM, Xerxes R?nby wrote: > 2012-02-20 14:26, Andrew Haley skrev: >> I noticed that, on Zero, UseTLAB defaults to false, because of this >> code: >> >> #if !defined(COMPILER1) && !defined(COMPILER2) && !defined(SHARK) >> define_pd_global(bool, BackgroundCompilation, false); >> define_pd_global(bool, UseTLAB, false); >> ... >> >> I don't understand why this is. Surely it only pointlessly slows >> down Zero. Any ideas? >> >> Thanks, >> Andrew. > > OK! > > I checked the jdk6 hotspot log http://hg.openjdk.java.net/jdk6/jdk6/hotspot/annotate/20dbc199874e/src/share/vm/runtime/globals.hpp it have been turned off since the initial duke at 0 commit. > > Shark have always used UseTLAB and ResizeTLAB true in its shark_globals_zero.hpp . > > I think this part have simply been missed to be turned ON for Zero builds. It's this push: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d2ede61b7a12 We should ask Gary why it's turned off. -- Chris > > Xerxes > > From christian.thalinger at oracle.com Mon Feb 27 05:36:07 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Feb 2012 14:36:07 +0100 Subject: CFV: New HSX Reviewer: Bengt Rutisson In-Reply-To: <4F47C17A.2080609@oracle.com> References: <4F47C17A.2080609@oracle.com> Message-ID: Vote: yes On Feb 24, 2012, at 5:57 PM, Paul Hohensee wrote: > I hereby nominate Bengt Rutisson to be an OpenJDK HSX [0] project Reviewer [1]. > > Bengt has been a Committer on the HSX project for some time and is also a > Committer on the JDK 6, 7, 7u and 8 projects. He is a key contributor in > Hotspot's GC group, working on G1 primarily, and is involved in all aspects > of GC work and planning. He's pushed 30 significant changesets, been > proxy for four more, and has been a de-facto in-depth GC reviewer for > quite awhile. The GC group relies on his expertise. Bengt is thus well- > qualified to be a Reviewer on the HSX project. > > Votes are due by 12:01AM U.S.A. Eastern time, March 9th, 2012 > (two week voting period). > > Only current HSX project Reviewers [2] are eligible to vote on this nomination. > > For Three-Vote Consensus voting instructions, see [3]. > > Regards, > > Paul Hohensee > > [0] http://openjdk.java.net/census/#hsx > [1] http://openjdk.java.net/bylaws#reviewer > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://openjdk.java.net/bylaws#three-vote-consensus > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120227/5e7c2470/attachment.html From jesper.wilhelmsson at oracle.com Mon Feb 27 07:21:54 2012 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 27 Feb 2012 16:21:54 +0100 Subject: JEP 142: Reduce Cache Contention on Specified Fields In-Reply-To: <4F45C9D0.2030902@oracle.com> References: <20120222231324.B7B20E00@eggemoggin.niobe.net> <4F45C9D0.2030902@oracle.com> Message-ID: <4F4B9F92.5020808@oracle.com> David, I have not been active on the concurrency-interest list and don't know if this is the same issue as discussed there, but it does seem likely. In the mail discussions I was involved in when creating the JEP @contended was discussed as one way among others of identifying the fields. Maybe Doug has seen both discussions and know if they are the same. /Jesper On 2012-02-23 06:08, David Holmes wrote: > On 23/02/2012 9:13 AM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/142 > > Is this the @Contended proposal which has often been mentioned on the > concurrency-interest list? > > David -------------- next part -------------- A non-text attachment was scrubbed... Name: jesper_wilhelmsson.vcf Type: text/x-vcard Size: 262 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120227/d3f52211/jesper_wilhelmsson.vcf From kelly.ohair at oracle.com Mon Feb 27 12:53:37 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 27 Feb 2012 12:53:37 -0800 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F4AFF12.5010105@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> <4F4575CD.7050708@oracle.com> <4F4AFF12.5010105@oracle.com> Message-ID: <2A8126A2-AA1B-4579-8A66-1FE5909849B0@oracle.com> On Feb 26, 2012, at 7:57 PM, James Melvin wrote: > Hi Stephen, > > The scope of the work for 7130404 is to... > > 1) Convert os.arch callsites to use 'x86_64' instead of 'amd64' > 2) Add *missing* os.name callsites for Mac OS X > > I did not originally plan to fixup *existing* os.name callsites. > However, your review has inspired me to expand the scope of 7130404 to > do just that. I walked the ~300 os.name/os.arch callsites and it turns > out that only a couple dozen need fixing up to use .contains() instead > of .startsWith(). I've updated the webrevs to reflect this additional > work. Might as well get it over now and get on to bigger and better > things. :) > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.03 Looks fine. agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java mentions "Darwin", not sure why. Also looks for "FreeBSD" "NetBSD" and "OpenBSD" But the rest of the jdk doesn't. Just seems strange to me to be looking for values of the Java property "os.name" that we don't appear to support. > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.04 Again, looks fine. Also see a "Darwin" in src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java: osname.equals("Darwin") I don't think it will ever say "Darwin" will it? Not your change, I'm just curious. And if it ever did say "Darwin", I doubt any of the other files that don't look for "Darwin" would work anyway. > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.02 Looks fine. > > TESTING: > JPRT hotspot and jdk builds and smoke tests on all platforms > Notepad, SwingSet2, SPECjbb2005 on Mac OS X > > Any final comments would be appreciated. Just my comments on Darwin, but don't consider that a hold up on the changes. -kto > > - Jim > > > > > On 2/22/12 7:39 PM, Stephen Bannasch wrote: >> At 6:10 PM -0500 2/22/12, James Melvin wrote: >>> Updated to include latest comments... >>> >>> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 >> >> line 46 still uses: os.startsWith("Mac OS X") instead of os.contains("OS X") >> >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java.html From paul.hohensee at oracle.com Mon Feb 27 13:51:31 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 27 Feb 2012 16:51:31 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F4AFF12.5010105@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> <4F4575CD.7050708@oracle.com> <4F4AFF12.5010105@oracle.com> Message-ID: <4F4BFAE3.60604@oracle.com> Looks good. Ship it. Paul On 2/26/12 10:57 PM, James Melvin wrote: > Hi Stephen, > > The scope of the work for 7130404 is to... > > 1) Convert os.arch callsites to use 'x86_64' instead of 'amd64' > 2) Add *missing* os.name callsites for Mac OS X > > I did not originally plan to fixup *existing* os.name callsites. > However, your review has inspired me to expand the scope of 7130404 to > do just that. I walked the ~300 os.name/os.arch callsites and it turns > out that only a couple dozen need fixing up to use .contains() instead > of .startsWith(). I've updated the webrevs to reflect this additional > work. Might as well get it over now and get on to bigger and better > things. :) > > WEBREV: > http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.03 > http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.04 > http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.02 > > TESTING: > JPRT hotspot and jdk builds and smoke tests on all platforms > Notepad, SwingSet2, SPECjbb2005 on Mac OS X > > Any final comments would be appreciated. > > - Jim > > > > > On 2/22/12 7:39 PM, Stephen Bannasch wrote: >> At 6:10 PM -0500 2/22/12, James Melvin wrote: >>> Updated to include latest comments... >>> >>> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 >> >> line 46 still uses: os.startsWith("Mac OS X") instead of >> os.contains("OS X") >> >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java.html >> From paul.hohensee at oracle.com Mon Feb 27 13:53:13 2012 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 27 Feb 2012 16:53:13 -0500 Subject: RFR (XXS): 7130404: [macosx] "os.arch" value should be "x86_64" for compatibility with Apple JDK6 In-Reply-To: <4F4BFAE3.60604@oracle.com> References: <4F42B4D5.2000004@oracle.com> <4F442408.3070807@oracle.com> <4F4575CD.7050708@oracle.com> <4F4AFF12.5010105@oracle.com> <4F4BFAE3.60604@oracle.com> Message-ID: <4F4BFB49.2070802@oracle.com> Changed jdk7-dev to jdk7u-dev. Paul On 2/27/12 4:51 PM, Paul Hohensee wrote: > Looks good. Ship it. > > Paul > > On 2/26/12 10:57 PM, James Melvin wrote: >> Hi Stephen, >> >> The scope of the work for 7130404 is to... >> >> 1) Convert os.arch callsites to use 'x86_64' instead of 'amd64' >> 2) Add *missing* os.name callsites for Mac OS X >> >> I did not originally plan to fixup *existing* os.name callsites. >> However, your review has inspired me to expand the scope of 7130404 to >> do just that. I walked the ~300 os.name/os.arch callsites and it turns >> out that only a couple dozen need fixing up to use .contains() instead >> of .startsWith(). I've updated the webrevs to reflect this additional >> work. Might as well get it over now and get on to bigger and better >> things. :) >> >> WEBREV: >> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.03 >> http://cr.openjdk.java.net/~jmelvin/7130404/jdk/webrev.04 >> http://cr.openjdk.java.net/~jmelvin/7130404/corba/webrev.02 >> >> TESTING: >> JPRT hotspot and jdk builds and smoke tests on all platforms >> Notepad, SwingSet2, SPECjbb2005 on Mac OS X >> >> Any final comments would be appreciated. >> >> - Jim >> >> >> >> >> On 2/22/12 7:39 PM, Stephen Bannasch wrote: >>> At 6:10 PM -0500 2/22/12, James Melvin wrote: >>>> Updated to include latest comments... >>>> >>>> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02 >>> >>> line 46 still uses: os.startsWith("Mac OS X") instead of >>> os.contains("OS X") >>> >>> http://cr.openjdk.java.net/~jmelvin/7130404/hotspot/webrev.02/agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java.html >>> From mark.reinhold at oracle.com Tue Feb 28 16:15:34 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Feb 2012 16:15:34 -0800 (PST) Subject: JEP 145: Cache Compiled Code Message-ID: <20120229001534.B3188616@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/145 - Mark From john.coomes at oracle.com Tue Feb 28 19:02:06 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 29 Feb 2012 03:02:06 +0000 Subject: hg: hsx/hsx23/hotspot: 7148663: new hotspot build - hs23-b17 Message-ID: <20120229030214.19616476F9@hg.openjdk.java.net> Changeset: cf8928e22f20 Author: amurillo Date: 2012-02-28 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/cf8928e22f20 7148663: new hotspot build - hs23-b17 Reviewed-by: jcoomes ! make/hotspot_version From frederic.parain at oracle.com Wed Feb 29 08:47:28 2012 From: frederic.parain at oracle.com (frederic.parain at oracle.com) Date: Wed, 29 Feb 2012 16:47:28 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20120229164740.1619D4771E@hg.openjdk.java.net> Changeset: 645162d94294 Author: dsamersoff Date: 2012-02-22 19:43 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/645162d94294 7110104: It should be possible to stop and start JMX Agent at runtime Summary: Added a capability to start and stop JMX Agent by jcmd Reviewed-by: acorn, mchung ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: b5ab7482dbf9 Author: dsamersoff Date: 2012-02-22 10:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b5ab7482dbf9 Merge Changeset: 7292cff45988 Author: erikj Date: 2012-02-22 09:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7292cff45988 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable Reviewed-by: dholmes, ohrstrom, ohair, jcoomes ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/sparcWorks.make ! make/defs.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/sparcWorks.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/sparcWorks.make ! make/windows/build.make ! make/windows/makefiles/compile.make ! make/windows/makefiles/defs.make Changeset: f096e1b74d85 Author: dholmes Date: 2012-02-25 01:49 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f096e1b74d85 7148126: ConstantPoolCacheEntry::print prints to wrong stream Summary: Should print to passed in stream not tty Reviewed-by: dholmes, never Contributed-by: Krystal Mok ! src/share/vm/oops/cpCacheOop.cpp Changeset: 205573af962c Author: fparain Date: 2012-02-28 07:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/205573af962c Merge From dmitriy.samersoff at oracle.com Wed Feb 29 09:01:53 2012 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Wed, 29 Feb 2012 17:01:53 +0000 Subject: hg: hsx/hsx23/hotspot: 7110104: It should be possible to stop and start JMX Agent at runtime Message-ID: <20120229170157.600964771F@hg.openjdk.java.net> Changeset: 3322dd7f0a4d Author: dsamersoff Date: 2012-02-29 15:59 +0400 URL: http://hg.openjdk.java.net/hsx/hsx23/hotspot/rev/3322dd7f0a4d 7110104: It should be possible to stop and start JMX Agent at runtime Summary: Added a capability to start and stop JMX Agent by jcmd Reviewed-by: acorn, mchung ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp From mark.reinhold at oracle.com Wed Feb 29 10:30:46 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Feb 2012 10:30:46 -0800 (PST) Subject: JEP 146: Improve Fatal Error Logs Message-ID: <20120229183046.ABDAF7FC@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/146 - Mark From mark.reinhold at oracle.com Wed Feb 29 12:57:45 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Feb 2012 12:57:45 -0800 (PST) Subject: JEP 148: Small VM Message-ID: <20120229205745.E5C307FC@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/148 - Mark From fweimer at bfk.de Wed Feb 29 23:46:05 2012 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 01 Mar 2012 07:46:05 +0000 Subject: JEP 148: Small VM In-Reply-To: <20120229205745.E5C307FC@eggemoggin.niobe.net> (mark reinhold's message of "Wed, 29 Feb 2012 12:57:45 -0800 (PST)") References: <20120229205745.E5C307FC@eggemoggin.niobe.net> Message-ID: <82y5rkdarm.fsf@mid.bfk.de> * mark reinhold: > Posted: http://openjdk.java.net/jeps/148 The JEP doesn't mention if this work will cover 64 bit VMs. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99