From dmitry.samersoff at oracle.com Sat Feb 1 01:02:29 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 01 Feb 2014 13:02:29 +0400 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EC62CD.8000300@oracle.com> References: <52EC62CD.8000300@oracle.com> Message-ID: <52ECB825.70600@oracle.com> Looks good for me! On 2014-02-01 06:58, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ > > > Summary: > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may > return different results: > - 1-st: true > - 2-nd: false > > This more generic suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the 6280037 > in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. > It is on the Test Stabilization radar (as well as the 6280037). > There are many tests intermittently failing because of this. > > The webrev for review is a one-liner work around the 6280037 for the > GetFrameCount(). > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing > bytecodes (for example, > not the current thread and not suspended), the information returned > is transient." > > So, it is Ok to call the GetFrameCount() for non-suspended target > threads. > To achieve safety, the frame count for non-suspended threads is > calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads as > well. > There is no big performance impact because it is already on a slow path. > It is still important to avoid safepointing when the target thread is > current. > > The bug 6280037 should go out of the Test Stabilization radar (remove > the svc-nightly label) > as the most of the impacted tests are covered by the 6471769. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests > > > Thanks, > Serguei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From serguei.spitsyn at oracle.com Sat Feb 1 04:24:43 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 01 Feb 2014 04:24:43 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52ECB825.70600@oracle.com> References: <52EC62CD.8000300@oracle.com> <52ECB825.70600@oracle.com> Message-ID: <52ECE78B.10809@oracle.com> Thanks, Dmitry! Serguei On 2/1/14 1:02 AM, Dmitry Samersoff wrote: > Looks good for me! > > On 2014-02-01 06:58, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >> >> >> Summary: >> >> There is a general issue in the suspend equivalent condition mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may >> return different results: >> - 1-st: true >> - 2-nd: false >> >> This more generic suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the 6280037 >> in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. >> It is on the Test Stabilization radar (as well as the 6280037). >> There are many tests intermittently failing because of this. >> >> The webrev for review is a one-liner work around the 6280037 for the >> GetFrameCount(). >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing >> bytecodes (for example, >> not the current thread and not suspended), the information returned >> is transient." >> >> So, it is Ok to call the GetFrameCount() for non-suspended target >> threads. >> To achieve safety, the frame count for non-suspended threads is >> calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads as >> well. >> There is no big performance impact because it is already on a slow path. >> It is still important to avoid safepointing when the target thread is >> current. >> >> The bug 6280037 should go out of the Test Stabilization radar (remove >> the svc-nightly label) >> as the most of the impacted tests are covered by the 6471769. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >> >> >> Thanks, >> Serguei >> > From vladimir.kozlov at oracle.com Sun Feb 2 01:09:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 02 Feb 2014 01:09:59 -0800 Subject: Escape Analysis and Stack Allocation In-Reply-To: References: <52E56F6B.4060202@infinite-source.de> <52E74954.9050608@oracle.com> Message-ID: <52EE0B67.6050303@oracle.com> Hi guys, I finally ported MLAB to jdk7 and 8. There was a problem due to new additional allocation path in runtime. It passed small set of tests and benchmarks (jvm98, jbb2000, jbb2005) but nothing is guaranteed :) http://cr.openjdk.java.net/~kvn/mlab_7/webrev/ http://cr.openjdk.java.net/~kvn/mlab_8/webrev/ I would like to hear more about Jeremy's implementation comparing to my. May be we can improve this. About changes: - It is supported only with C2, x86_64 and ParallelOldGC (did not try other GCs). - mlab is the same structure as tlab which is embedded into thread structure (the same as tlab) (thread.?pp) - mlab->top pointer is saved on compiled method entry and restored on exit (x86_64.ad, assembler_x86.cpp) - Allocation of objects which does not escape is done in mlab (macro.cpp) - Runtime allocation is called only when no space left in mlab. During runtime call new mlab is allocated and compiled frames are walked to patch saved mlab->top on stack with new top value (Thread::clear_mlab_allocation()). - some print and statistic output is added (copied from tlab) but nothing fancy. - default size is small 4Kb, you may want to play with it. All flags are defined in globals.hpp I forgot the reason for changes in escape.cpp but added comment what I think it was for. But I don't remember - you can play with it. Usual disclaimer: it is experimental work - don't expect it will run everything. Performance also is not guaranteed :) Regards, Vladimir On 1/29/14 4:45 PM, Benedict Elliott Smith wrote: > I'd definitely be interested if you could dig it out, especially if you > have the commit you forked from to compare against so I can figure out what > you changed and why. This approach seems just (or almost) as good to me, if > we can eliminate the problem you mention by, e.g. creating a special region > as Jeremy suggested. It also sounds a lot less involved to get to a > position to trial it, which is a huge plus. > > > On 28 January 2014 06:08, Vladimir Kozlov wrote: > >> I did the same experiment 4 years ago, back in jdk6 era. Called it MLAB, >> method local allocation buffer, works like thread local stack for >> non-escaping objects but was allocated in java heap as special TLAB. Got it >> worked but did not see benefits in jbb2005. GC requires no holes in heap, >> as result I had to give the buffer back to GC when young gen collection was >> needed. After GC a thread get new MLAB and starts allocation from scratch >> which nullified performance benefits. >> >> I can try to find those changes if someone interested. >> >> Regards, >> Vladimir >> >> >> On 1/27/14 9:21 PM, Jeremy Manson wrote: >> >>> I tried implementing direct stack allocation in Hotspot a couple of years >>> ago. It was a pain to try to allocate anything outside the heap - there >>> are a lot of checks to make sure that your objects live on the heap. >>> >>> I ended up creating TLAB-like regions in the heap that could hold objects >>> allocated in a stack-like way. It was a lot easier that way, and seemed >>> to >>> give the kinds of performance benefits you would expect. >>> >>> I never got around to trying to wire it up to Hotspot's escape analysis, >>> but it was a fairly obvious next step. >>> >>> Jeremy >>> >>> >>> On Sun, Jan 26, 2014 at 12:26 PM, Aaron Grunthal < >>> aaron.grunthal at infinite-source.de> wrote: >>> >>> There also is an issue with merge points [1] which prevents objects in >>>> loops with an accumulator (e.g. reduce operations on streams) to >>>> stack-allocate the intermediate values. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-6853701 >>>> >>>> - Aaron >>>> >>>> >>>> On 26.01.2014 07:04, Benedict Elliott Smith wrote: >>>> >>>> Hi, >>>>> >>>>> I was digging into some (to me) unexpected behaviour of escape analysis, >>>>> namely that some references that clearly weren't escaping, and easily >>>>> determined to be so, were not being stack allocated. >>>>> >>>>> So, after some digging through the hotspot code, I discovered some >>>>> things >>>>> that were probably obvious to everyone on this list, but also some >>>>> things >>>>> I'm still a little perplexed about. I was hoping somebody could >>>>> enlighten >>>>> me about the latter. >>>>> >>>>> 1) I cannot see a reason why stores to a primitive array, for instance, >>>>> should cause the argument to escape in bcEscapeAnalyser.cpp >>>>> *iterate_one_block()*; most interestingly, a store to an object array >>>>> does >>>>> not result in this, which seems incongruous; >>>>> >>>>> 2) An object array store *does* however result in *set_global_escape()* >>>>> for >>>>> the value being stored, which makes sense, except that this should only >>>>> be >>>>> *set_method_escape()*, as per the paper, in the case where the target >>>>> array >>>>> is one of the method arguments. This seems to be missing, here and for >>>>> *putfield*. >>>>> >>>>> Some other weird ones are *arraylength*, *getfield*, *ifnonnull*, etc. >>>>> The >>>>> fact that these all result in *set_method_escape()*, and that >>>>> *putfield*and >>>>> *aastore* don't optimise *set_global_escape()* to >>>>> *set_method_escape()*where possible, seem to point to the conclusion >>>>> that *_is_arg_stack >>>>> / set_method_escape()* actually encode only *!is_scalar_replaceable*. Is >>>>> this the case? If so, why the confusing name?* >>>>> >>>>> >>>>> Which leads to a much trickier but more interesting question, which is: >>>>> what are the barriers to performing actual stack allocation of full >>>>> objects, instead of scalar replacement? It is something I would be keen >>>>> to >>>>> investigate, but given my lack of familiarity with the codebase, it >>>>> would >>>>> be immensely helpful to hear what the major difficulties / showstoppers >>>>> might be before trying to attack it. >>>>> >>>>> Thanks in advance, >>>>> >>>>> Benedict >>>>> >>>>> >>>>> *I do note that in escape.cpp *ArgEscape* is defined and is explicitly >>>>> overloaded to include some of the characteristics of >>>>> *is_scalar_replaceable*. >>>>> However the *is_arg_stack()* method is commented with "The given >>>>> argument >>>>> escapes the callee, but does not become globally reachable." which seems >>>>> to >>>>> correspond to *ArgEscape* in the paper, but only *invoke()* seems to >>>>> follow >>>>> the spec, when invoking a method that cannot be analysed, and this would >>>>> also be true for *!is_scalar_replaceable.* >>>>> >>>>> >>>>> >>>> From kevin.walls at oracle.com Mon Feb 3 02:08:36 2014 From: kevin.walls at oracle.com (Kevin Walls) Date: Mon, 03 Feb 2014 10:08:36 +0000 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52EBD3F7.2010307@oracle.com> References: <52EBB103.5090907@oracle.com> <52EBD3F7.2010307@oracle.com> Message-ID: <52EF6AA4.9000403@oracle.com> Hi Vladimir - Regarding different local library versions impacting e.g. libproc's ability to open a core: I would hope you can get a good result from kjdb [1] which gives you a pure Java method of opening that core. Gives you a debugger within a debugger if you type "sa clhsdb". Ping me directly if you find something it can't open! Regards Kevin [1] https://java.net/projects/kjdb On 31/01/14 16:48, Vladimir Kozlov wrote: > It is become more useful for compiler group after ReplayCompilation > changes were added into jdk8 to replay crash during JIT compilation. > SA helps extract replay info and application classes from core files. > > Most annoying thing is when you get a core file from customer and you > can't open it with SA because on your system thread and/or other sys > libs is slightly different (other version). > > An other thing is how SA knows about Hotspot structures. Very often we > change our internal Hotspot classes and forgot to update vmStructures. > It would be nice to automate it or at least catch the miss during > VM/SA build. > > Used it on linux, solaris-x86 and -sparc. Never on windows. > > Debuggers: dbx on solaris, gdb on others. > > Thanks, > Vladimir > > On 1/31/14 6:19 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> I would like to start a discussion about future of hotspot debugger, >> known as serviceability agent or SA. >> >> How you typically use it? What do you expect from it? What is missed? >> >> Please, share your stories and wishes. >> >> And please, fill the small quiz: >> >> 1. How often do you use SA? >> >> 2. On what platform do you use SA? >> >> 3. Do you use it to analyze life processes or coredumps? >> >> 5. What other debuggers do you use to debug hotspot issues >> >> -Dmitry >> From staffan.larsen at oracle.com Mon Feb 3 03:57:27 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 3 Feb 2014 12:57:27 +0100 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EC62CD.8000300@oracle.com> References: <52EC62CD.8000300@oracle.com> Message-ID: <3E8D21DD-BD7A-4AEF-9C02-C175AEB40738@oracle.com> Looks good! Thanks, /Staffan On 1 feb 2014, at 03:58, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ > > Summary: > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: > - 1-st: true > - 2-nd: false > > This more generic suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the 6280037 > in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. > It is on the Test Stabilization radar (as well as the 6280037). > There are many tests intermittently failing because of this. > > The webrev for review is a one-liner work around the 6280037 for the GetFrameCount(). > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing bytecodes (for example, > not the current thread and not suspended), the information returned is transient." > > So, it is Ok to call the GetFrameCount() for non-suspended target threads. > To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads as well. > There is no big performance impact because it is already on a slow path. > It is still important to avoid safepointing when the target thread is current. > > The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) > as the most of the impacted tests are covered by the 6471769. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests > > > Thanks, > Serguei > From david.holmes at oracle.com Mon Feb 3 04:16:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Feb 2014 22:16:39 +1000 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EC62CD.8000300@oracle.com> References: <52EC62CD.8000300@oracle.com> Message-ID: <52EF88A7.3090506@oracle.com> Hi Serguei, On 1/02/2014 12:58 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ > > > Summary: > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may > return different results: > - 1-st: true > - 2-nd: false > > This more generic suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the 6280037 > in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. > It is on the Test Stabilization radar (as well as the 6280037). > There are many tests intermittently failing because of this. > > The webrev for review is a one-liner work around the 6280037 for the > GetFrameCount(). > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing > bytecodes (for example, > not the current thread and not suspended), the information > returned is transient." > > So, it is Ok to call the GetFrameCount() for non-suspended target > threads. > To achieve safety, the frame count for non-suspended threads is > calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads as > well. > There is no big performance impact because it is already on a slow path. > It is still important to avoid safepointing when the target thread is > current. This sounds completely reasonable - Reviewed. I can't check at the moment whether VM_GetFrameCount properly checks for a live target thread? David > The bug 6280037 should go out of the Test Stabilization radar (remove > the svc-nightly label) > as the most of the impacted tests are covered by the 6471769. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests > > > Thanks, > Serguei > From staffan.larsen at oracle.com Mon Feb 3 06:26:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 3 Feb 2014 15:26:14 +0100 Subject: RFR(S): JDK-8033126 : Can't call default methods from JNI In-Reply-To: References: Message-ID: <31D56917-1799-4587-87A4-84B2E92D3988@oracle.com> Karen, I have pushed this change without the assertion. Given the problems with creating test cases with JNI code, I plan to file a follow-up bug for the testcase. Thanks, /Staffan On 29 jan 2014, at 15:28, Karen Kinnear wrote: > Staffan, > > Fix approach looks good. Can you please remove the assertion - I don't think that will always > be true. > > Can you please submit an automated testcase with this? > > thanks, > Karen > > On Jan 29, 2014, at 8:17 AM, Staffan Larsen wrote: > >> This is a more formal review request for the patch proposed in [0] >> >> webrev: http://cr.openjdk.java.net/~sla/8033126/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8033126 >> >> The bug report has a reproducer/testcase that I have used to verify the fix. I have also run the vm/jni tests in the JCK. >> >> Thanks, >> /Staffan >> >> [0] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012325.html > From daniel.daugherty at oracle.com Mon Feb 3 07:51:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Feb 2014 08:51:18 -0700 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EC62CD.8000300@oracle.com> References: <52EC62CD.8000300@oracle.com> Message-ID: <52EFBAF6.8000404@oracle.com> On 1/31/14 7:58 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ > src/share/vm/prims/jvmtiEnv.cpp Thumbs up on the code change. I've never been a fan of the: if (is_thread_fully_suspended(...)) do-something-direct else do-something-via-a-safepoint model. We don't have any mechanism in the VM to keep the is_thread_fully_suspended() constraint true over the execution time of the "do-something-direct" operation so we've always been exposed to races. Also, I think this model is used for several other JVM/TI calls so you might want to visit those also with an eye on safety. For this specific change, I think the comment would be better as: // It is only safe to perform the direct operation on the current // thread. All other usage needs to use a vm-op for safety. In particular, I don't agree with this part of the comment: // Performance-wise the only important case is when current thread is // the target thread. I'm not sure how you can state that performance on the current thread is the only important case, but maybe I don't understand what you're really trying to say here. Now for the more general question with respect to this bug: 6471769 I've having trouble connecting this change (which I like) to this particular bug report. The crash in the bug's description looks like this: # Internal Error (/net/prt-solamd64-q1-2/PrtBuildDir/workspace/src/share/vm/prims/jvmtiThreadState.cpp, 273), pid=9561, tid=2 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (20060914135846.dcubed.service_hs_b02_merge.2-debug compiled mode) # # Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth out of sync") V [libjvm.so+0x1217206];; void VMError::report_and_die()+0x606 V [libjvm.so+0x667841];; void report_assertion_failure(const char*,int,const char*)+0x61 V [libjvm.so+0xca9557];; int JvmtiThreadState::cur_stack_depth()+0x6e7 V [libjvm.so+0xc1caaa];; void JvmtiExport::post_method_exit(JavaThread*,methodOop,frame)+0x21ba V [libjvm.so+0x8385de];; void InterpreterRuntime::post_method_exit(JavaThread*)+0x21e j java.io.ObjectInputStream$BlockDataInputStream.getBlockDataMode()Z+4 In the above crash, the current thread is trying to post a JVMTI_EVENT_METHOD_EXIT and during the event posting code, it calls cur_stack_depth() which fails an assert because the cached stack depth doesn't match the current queried value: 282 int JvmtiThreadState::cur_stack_depth() { 283 uint32_t debug_bits = 0; 284 guarantee(JavaThread::current() == get_thread() || 285 JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits ), 286 "must be current thread or suspended"); 287 288 if (!is_interp_only_mode() || _cur_stack_depth == UNKNOWN_STACK_DEPTH) { 289 _cur_stack_depth = count_frames(); 290 } else { 291 // heavy weight assert 292 assert(_cur_stack_depth == count_frames(), 293 "cur_stack_depth out of sync"); 294 } 295 return _cur_stack_depth; 296 } This is not an unsafe query from one thread to another target thread so I don't see how the proposed change will address this failure mode. In particular, the assertion is troubling because it tells me that the cached stack depth for the current thread is either wrong or has been corrupted. To reiterate: - I like the code change! - I would like to see the comment tweaked a bit You should consider going forward with this change using a different bug ID, perhaps something like: JDK-NNNNNNN improve safety of JVM/TI GetFrameCount() Dan > > Summary: > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() > may return different results: > - 1-st: true > - 2-nd: false > > This more generic suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the > 6280037 > in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. > It is on the Test Stabilization radar (as well as the 6280037). > There are many tests intermittently failing because of this. > > The webrev for review is a one-liner work around the 6280037 for the > GetFrameCount(). > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing > bytecodes (for example, > not the current thread and not suspended), the information > returned is transient." > > So, it is Ok to call the GetFrameCount() for non-suspended target > threads. > To achieve safety, the frame count for non-suspended threads is > calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads > as well. > There is no big performance impact because it is already on a slow > path. > It is still important to avoid safepointing when the target thread > is current. > > The bug 6280037 should go out of the Test Stabilization radar > (remove the svc-nightly label) > as the most of the impacted tests are covered by the 6471769. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests > > > Thanks, > Serguei > From mikael.gerdin at oracle.com Mon Feb 3 07:58:08 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 03 Feb 2014 16:58:08 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52EBB103.5090907@oracle.com> References: <52EBB103.5090907@oracle.com> Message-ID: <2648336.oKTbdjJpKm@mgerdin03> On Friday 31 January 2014 18.19.47 Dmitry Samersoff wrote: > Hi Everyone, > > I would like to start a discussion about future of hotspot debugger, > known as serviceability agent or SA. > > How you typically use it? What do you expect from it? What is missed? I use it to inspect core files from crashes that are hard to reproduce. A few bits of functionality I use are: * the inspector ** primarily for java objects but sometimes for C++ objects as well. * class browser, both to look at bytecode disassembly and dissasembly of compiled code. The disassembler displays oopmap data which is useful for debugging GC/compiler interaction bugs. * jstack stack walking * the (slightly broken) thread stack visualizer > > Please, share your stories and wishes. > > And please, fill the small quiz: > > 1. How often do you use SA? Weekly. > > 2. On what platform do you use SA? Linux, Windows, Solaris > > 3. Do you use it to analyze life processes or coredumps? Primarily for core files, for live processes it's usually easy enough to call functions in the debug vm to print out objects and such. It's when bugs are hard to reproduce that the SA shines. > > 5. What other debuggers do you use to debug hotspot issues gdb, dbx, windbg - depending on platform. /Mikael > > -Dmitry From serguei.spitsyn at oracle.com Mon Feb 3 10:30:51 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 10:30:51 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <3E8D21DD-BD7A-4AEF-9C02-C175AEB40738@oracle.com> References: <52EC62CD.8000300@oracle.com> <3E8D21DD-BD7A-4AEF-9C02-C175AEB40738@oracle.com> Message-ID: <52EFE05B.1070504@oracle.com> Thanks, Staffan! Serguei On 2/3/14 3:57 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 1 feb 2014, at 03:58, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >> >> Summary: >> >> There is a general issue in the suspend equivalent condition mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: >> - 1-st: true >> - 2-nd: false >> >> This more generic suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the 6280037 >> in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. >> It is on the Test Stabilization radar (as well as the 6280037). >> There are many tests intermittently failing because of this. >> >> The webrev for review is a one-liner work around the 6280037 for the GetFrameCount(). >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing bytecodes (for example, >> not the current thread and not suspended), the information returned is transient." >> >> So, it is Ok to call the GetFrameCount() for non-suspended target threads. >> To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads as well. >> There is no big performance impact because it is already on a slow path. >> It is still important to avoid safepointing when the target thread is current. >> >> The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) >> as the most of the impacted tests are covered by the 6471769. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >> >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Mon Feb 3 11:12:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 11:12:37 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EF88A7.3090506@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EF88A7.3090506@oracle.com> Message-ID: <52EFEA25.8080905@oracle.com> On 2/3/14 4:16 AM, David Holmes wrote: > Hi Serguei, > > On 1/02/2014 12:58 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >> >> >> >> Summary: >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may >> return different results: >> - 1-st: true >> - 2-nd: false >> >> This more generic suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the >> 6280037 >> in the JVMTI GetFrameCount() that has a big impact on the SQE >> nightly. >> It is on the Test Stabilization radar (as well as the 6280037). >> There are many tests intermittently failing because of this. >> >> The webrev for review is a one-liner work around the 6280037 for the >> GetFrameCount(). >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing >> bytecodes (for example, >> not the current thread and not suspended), the information >> returned is transient." >> >> So, it is Ok to call the GetFrameCount() for non-suspended target >> threads. >> To achieve safety, the frame count for non-suspended threads is >> calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads as >> well. >> There is no big performance impact because it is already on a slow >> path. >> It is still important to avoid safepointing when the target thread is >> current. > > This sounds completely reasonable - Reviewed. > > I can't check at the moment whether VM_GetFrameCount properly checks > for a live target thread? David, thank you for the review! It looks like the check is missed. Please, give me some time to make sure what is needed here. Thanks! Serguei > > David > >> The bug 6280037 should go out of the Test Stabilization radar (remove >> the svc-nightly label) >> as the most of the impacted tests are covered by the 6471769. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >> >> >> Thanks, >> Serguei >> From neale at sinenomine.net Mon Feb 3 11:50:59 2014 From: neale at sinenomine.net (Neale Ferguson) Date: Mon, 3 Feb 2014 19:50:59 +0000 Subject: Error building hotspot with shark/zero Message-ID: Hi, I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' line 72 looks like: llvm::Constant* get_external(const char* name, const llvm::FunctionType* sig) { return module()->getOrInsertFunction(name, sig); } Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. Neale From serguei.spitsyn at oracle.com Mon Feb 3 12:13:02 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 12:13:02 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EFBAF6.8000404@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EFBAF6.8000404@oracle.com> Message-ID: <52EFF84E.1050800@oracle.com> Dan, Thank you for reviewing! Some comments are below. On 2/3/14 7:51 AM, Daniel D. Daugherty wrote: > On 1/31/14 7:58 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >> > > src/share/vm/prims/jvmtiEnv.cpp > Thumbs up on the code change. > > I've never been a fan of the: > > if (is_thread_fully_suspended(...)) > do-something-direct > else > do-something-via-a-safepoint > > model. We don't have any mechanism in the VM to keep the > is_thread_fully_suspended() constraint true over the > execution time of the "do-something-direct" operation so > we've always been exposed to races. Thank you for this confirmation. So that, we are in sync here. > Also, I think this > model is used for several other JVM/TI calls so you might > want to visit those also with an eye on safety. Yes, I'm looking to isolate and double check other places like this in the code. Another piece of work is to isolate other bugs on this topic. > > For this specific change, I think the comment would be > better as: > > // It is only safe to perform the direct operation on the current > // thread. All other usage needs to use a vm-op for safety. It is taken, thanks! > In particular, I don't agree with this part of the comment: > > // Performance-wise the only important case is when current thread is > // the target thread. > > I'm not sure how you can state that performance on the current thread > is the only important case, but maybe I don't understand what you're > really trying to say here. I agree, the comment is not clear. Probably, the comment had to say: "the only case where we can keep performance without loosing safety is the target thread is current ...". In fact, collecting data at a safepoint is the only way to make it safe. If the target thread is not current then: - a) thread has been suspended: already slow path, so that performance is not that critical - b) thread has not been suspended: the information we provide is transient, safepoint is the only way to get it safe (is is correct?) > > Now for the more general question with respect to this bug: 6471769 > I've having trouble connecting this change (which I like) to this > particular bug report. > > The crash in the bug's description looks like this: > > # Internal Error > (/net/prt-solamd64-q1-2/PrtBuildDir/workspace/src/share/vm/prims/jvmtiThreadState.cpp, > 273), pid=9561, tid=2 > # > # Java VM: Java HotSpot(TM) 64-Bit Server VM > (20060914135846.dcubed.service_hs_b02_merge.2-debug compiled mode) > # > # Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth > out of sync") > > V [libjvm.so+0x1217206];; void VMError::report_and_die()+0x606 > V [libjvm.so+0x667841];; void report_assertion_failure(const > char*,int,const char*)+0x61 > V [libjvm.so+0xca9557];; int JvmtiThreadState::cur_stack_depth()+0x6e7 > V [libjvm.so+0xc1caaa];; void > JvmtiExport::post_method_exit(JavaThread*,methodOop,frame)+0x21ba > V [libjvm.so+0x8385de];; void > InterpreterRuntime::post_method_exit(JavaThread*)+0x21e > j java.io.ObjectInputStream$BlockDataInputStream.getBlockDataMode()Z+4 > > In the above crash, the current thread is trying to post a > JVMTI_EVENT_METHOD_EXIT and during the event posting code, it > calls cur_stack_depth() which fails an assert because the > cached stack depth doesn't match the current queried value: > > 282 int JvmtiThreadState::cur_stack_depth() { > 283 uint32_t debug_bits = 0; > 284 guarantee(JavaThread::current() == get_thread() || > 285 JvmtiEnv::is_thread_fully_suspended(get_thread(), false, > &debug_bits > ), > 286 "must be current thread or suspended"); > 287 > 288 if (!is_interp_only_mode() || _cur_stack_depth == > UNKNOWN_STACK_DEPTH) > { > 289 _cur_stack_depth = count_frames(); > 290 } else { > 291 // heavy weight assert > 292 assert(_cur_stack_depth == count_frames(), > 293 "cur_stack_depth out of sync"); > 294 } > 295 return _cur_stack_depth; > 296 } > > > This is not an unsafe query from one thread to another target thread > so I don't see how the proposed change will address this failure mode. > In particular, the assertion is troubling because it tells me that > the cached stack depth for the current thread is either wrong or has > been corrupted. The above are consequences of unsafe operations we are doing. Current thread should not calculate frame count of target thread (if different) other than at a safepoint. We assume the thread is suspended but, in fact, it was not. So that we lost safety here and all manifestation we observe are the consequences. This bug covers the frames miscount issue. In the fastdebug mode we may get the assert as in this bug report: https://bugs.openjdk.java.net/browse/JDK-8032223 There is another potential race that I forgot to check and fix but David pointed out. I will try to cover it in the next version of webrev. It is still possible there can be other issues here (as you say). But it is hard to make sure it is the case because it is extremely hard to reproduce (you know it!). I'd suggest to resolve it step-by-step: - fix the known safety issues - watch the nightly if anything else is left, file and fix new bugs > > To reiterate: > > - I like the code change! > - I would like to see the comment tweaked a bit > > You should consider going forward with this change using a different > bug ID, perhaps something like: > > JDK-NNNNNNN improve safety of JVM/TI GetFrameCount() There is already bug on this topic (and there are even more dups): https://bugs.openjdk.java.net/browse/JDK-8032223 But I still believe, the issue is the same ... Thanks! Serguei > > Dan > > > >> >> Summary: >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >> may return different results: >> - 1-st: true >> - 2-nd: false >> >> This more generic suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the >> 6280037 >> in the JVMTI GetFrameCount() that has a big impact on the SQE nightly. >> It is on the Test Stabilization radar (as well as the 6280037). >> There are many tests intermittently failing because of this. >> >> The webrev for review is a one-liner work around the 6280037 for >> the GetFrameCount(). >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing >> bytecodes (for example, >> not the current thread and not suspended), the information >> returned is transient." >> >> So, it is Ok to call the GetFrameCount() for non-suspended target >> threads. >> To achieve safety, the frame count for non-suspended threads is >> calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads >> as well. >> There is no big performance impact because it is already on a slow >> path. >> It is still important to avoid safepointing when the target thread >> is current. >> >> The bug 6280037 should go out of the Test Stabilization radar >> (remove the svc-nightly label) >> as the most of the impacted tests are covered by the 6471769. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Mon Feb 3 14:17:13 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 14:17:13 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced Message-ID: <52F01569.3070201@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8025841 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 Summary: The fix contributed by Oleg Mazurov to improve profiling data quality. It moves the "vtable stub" dynamic code notification to the right place. I've already reviewed the fix, and it looks good to me. Bug report description: "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled when a new chunk of memory for subsequent vtable and itable stubs is allocated. That chunk is uninitialized (contains zeros or garbage) although due to the fact that the actual event delivery is deferred, at least one vtable comes out right. This event should describe an individual vtable/itable stub (base address and size) and only after it's been created (memory is actually populated with code). Where VM diagnostic messages about vtable/itable stubs are issued upon -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI events as well. Getting vtables/itables right is important in the context of performance analysis as that dynamically generated code may accumulate quite noticeable CPU time (especially itabes), sometimes larger than the actual Java methods called." Testing: Oleg tested it in the Oracle Studio Performance Analyzer environment. nsk.jvmti, nsk.jdi, nsk.jdwp, In progress: Jtreg com/sun/jdi, java/lang/instrument Thanks, Serguei From daniel.daugherty at oracle.com Mon Feb 3 14:38:27 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Feb 2014 15:38:27 -0700 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EFEA25.8080905@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EF88A7.3090506@oracle.com> <52EFEA25.8080905@oracle.com> Message-ID: <52F01A63.7080206@oracle.com> On 2/3/14 12:12 PM, serguei.spitsyn at oracle.com wrote: > On 2/3/14 4:16 AM, David Holmes wrote: >> Hi Serguei, >> >> On 1/02/2014 12:58 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >>> >>> >>> >>> Summary: >>> >>> There is a general issue in the suspend equivalent condition >>> mechanism: >>> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >>> may >>> return different results: >>> - 1-st: true >>> - 2-nd: false >>> >>> This more generic suspend equivalent issue is covered by another >>> bug: >>> https://bugs.openjdk.java.net/browse/JDK-6280037 >>> >>> The bug to fix in this review is a specific manifestation of the >>> 6280037 >>> in the JVMTI GetFrameCount() that has a big impact on the SQE >>> nightly. >>> It is on the Test Stabilization radar (as well as the 6280037). >>> There are many tests intermittently failing because of this. >>> >>> The webrev for review is a one-liner work around the 6280037 for the >>> GetFrameCount(). >>> >>> The JVMTI GetFrameCount() spec tells: >>> "If this function is called for a thread actively executing >>> bytecodes (for example, >>> not the current thread and not suspended), the information >>> returned is transient." >>> >>> So, it is Ok to call the GetFrameCount() for non-suspended target >>> threads. >>> To achieve safety, the frame count for non-suspended threads is >>> calculated at a safepoint. >>> It should be Ok and more safe to do the same for suspended >>> threads as >>> well. >>> There is no big performance impact because it is already on a >>> slow path. >>> It is still important to avoid safepointing when the target >>> thread is >>> current. >> >> This sounds completely reasonable - Reviewed. >> >> I can't check at the moment whether VM_GetFrameCount properly checks >> for a live target thread? > > David, thank you for the review! > It looks like the check is missed. > Please, give me some time to make sure what is needed here. Check out the work done via this changeset: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1d7040a1183 Sergey did the push via: JDK-8022836 JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR and GET_OWNED_MONITOR https://bugs.openjdk.java.net/browse/JDK-8022836 but the real commentary about the bug is in this one: JDK-7154963 crash in JvmtiEnvBase::get_current_contended_monitor() https://bugs.openjdk.java.net/browse/JDK-7154963 I think above code is what you want... Dan > > Thanks! > Serguei > >> >> David >> >>> The bug 6280037 should go out of the Test Stabilization radar >>> (remove >>> the svc-nightly label) >>> as the most of the impacted tests are covered by the 6471769. >>> >>> >>> Testing: >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >>> >>> >>> Thanks, >>> Serguei >>> > From daniel.daugherty at oracle.com Mon Feb 3 14:54:06 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 03 Feb 2014 15:54:06 -0700 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52EFF84E.1050800@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EFBAF6.8000404@oracle.com> <52EFF84E.1050800@oracle.com> Message-ID: <52F01E0D.8010304@oracle.com> On 2/3/14 1:13 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > Thank you for reviewing! > Some comments are below. > > On 2/3/14 7:51 AM, Daniel D. Daugherty wrote: >> On 1/31/14 7:58 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >>> >> >> src/share/vm/prims/jvmtiEnv.cpp >> Thumbs up on the code change. >> >> I've never been a fan of the: >> >> if (is_thread_fully_suspended(...)) >> do-something-direct >> else >> do-something-via-a-safepoint >> >> model. We don't have any mechanism in the VM to keep the >> is_thread_fully_suspended() constraint true over the >> execution time of the "do-something-direct" operation so >> we've always been exposed to races. > > Thank you for this confirmation. > So that, we are in sync here. > > >> Also, I think this >> model is used for several other JVM/TI calls so you might >> want to visit those also with an eye on safety. > > Yes, I'm looking to isolate and double check other places like this in > the code. > Another piece of work is to isolate other bugs on this topic. > > >> >> For this specific change, I think the comment would be >> better as: >> >> // It is only safe to perform the direct operation on the current >> // thread. All other usage needs to use a vm-op for safety. > > It is taken, thanks! > >> In particular, I don't agree with this part of the comment: >> >> // Performance-wise the only important case is when current >> thread is >> // the target thread. >> >> I'm not sure how you can state that performance on the current >> thread >> is the only important case, but maybe I don't understand what you're >> really trying to say here. > > I agree, the comment is not clear. > Probably, the comment had to say: "the only case where we can keep > performance > without loosing safety is the target thread is current ...". > In fact, collecting data at a safepoint is the only way to make it safe. > If the target thread is not current then: > - a) thread has been suspended: already slow path, so that > performance is not that critical > - b) thread has not been suspended: the information we provide is > transient, > safepoint is the only way to get it safe (is is correct?) Yes, the only safe way to get info for another thread is via a safepoint operation. > >> >> Now for the more general question with respect to this bug: 6471769 >> I've having trouble connecting this change (which I like) to this >> particular bug report. >> >> The crash in the bug's description looks like this: >> >> # Internal Error >> (/net/prt-solamd64-q1-2/PrtBuildDir/workspace/src/share/vm/prims/jvmtiThreadState.cpp, >> 273), pid=9561, tid=2 >> # >> # Java VM: Java HotSpot(TM) 64-Bit Server VM >> (20060914135846.dcubed.service_hs_b02_merge.2-debug compiled mode) >> # >> # Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth >> out of sync") >> >> V [libjvm.so+0x1217206];; void VMError::report_and_die()+0x606 >> V [libjvm.so+0x667841];; void report_assertion_failure(const >> char*,int,const char*)+0x61 >> V [libjvm.so+0xca9557];; int JvmtiThreadState::cur_stack_depth()+0x6e7 >> V [libjvm.so+0xc1caaa];; void >> JvmtiExport::post_method_exit(JavaThread*,methodOop,frame)+0x21ba >> V [libjvm.so+0x8385de];; void >> InterpreterRuntime::post_method_exit(JavaThread*)+0x21e >> j java.io.ObjectInputStream$BlockDataInputStream.getBlockDataMode()Z+4 >> >> In the above crash, the current thread is trying to post a >> JVMTI_EVENT_METHOD_EXIT and during the event posting code, it >> calls cur_stack_depth() which fails an assert because the >> cached stack depth doesn't match the current queried value: >> >> 282 int JvmtiThreadState::cur_stack_depth() { >> 283 uint32_t debug_bits = 0; >> 284 guarantee(JavaThread::current() == get_thread() || >> 285 JvmtiEnv::is_thread_fully_suspended(get_thread(), false, >> &debug_bits >> ), >> 286 "must be current thread or suspended"); >> 287 >> 288 if (!is_interp_only_mode() || _cur_stack_depth == >> UNKNOWN_STACK_DEPTH) >> { >> 289 _cur_stack_depth = count_frames(); >> 290 } else { >> 291 // heavy weight assert >> 292 assert(_cur_stack_depth == count_frames(), >> 293 "cur_stack_depth out of sync"); >> 294 } >> 295 return _cur_stack_depth; >> 296 } >> >> >> This is not an unsafe query from one thread to another target thread >> so I don't see how the proposed change will address this failure mode. >> In particular, the assertion is troubling because it tells me that >> the cached stack depth for the current thread is either wrong or has >> been corrupted. > > The above are consequences of unsafe operations we are doing. > Current thread should not calculate frame count of target thread (if > different) other than at a safepoint. > We assume the thread is suspended but, in fact, it was not. > So that we lost safety here and all manifestation we observe are the > consequences. For at least the stack trace shown in the description of 6471769, it is not an unsafe case because the thread is operating on itself. All I'm saying here is that 6471769 is not the right bug to use for this fix... > This bug covers the frames miscount issue. > In the fastdebug mode we may get the assert as in this bug report: > https://bugs.openjdk.java.net/browse/JDK-8032223 This bug: JDK-8032223 seems to be a perfect match for code that you are proposing the change in your current webrev. You have a thread ("JDWP Transport Listener: dt_socket") that is trying to query the frame count on another thread... That target JavaThread met the is_thread_fully_suspended() criteria when execution went down the direct path, but later the target stopped meeting that criteria... And boom... > There is another potential race that I forgot to check and fix but > David pointed out. > I will try to cover it in the next version of webrev. See the separate reply that I sent on that part... > > It is still possible there can be other issues here (as you say). > But it is hard to make sure it is the case because it is extremely > hard to reproduce (you know it!). > I'd suggest to resolve it step-by-step: > - fix the known safety issues > - watch the nightly if anything else is left, file and fix new bugs This sounds like a good plan. > >> >> To reiterate: >> >> - I like the code change! >> - I would like to see the comment tweaked a bit >> >> You should consider going forward with this change using a different >> bug ID, perhaps something like: >> >> JDK-NNNNNNN improve safety of JVM/TI GetFrameCount() > > There is already bug on this topic (and there are even more dups): > https://bugs.openjdk.java.net/browse/JDK-8032223 > > But I still believe, the issue is the same ... I don't think the issues in JDK-6471769 and JDK-8032223 are the same; well not the same for the crash in the description of JDK-6471769. I didn't look closely at the other crashes... Dan > > > Thanks! > Serguei > >> >> Dan >> >> >> >>> >>> Summary: >>> >>> There is a general issue in the suspend equivalent condition >>> mechanism: >>> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >>> may return different results: >>> - 1-st: true >>> - 2-nd: false >>> >>> This more generic suspend equivalent issue is covered by another bug: >>> https://bugs.openjdk.java.net/browse/JDK-6280037 >>> >>> The bug to fix in this review is a specific manifestation of the >>> 6280037 >>> in the JVMTI GetFrameCount() that has a big impact on the SQE >>> nightly. >>> It is on the Test Stabilization radar (as well as the 6280037). >>> There are many tests intermittently failing because of this. >>> >>> The webrev for review is a one-liner work around the 6280037 for >>> the GetFrameCount(). >>> >>> The JVMTI GetFrameCount() spec tells: >>> "If this function is called for a thread actively executing >>> bytecodes (for example, >>> not the current thread and not suspended), the information >>> returned is transient." >>> >>> So, it is Ok to call the GetFrameCount() for non-suspended target >>> threads. >>> To achieve safety, the frame count for non-suspended threads is >>> calculated at a safepoint. >>> It should be Ok and more safe to do the same for suspended threads >>> as well. >>> There is no big performance impact because it is already on a slow >>> path. >>> It is still important to avoid safepointing when the target thread >>> is current. >>> >>> The bug 6280037 should go out of the Test Stabilization radar >>> (remove the svc-nightly label) >>> as the most of the impacted tests are covered by the 6471769. >>> >>> >>> Testing: >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Mon Feb 3 14:54:14 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 14:54:14 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52F01A63.7080206@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EF88A7.3090506@oracle.com> <52EFEA25.8080905@oracle.com> <52F01A63.7080206@oracle.com> Message-ID: <52F01E16.7050200@oracle.com> On 2/3/14 2:38 PM, Daniel D. Daugherty wrote: > > On 2/3/14 12:12 PM, serguei.spitsyn at oracle.com wrote: >> On 2/3/14 4:16 AM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 1/02/2014 12:58 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> There is a general issue in the suspend equivalent condition >>>> mechanism: >>>> Two subsequent calls to the >>>> JvmtiEnv::is_thread_fully_suspended() may >>>> return different results: >>>> - 1-st: true >>>> - 2-nd: false >>>> >>>> This more generic suspend equivalent issue is covered by another >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-6280037 >>>> >>>> The bug to fix in this review is a specific manifestation of the >>>> 6280037 >>>> in the JVMTI GetFrameCount() that has a big impact on the SQE >>>> nightly. >>>> It is on the Test Stabilization radar (as well as the 6280037). >>>> There are many tests intermittently failing because of this. >>>> >>>> The webrev for review is a one-liner work around the 6280037 for >>>> the >>>> GetFrameCount(). >>>> >>>> The JVMTI GetFrameCount() spec tells: >>>> "If this function is called for a thread actively executing >>>> bytecodes (for example, >>>> not the current thread and not suspended), the information >>>> returned is transient." >>>> >>>> So, it is Ok to call the GetFrameCount() for non-suspended target >>>> threads. >>>> To achieve safety, the frame count for non-suspended threads is >>>> calculated at a safepoint. >>>> It should be Ok and more safe to do the same for suspended >>>> threads as >>>> well. >>>> There is no big performance impact because it is already on a >>>> slow path. >>>> It is still important to avoid safepointing when the target >>>> thread is >>>> current. >>> >>> This sounds completely reasonable - Reviewed. >>> >>> I can't check at the moment whether VM_GetFrameCount properly checks >>> for a live target thread? >> >> David, thank you for the review! >> It looks like the check is missed. >> Please, give me some time to make sure what is needed here. > > Check out the work done via this changeset: > > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c1d7040a1183 > > Sergey did the push via: > > JDK-8022836 JVM crashes in > JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR > and GET_OWNED_MONITOR > https://bugs.openjdk.java.net/browse/JDK-8022836 > > but the real commentary about the bug is in this one: > > JDK-7154963 crash in JvmtiEnvBase::get_current_contended_monitor() > https://bugs.openjdk.java.net/browse/JDK-7154963 > > I think above code is what you want... I know what to check, just need to make sure new check is in a right place. :) One of the examples is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8030027-JVMTI-HS101.1/ Thanks, Serguei > > Dan > > >> >> Thanks! >> Serguei >> >>> >>> David >>> >>>> The bug 6280037 should go out of the Test Stabilization radar >>>> (remove >>>> the svc-nightly label) >>>> as the most of the impacted tests are covered by the 6471769. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >> > From alejandro.murillo at oracle.com Mon Feb 3 15:14:29 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 03 Feb 2014 16:14:29 -0700 Subject: [Rectification] Re: New hotspot repo for 7u60 changes In-Reply-To: <52EC36F5.9020208@oracle.com> References: <52EC36F5.9020208@oracle.com> Message-ID: <52F022D5.8010308@oracle.com> On 1/31/2014 4:51 PM, Alejandro E Murillo wrote: > Starting immediately, any hotspot change destined for 7u60 should go to: > > hg.openjdk.java.net/hsx/jdk7u60/hotspot > > These repos may not be available until the end of the day today > > This means that hg.openjdk.java.net/hsx/jdk7u/ is now associated to 7u80, > so any hotspot change destined to 7u80 should be pushed to that repo. > > As usual do not hesitate to ask if you have any question > thanks > To follow the same model followed for non hotspot changes(see [1]), all hotspot changes intended for 7u (7u60 and 7u80 for the time being), should be pushed, as usual to hsx/jdk7u/hotspot [2]. I will then snapshot and PIT as usual and push to the jdk7u master and jdk7u-dev, and from there, the 7u60 changes will be brought to the 7u60 stabilization repos [3] and [4] by the repo maintainers. so do not push anything to hsx/jdk7u60/hotspot, please push to hsx/jdk7u/hotspot as usual. apologies this created any confusion thanks -- Alejandro From alejandro.murillo at oracle.com Mon Feb 3 15:16:08 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 03 Feb 2014 16:16:08 -0700 Subject: [Rectification] Re: New hotspot repo for 7u60 changes In-Reply-To: <52F022D5.8010308@oracle.com> References: <52EC36F5.9020208@oracle.com> <52F022D5.8010308@oracle.com> Message-ID: <52F02338.9030907@oracle.com> On 2/3/2014 4:14 PM, Alejandro E Murillo wrote: > > On 1/31/2014 4:51 PM, Alejandro E Murillo wrote: >> Starting immediately, any hotspot change destined for 7u60 should go to: >> >> hg.openjdk.java.net/hsx/jdk7u60/hotspot >> >> These repos may not be available until the end of the day today >> >> This means that hg.openjdk.java.net/hsx/jdk7u/ is now associated to >> 7u80, >> so any hotspot change destined to 7u80 should be pushed to that repo. >> >> As usual do not hesitate to ask if you have any question >> thanks >> > To follow the same model followed for non hotspot changes(see [1]), > all hotspot changes intended for 7u (7u60 and 7u80 for the time being), > should be pushed, as usual to hsx/jdk7u/hotspot [2]. > > I will then snapshot and PIT as usual and push to the jdk7u master > and jdk7u-dev, > and from there, the 7u60 changes will be brought to the 7u60 > stabilization > repos [3] and [4] by the repo maintainers. > > so do not push anything to hsx/jdk7u60/hotspot, > please push to hsx/jdk7u/hotspot as usual. > > apologies this created any confusion > thanks > [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-January/008315.html [2] http://hg.openjdk.java.net/hsx/jdk7u/hotspot [3] http://hg.openjdk.java.net/jdk7u/jdk7u60/hotspot/ [3] http://hg.openjdk.java.net/jdk7u/jdk7u60-dev/hotspot/ -- Alejandro From lois.foltan at oracle.com Mon Feb 3 15:48:51 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 03 Feb 2014 18:48:51 -0500 Subject: RFR: 8032010: Attempt to resolve abstract method in concrete class fails with AbstractMethodError In-Reply-To: <52EC277B.3070605@oracle.com> References: <52EC277B.3070605@oracle.com> Message-ID: <52F02AE3.3050907@oracle.com> Hi Calvin, - src/share/vm/interpreter/linkResolver.cpp Looks good, no comments. - test/runtime/lambda-features/TestConcreteClassWithAbstractMethod.java Looks good. Please update the comments that contain the pseudo Java code describing the test's purpose. The comments need to reflect that the callsite to the method of interest, "m()", actually occurs within p1.T3's "test()" method. Thank you, Lois On 1/31/2014 5:45 PM, Calvin Cheung wrote: > This change, by removing a check in LinkResolver::resolve_method(), is > to conform with the recent change in JVMS-8 [1]. > The following check during method resolution is removed: > JVMS-5.4.3.3. Method Resolution > "If method lookup succeeds and the method is abstract, but C is not > abstract, method resolution throws an AbstractMethodError." > > bug: https://bugs.openjdk.java.net/browse/JDK-8032010 > > webrev: http://cr.openjdk.java.net/~ccheung/8032010/webrev/ > > tests: (on linux-x64) > vm.quick > jck vm and lang > jtreg on java/util/stream and the new testcase > defmeth > jprt > > thanks, > Calvin > > [1] http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.1.html#J From serguei.spitsyn at oracle.com Mon Feb 3 16:04:10 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 03 Feb 2014 16:04:10 -0800 Subject: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <52F01E0D.8010304@oracle.com> References: <52EC62CD.8000300@oracle.com> <52EFBAF6.8000404@oracle.com> <52EFF84E.1050800@oracle.com> <52F01E0D.8010304@oracle.com> Message-ID: <52F02E7A.9090603@oracle.com> On 2/3/14 2:54 PM, Daniel D. Daugherty wrote: > On 2/3/14 1:13 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you for reviewing! >> Some comments are below. >> >> On 2/3/14 7:51 AM, Daniel D. Daugherty wrote: >>> On 1/31/14 7:58 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-FRAME/ >>>> >>> >>> src/share/vm/prims/jvmtiEnv.cpp >>> Thumbs up on the code change. >>> >>> I've never been a fan of the: >>> >>> if (is_thread_fully_suspended(...)) >>> do-something-direct >>> else >>> do-something-via-a-safepoint >>> >>> model. We don't have any mechanism in the VM to keep the >>> is_thread_fully_suspended() constraint true over the >>> execution time of the "do-something-direct" operation so >>> we've always been exposed to races. >> >> Thank you for this confirmation. >> So that, we are in sync here. >> >> >>> Also, I think this >>> model is used for several other JVM/TI calls so you might >>> want to visit those also with an eye on safety. >> >> Yes, I'm looking to isolate and double check other places like this >> in the code. >> Another piece of work is to isolate other bugs on this topic. >> >> >>> >>> For this specific change, I think the comment would be >>> better as: >>> >>> // It is only safe to perform the direct operation on the current >>> // thread. All other usage needs to use a vm-op for safety. >> >> It is taken, thanks! >> >>> In particular, I don't agree with this part of the comment: >>> >>> // Performance-wise the only important case is when current >>> thread is >>> // the target thread. >>> >>> I'm not sure how you can state that performance on the current >>> thread >>> is the only important case, but maybe I don't understand what >>> you're >>> really trying to say here. >> >> I agree, the comment is not clear. >> Probably, the comment had to say: "the only case where we can keep >> performance >> without loosing safety is the target thread is current ...". >> In fact, collecting data at a safepoint is the only way to make it safe. >> If the target thread is not current then: >> - a) thread has been suspended: already slow path, so that >> performance is not that critical >> - b) thread has not been suspended: the information we provide is >> transient, >> safepoint is the only way to get it safe (is is correct?) > > Yes, the only safe way to get info for another thread is via > a safepoint operation. Ok, thanks. >>> >>> Now for the more general question with respect to this bug: 6471769 >>> I've having trouble connecting this change (which I like) to this >>> particular bug report. >>> >>> The crash in the bug's description looks like this: >>> >>> # Internal Error >>> (/net/prt-solamd64-q1-2/PrtBuildDir/workspace/src/share/vm/prims/jvmtiThreadState.cpp, >>> 273), pid=9561, tid=2 >>> # >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM >>> (20060914135846.dcubed.service_hs_b02_merge.2-debug compiled mode) >>> # >>> # Error: assert(_cur_stack_depth == count_frames(),"cur_stack_depth >>> out of sync") >>> >>> V [libjvm.so+0x1217206];; void VMError::report_and_die()+0x606 >>> V [libjvm.so+0x667841];; void report_assertion_failure(const >>> char*,int,const char*)+0x61 >>> V [libjvm.so+0xca9557];; int JvmtiThreadState::cur_stack_depth()+0x6e7 >>> V [libjvm.so+0xc1caaa];; void >>> JvmtiExport::post_method_exit(JavaThread*,methodOop,frame)+0x21ba >>> V [libjvm.so+0x8385de];; void >>> InterpreterRuntime::post_method_exit(JavaThread*)+0x21e >>> j java.io.ObjectInputStream$BlockDataInputStream.getBlockDataMode()Z+4 >>> >>> In the above crash, the current thread is trying to post a >>> JVMTI_EVENT_METHOD_EXIT and during the event posting code, it >>> calls cur_stack_depth() which fails an assert because the >>> cached stack depth doesn't match the current queried value: >>> >>> 282 int JvmtiThreadState::cur_stack_depth() { >>> 283 uint32_t debug_bits = 0; >>> 284 guarantee(JavaThread::current() == get_thread() || >>> 285 JvmtiEnv::is_thread_fully_suspended(get_thread(), false, >>> &debug_bits >>> ), >>> 286 "must be current thread or suspended"); >>> 287 >>> 288 if (!is_interp_only_mode() || _cur_stack_depth == >>> UNKNOWN_STACK_DEPTH) >>> { >>> 289 _cur_stack_depth = count_frames(); >>> 290 } else { >>> 291 // heavy weight assert >>> 292 assert(_cur_stack_depth == count_frames(), >>> 293 "cur_stack_depth out of sync"); >>> 294 } >>> 295 return _cur_stack_depth; >>> 296 } >>> >>> >>> This is not an unsafe query from one thread to another target thread >>> so I don't see how the proposed change will address this failure mode. >>> In particular, the assertion is troubling because it tells me that >>> the cached stack depth for the current thread is either wrong or has >>> been corrupted. >> >> The above are consequences of unsafe operations we are doing. >> Current thread should not calculate frame count of target thread (if >> different) other than at a safepoint. >> We assume the thread is suspended but, in fact, it was not. >> So that we lost safety here and all manifestation we observe are the >> consequences. > > For at least the stack trace shown in the description of 6471769, > it is not an unsafe case because the thread is operating on itself. > All I'm saying here is that 6471769 is not the right bug to use for > this fix... Thank you for sharing the concern. I was not able to reproduce the issue and so, did not prove my theory (which can be wrong). But you have a pretty valid point here. I still think, the stack trace with the assert is a consequence of a previous unsafe calculation on another thread. But that calculation is probably different than that I'm fixing in this webrev. >> This bug covers the frames miscount issue. >> In the fastdebug mode we may get the assert as in this bug report: >> https://bugs.openjdk.java.net/browse/JDK-8032223 > > This bug: JDK-8032223 seems to be a perfect match for code that you > are proposing the change in your current webrev. You have a thread > ("JDWP Transport Listener: dt_socket") that is trying to query the > frame count on another thread... That target JavaThread met the > is_thread_fully_suspended() criteria when execution went down the > direct path, but later the target stopped meeting that criteria... > > And boom... > >> There is another potential race that I forgot to check and fix but >> David pointed out. >> I will try to cover it in the next version of webrev. > > See the separate reply that I sent on that part... > > >> >> It is still possible there can be other issues here (as you say). >> But it is hard to make sure it is the case because it is extremely >> hard to reproduce (you know it!). >> I'd suggest to resolve it step-by-step: >> - fix the known safety issues >> - watch the nightly if anything else is left, file and fix new bugs > > This sounds like a good plan. > > >> >>> >>> To reiterate: >>> >>> - I like the code change! >>> - I would like to see the comment tweaked a bit >>> >>> You should consider going forward with this change using a different >>> bug ID, perhaps something like: >>> >>> JDK-NNNNNNN improve safety of JVM/TI GetFrameCount() >> >> There is already bug on this topic (and there are even more dups): >> https://bugs.openjdk.java.net/browse/JDK-8032223 >> >> But I still believe, the issue is the same ... > > I don't think the issues in JDK-6471769 and JDK-8032223 are the same; > well not the same for the crash in the description of JDK-6471769. I > didn't look closely at the other crashes... Ok. I will reopen the JDK-8032223 and use it for this fix. Thank you for helping to sort this out! Serguei > > > Dan > > >> >> >> Thanks! >> Serguei >> >>> >>> Dan >>> >>> >>> >>>> >>>> Summary: >>>> >>>> There is a general issue in the suspend equivalent condition >>>> mechanism: >>>> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >>>> may return different results: >>>> - 1-st: true >>>> - 2-nd: false >>>> >>>> This more generic suspend equivalent issue is covered by another >>>> bug: >>>> https://bugs.openjdk.java.net/browse/JDK-6280037 >>>> >>>> The bug to fix in this review is a specific manifestation of the >>>> 6280037 >>>> in the JVMTI GetFrameCount() that has a big impact on the SQE >>>> nightly. >>>> It is on the Test Stabilization radar (as well as the 6280037). >>>> There are many tests intermittently failing because of this. >>>> >>>> The webrev for review is a one-liner work around the 6280037 for >>>> the GetFrameCount(). >>>> >>>> The JVMTI GetFrameCount() spec tells: >>>> "If this function is called for a thread actively executing >>>> bytecodes (for example, >>>> not the current thread and not suspended), the information >>>> returned is transient." >>>> >>>> So, it is Ok to call the GetFrameCount() for non-suspended target >>>> threads. >>>> To achieve safety, the frame count for non-suspended threads is >>>> calculated at a safepoint. >>>> It should be Ok and more safe to do the same for suspended >>>> threads as well. >>>> There is no big performance impact because it is already on a >>>> slow path. >>>> It is still important to avoid safepointing when the target >>>> thread is current. >>>> >>>> The bug 6280037 should go out of the Test Stabilization radar >>>> (remove the svc-nightly label) >>>> as the most of the impacted tests are covered by the 6471769. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From christian.thalinger at oracle.com Mon Feb 3 16:08:40 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 3 Feb 2014 16:08:40 -0800 Subject: Error building hotspot with shark/zero In-Reply-To: References: Message-ID: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: > Hi, > I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: > > In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, > from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: > /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': > /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' > /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' > > line 72 looks like: > > llvm::Constant* get_external(const char* name, > const llvm::FunctionType* sig) { > return module()->getOrInsertFunction(name, sig); > } > > Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. > > Neale From alejandro.murillo at oracle.com Mon Feb 3 17:05:10 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 03 Feb 2014 18:05:10 -0700 Subject: Error building hotspot with shark/zero In-Reply-To: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> Message-ID: <52F03CC6.3030302@oracle.com> I believe this has to do with this bug: https://bugs.openjdk.java.net/browse/JDK-8024648 there seems to be a fix for this, but unfortunately the patch hasn't been supplied Thanks Alejandro On 2/3/2014 5:08 PM, Christian Thalinger wrote: > I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... > > On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: > >> Hi, >> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >> >> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >> >> line 72 looks like: >> >> llvm::Constant* get_external(const char* name, >> const llvm::FunctionType* sig) { >> return module()->getOrInsertFunction(name, sig); >> } >> >> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >> >> Neale -- Alejandro From calvin.cheung at oracle.com Mon Feb 3 18:00:03 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 03 Feb 2014 18:00:03 -0800 Subject: RFR: 8032010: Attempt to resolve abstract method in concrete class fails with AbstractMethodError In-Reply-To: <52F041E2.2060707@oracle.com> References: <52EC277B.3070605@oracle.com> <52F02AE3.3050907@oracle.com> <52F03B7F.1030209@oracle.com> <52F041E2.2060707@oracle.com> Message-ID: <52F049A3.9040100@oracle.com> I forgot to include the open alias. On 2/3/2014 5:26 PM, Lois Foltan wrote: > > On 2/3/2014 7:59 PM, Calvin Cheung wrote: >> Hi Lois, >> >> Thanks for your review. >> >> On 2/3/2014 3:48 PM, Lois Foltan wrote: >>> Hi Calvin, >>> >>> - src/share/vm/interpreter/linkResolver.cpp >>> Looks good, no comments. >>> >>> - test/runtime/lambda-features/TestConcreteClassWithAbstractMethod.java >>> Looks good. Please update the comments that contain the pseudo >>> Java code describing >>> the test's purpose. The comments need to reflect that the >>> callsite to the method of interest, "m()", >>> actually occurs within p1.T3's "test()" method. >> >> How about changing the comments to the following? >> 37 /* >> 38 * class T1 { public int m() {} } >> 39 * class T2 { public abstract int m(); } >> 40 * class T3 { public int m() {} } >> 41 * >> 42 * Call site: T3.test() { invokevirtual T2.m() } >> 43 * T3.m() should be invoked >> 44 */ > > Yes, thank you. I don't know if you meant to cc the openjdk distro or > not? I don't need to see another webrev at this point, looks great! > Lois > >> >> thanks, >> Calvin >> >>> >>> Thank you, >>> Lois >>> >>> On 1/31/2014 5:45 PM, Calvin Cheung wrote: >>>> This change, by removing a check in LinkResolver::resolve_method(), >>>> is to conform with the recent change in JVMS-8 [1]. >>>> The following check during method resolution is removed: >>>> JVMS-5.4.3.3. Method Resolution >>>> "If method lookup succeeds and the method is abstract, but C is not >>>> abstract, method resolution throws an AbstractMethodError." >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8032010 >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8032010/webrev/ >>>> >>>> tests: (on linux-x64) >>>> vm.quick >>>> jck vm and lang >>>> jtreg on java/util/stream and the new testcase >>>> defmeth >>>> jprt >>>> >>>> thanks, >>>> Calvin >>>> >>>> [1] http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.1.html#J >>> >> > From alejandro.murillo at oracle.com Mon Feb 3 18:23:25 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 04 Feb 2014 02:23:25 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.80-b00 for changeset b92f390febd0 Message-ID: <20140204022337.AFE2F62996@hg.openjdk.java.net> Changeset: 2c512895756d Author: amurillo Date: 2014-02-03 18:20 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2c512895756d Added tag hs24.80-b00 for changeset b92f390febd0 ! .hgtags From alejandro.murillo at oracle.com Mon Feb 3 19:55:57 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 04 Feb 2014 03:55:57 +0000 Subject: hg: hsx/jdk7u/hotspot: 8033524: Set minor version for hotspot in 7u80 to 80 and build number to b01 Message-ID: <20140204035559.C8B776299A@hg.openjdk.java.net> Changeset: 5bb695c660d7 Author: amurillo Date: 2014-02-03 18:29 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/5bb695c660d7 8033524: Set minor version for hotspot in 7u80 to 80 and build number to b01 Reviewed-by: jcoomes ! make/hotspot_version From serguei.spitsyn at oracle.com Tue Feb 4 03:13:20 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Feb 2014 03:13:20 -0800 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) Message-ID: <52F0CB50.3040703@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8032223 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ Summary: This is the second round of review for this issue. But it was decided that the JDK-8032223 must be used to cover it instead of the JDK-6471769. The 8032223 was initially closed as a dup of 6471769 but it has been re-open now. There is a general issue in the suspend equivalent condition mechanism: Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: - 1-st: true - 2-nd: false This suspend equivalent issue is covered by another bug: https://bugs.openjdk.java.net/browse/JDK-6280037 The bug to fix in this review is a specific manifestation of the 6280037 in the JVMTI GetFrameCount() that has a major impact on the SQE nightly. It is on the Test Stabilization radar as well as the 6280037. There are many tests intermittently failing because of this. I've also decided to fix the same issue in the JVMTI GetFrameLocation() as well. The JVMTI GetFrameCount() spec tells: "If this function is called for a thread actively executing bytecodes (for example, not the current thread and not suspended), the information returned is transient." So, it is Ok to call the GetFrameCount() for the non-suspended target thread. To achieve safety, the frame count for non-suspended threads is calculated at a safepoint. It should be Ok and more safe to do the same for suspended threads as well. There should be no big performance impact because it is already on a slow path. It is still important to avoid safepointing when the target thread is current. The bug 6280037 should go out of the Test Stabilization radar (remove the svc-nightly label) as the most of the impacted tests must be covered by the 8032223. Testing: In progress: - nsk.jvmti, nsk.jdi, nsk.jdwp - JTreg com/sun/jdi Thanks, Serguei From david.holmes at oracle.com Tue Feb 4 03:46:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 04 Feb 2014 21:46:20 +1000 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) In-Reply-To: <52F0CB50.3040703@oracle.com> References: <52F0CB50.3040703@oracle.com> Message-ID: <52F0D30C.20401@oracle.com> Hi Serguei, Looks okay to me. Minor nit: "use a vm-op for safety" is actually "use a vm-safepoint-op for safety". Not all VM ops need involve a safepoint. David On 4/02/2014 9:13 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8032223 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ > > > Summary: > > This is the second round of review for this issue. > But it was decided that the JDK-8032223 must be used to cover it > instead of the JDK-6471769. > The 8032223 was initially closed as a dup of 6471769 but it has been > re-open now. > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may > return different results: > - 1-st: true > - 2-nd: false > > This suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the 6280037 > in the JVMTI GetFrameCount() that has a major impact on the SQE nightly. > It is on the Test Stabilization radar as well as the 6280037. > There are many tests intermittently failing because of this. > I've also decided to fix the same issue in the JVMTI > GetFrameLocation() as well. > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing > bytecodes (for example, > not the current thread and not suspended), the information > returned is transient." > > So, it is Ok to call the GetFrameCount() for the non-suspended target > thread. > To achieve safety, the frame count for non-suspended threads is > calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads as > well. > There should be no big performance impact because it is already on a > slow path. > It is still important to avoid safepointing when the target thread is > current. > > The bug 6280037 should go out of the Test Stabilization radar (remove > the svc-nightly label) > as the most of the impacted tests must be covered by the 8032223. > > > Testing: > In progress: > - nsk.jvmti, nsk.jdi, nsk.jdwp > - JTreg com/sun/jdi > > > Thanks, > Serguei > From mikael.gerdin at oracle.com Tue Feb 4 03:59:55 2014 From: mikael.gerdin at oracle.com (mikael.gerdin at oracle.com) Date: Tue, 04 Feb 2014 11:59:55 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20140204120107.06F23629A4@hg.openjdk.java.net> Changeset: e311856f0adb Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/e311856f0adb 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: c80ac841bd81 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c80ac841bd81 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Reviewed-by: brutisso, tschatzl, roland ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp From daniel.daugherty at oracle.com Tue Feb 4 07:48:10 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 04 Feb 2014 08:48:10 -0700 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) In-Reply-To: <52F0CB50.3040703@oracle.com> References: <52F0CB50.3040703@oracle.com> Message-ID: <52F10BBA.8060504@oracle.com> On 2/4/14 4:13 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8032223 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ > src/share/vm/prims/jvmtiEnvBase.hpp No comments. src/share/vm/prims/jvmtiEnv.cpp No comments beyond David's tweak to the comment. For future work... Looks like these VM ops also need the liveness check on the target JavaThread: VM_GetOwnedMonitorInfo VM_GetStackTrace JvmtiEnv::GetStackTrace() looks like it has the same is_thread_fully_suspended() flaw... Dan > > Summary: > > This is the second round of review for this issue. > But it was decided that the JDK-8032223 must be used to cover it > instead of the JDK-6471769. > The 8032223 was initially closed as a dup of 6471769 but it has been > re-open now. > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() > may return different results: > - 1-st: true > - 2-nd: false > > This suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > The bug to fix in this review is a specific manifestation of the > 6280037 > in the JVMTI GetFrameCount() that has a major impact on the SQE > nightly. > It is on the Test Stabilization radar as well as the 6280037. > There are many tests intermittently failing because of this. > I've also decided to fix the same issue in the JVMTI > GetFrameLocation() as well. > > The JVMTI GetFrameCount() spec tells: > "If this function is called for a thread actively executing > bytecodes (for example, > not the current thread and not suspended), the information > returned is transient." > > So, it is Ok to call the GetFrameCount() for the non-suspended > target thread. > To achieve safety, the frame count for non-suspended threads is > calculated at a safepoint. > It should be Ok and more safe to do the same for suspended threads > as well. > There should be no big performance impact because it is already on a > slow path. > It is still important to avoid safepointing when the target thread > is current. > > The bug 6280037 should go out of the Test Stabilization radar > (remove the svc-nightly label) > as the most of the impacted tests must be covered by the 8032223. > > > Testing: > In progress: > - nsk.jvmti, nsk.jdi, nsk.jdwp > - JTreg com/sun/jdi > > > Thanks, > Serguei > From volker.simonis at gmail.com Tue Feb 4 08:18:58 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 4 Feb 2014 17:18:58 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) Message-ID: Hi, I know this is an old topic and actually I was involved myself in some of these discussions. Nevertheless, the topic regularly pops up again and every time this happens and I take a deeper look at the topic I have the feeling I still haven?t completely understood it. Current state: On Linux, we are currently compiling the HotSpot with the '-fvisibility=hidden' flag which effectively hides all symbols except the ones which are explicitely declared to have default visibility (with the macro JNIEXPORT which expands to __attribute__((visibility("default")))). This was introduced by "6588413: Use -fvisibility=hidden for gcc compiles" [1] in HS 21 and it is potentially a good change because it hides all symbols by default and it enables certain compiler optimizations on some platforms (see "How To Write Shared Libraries" [2]). However, independently of this change, we still use export maps (i.e. --version-script=mapfile_reorder) in addition to setting the explicit symbol visibility. While [2] recommends this as good practice, I don't see the real benefit of having both - -fvisibility=hidden/__attribute__((visibility("default"))) and export maps except if we were maintaining a versioned ABI. But as far as I can tell, that's not the case for HotSpot. So finally my question: is there any real reason (except the fact that "we always did it that way") why we would still need to use export maps on Linux where symbol hiding is done with -fvisibility=hidden/__attribute__((visibility("default"))) anyway? Dropping the maps would make the maintenance of exported symbols easier as we wouldn't have to keep the export map files and the JNIEXPORT functions in sync. Thank you and best regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-6588413 [2] http://www.akkadia.org/drepper/dsohowto.pdf From serguei.spitsyn at oracle.com Tue Feb 4 11:25:17 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Feb 2014 11:25:17 -0800 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) In-Reply-To: <52F0D30C.20401@oracle.com> References: <52F0CB50.3040703@oracle.com> <52F0D30C.20401@oracle.com> Message-ID: <52F13E9D.2040105@oracle.com> Thanks, David! Serguei On 2/4/14 3:46 AM, David Holmes wrote: > Hi Serguei, > > Looks okay to me. > > Minor nit: "use a vm-op for safety" is actually "use a vm-safepoint-op > for safety". Not all VM ops need involve a safepoint. > > David > > On 4/02/2014 9:13 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8032223 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ >> >> >> >> Summary: >> >> This is the second round of review for this issue. >> But it was decided that the JDK-8032223 must be used to cover it >> instead of the JDK-6471769. >> The 8032223 was initially closed as a dup of 6471769 but it has been >> re-open now. >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may >> return different results: >> - 1-st: true >> - 2-nd: false >> >> This suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the >> 6280037 >> in the JVMTI GetFrameCount() that has a major impact on the SQE >> nightly. >> It is on the Test Stabilization radar as well as the 6280037. >> There are many tests intermittently failing because of this. >> I've also decided to fix the same issue in the JVMTI >> GetFrameLocation() as well. >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing >> bytecodes (for example, >> not the current thread and not suspended), the information >> returned is transient." >> >> So, it is Ok to call the GetFrameCount() for the non-suspended target >> thread. >> To achieve safety, the frame count for non-suspended threads is >> calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads as >> well. >> There should be no big performance impact because it is already on a >> slow path. >> It is still important to avoid safepointing when the target thread is >> current. >> >> The bug 6280037 should go out of the Test Stabilization radar (remove >> the svc-nightly label) >> as the most of the impacted tests must be covered by the 8032223. >> >> >> Testing: >> In progress: >> - nsk.jvmti, nsk.jdi, nsk.jdwp >> - JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> From serguei.spitsyn at oracle.com Tue Feb 4 12:45:00 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Feb 2014 12:45:00 -0800 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) In-Reply-To: <52F10BBA.8060504@oracle.com> References: <52F0CB50.3040703@oracle.com> <52F10BBA.8060504@oracle.com> Message-ID: <52F1514C.1050405@oracle.com> Thanks, Dan! Some comments below. On 2/4/14 7:48 AM, Daniel D. Daugherty wrote: > On 2/4/14 4:13 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8032223 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ >> > > src/share/vm/prims/jvmtiEnvBase.hpp > No comments. > > src/share/vm/prims/jvmtiEnv.cpp > No comments beyond David's tweak to the comment. Will fix it before push. > For future work... > > Looks like these VM ops also need the liveness check on the > target JavaThread: > > VM_GetOwnedMonitorInfo > VM_GetStackTrace > > JvmtiEnv::GetStackTrace() looks like it has the same > is_thread_fully_suspended() flaw... I know about this. There are even more issues: GetCurrentContendedMonitor GetOwnedMonitorStackDepthInfo NotifyFramePop I'll check if we can use an existing bug to add this extra request. Otherwise, will file new one. Thanks, Serguei > > Dan > > > >> >> Summary: >> >> This is the second round of review for this issue. >> But it was decided that the JDK-8032223 must be used to cover it >> instead of the JDK-6471769. >> The 8032223 was initially closed as a dup of 6471769 but it has >> been re-open now. >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >> may return different results: >> - 1-st: true >> - 2-nd: false >> >> This suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> The bug to fix in this review is a specific manifestation of the >> 6280037 >> in the JVMTI GetFrameCount() that has a major impact on the SQE >> nightly. >> It is on the Test Stabilization radar as well as the 6280037. >> There are many tests intermittently failing because of this. >> I've also decided to fix the same issue in the JVMTI >> GetFrameLocation() as well. >> >> The JVMTI GetFrameCount() spec tells: >> "If this function is called for a thread actively executing >> bytecodes (for example, >> not the current thread and not suspended), the information >> returned is transient." >> >> So, it is Ok to call the GetFrameCount() for the non-suspended >> target thread. >> To achieve safety, the frame count for non-suspended threads is >> calculated at a safepoint. >> It should be Ok and more safe to do the same for suspended threads >> as well. >> There should be no big performance impact because it is already on >> a slow path. >> It is still important to avoid safepointing when the target thread >> is current. >> >> The bug 6280037 should go out of the Test Stabilization radar >> (remove the svc-nightly label) >> as the most of the impacted tests must be covered by the 8032223. >> >> >> Testing: >> In progress: >> - nsk.jvmti, nsk.jdi, nsk.jdwp >> - JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> > From markus.gronlund at oracle.com Tue Feb 4 12:59:49 2014 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Tue, 04 Feb 2014 20:59:49 +0000 Subject: hg: hsx/jdk7u60/hotspot: 8033487: Improve GC option handling Message-ID: <20140204205953.E49CF629CC@hg.openjdk.java.net> Changeset: dd6cb2f6cecd Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u60/hotspot/rev/dd6cb2f6cecd 8033487: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp From jesper.wilhelmsson at oracle.com Tue Feb 4 11:46:53 2014 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 04 Feb 2014 19:46:53 +0000 Subject: hg: hsx/jdk7u/hotspot: 8028391: Make the Min/MaxHeapFreeRatio flags manageable Message-ID: <20140204194706.56B5B629C5@hg.openjdk.java.net> Changeset: 88a32ae18e4b Author: jwilhelm Date: 2014-02-04 16:11 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/88a32ae18e4b 8028391: Make the Min/MaxHeapFreeRatio flags manageable Summary: Made the flags Min- and MaxHeapFreeRatio manageable, and implemented support for these flags in ParallelGC. Reviewed-by: sla, mgerdin, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/management.cpp From vladimir.kozlov at oracle.com Tue Feb 4 15:45:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 04 Feb 2014 15:45:29 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F01569.3070201@oracle.com> References: <52F01569.3070201@oracle.com> Message-ID: <52F17B99.6080405@oracle.com> Changes look reasonable. Thank, Vladimir On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8025841 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 > > > Summary: > > The fix contributed by Oleg Mazurov to improve profiling data quality. > It moves the "vtable stub" dynamic code notification to the right place. > I've already reviewed the fix, and it looks good to me. > > Bug report description: > > "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled > when > a new chunk of memory for subsequent vtable and itable stubs is > allocated. > That chunk is uninitialized (contains zeros or garbage) although > due to the fact > that the actual event delivery is deferred, at least one vtable > comes out right. > > This event should describe an individual vtable/itable stub (base > address and size) > and only after it's been created (memory is actually populated with > code). > Where VM diagnostic messages about vtable/itable stubs are issued upon > -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI > events as well. > > Getting vtables/itables right is important in the context of > performance analysis as > that dynamically generated code may accumulate quite noticeable CPU > time > (especially itabes), sometimes larger than the actual Java methods > called." > > > Testing: > Oleg tested it in the Oracle Studio Performance Analyzer environment. > nsk.jvmti, nsk.jdi, nsk.jdwp, > In progress: Jtreg com/sun/jdi, java/lang/instrument > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Tue Feb 4 16:14:48 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 04 Feb 2014 16:14:48 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F17B99.6080405@oracle.com> References: <52F01569.3070201@oracle.com> <52F17B99.6080405@oracle.com> Message-ID: <52F18278.309@oracle.com> Thanks a lot, Vladimir! Serguei On 2/4/14 3:45 PM, Vladimir Kozlov wrote: > Changes look reasonable. > > Thank, > Vladimir > > On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8025841 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >> >> >> >> Summary: >> >> The fix contributed by Oleg Mazurov to improve profiling data >> quality. >> It moves the "vtable stub" dynamic code notification to the right >> place. >> I've already reviewed the fix, and it looks good to me. >> >> Bug report description: >> >> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled >> when >> a new chunk of memory for subsequent vtable and itable stubs is >> allocated. >> That chunk is uninitialized (contains zeros or garbage) although >> due to the fact >> that the actual event delivery is deferred, at least one vtable >> comes out right. >> >> This event should describe an individual vtable/itable stub (base >> address and size) >> and only after it's been created (memory is actually populated with >> code). >> Where VM diagnostic messages about vtable/itable stubs are >> issued upon >> -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI >> events as well. >> >> Getting vtables/itables right is important in the context of >> performance analysis as >> that dynamically generated code may accumulate quite noticeable CPU >> time >> (especially itabes), sometimes larger than the actual Java methods >> called." >> >> >> Testing: >> Oleg tested it in the Oracle Studio Performance Analyzer environment. >> nsk.jvmti, nsk.jdi, nsk.jdwp, >> In progress: Jtreg com/sun/jdi, java/lang/instrument >> >> >> Thanks, >> Serguei >> From david.holmes at oracle.com Tue Feb 4 16:51:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Feb 2014 10:51:15 +1000 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: References: Message-ID: <52F18B03.1000107@oracle.com> Hi Volker, On 5/02/2014 2:18 AM, Volker Simonis wrote: > I know this is an old topic and actually I was involved myself in some > of these discussions. Nevertheless, the topic regularly pops up again > and every time this happens and I take a deeper look at the topic I > have the feeling I still haven?t completely understood it. > > Current state: > > On Linux, we are currently compiling the HotSpot with the > '-fvisibility=hidden' flag which effectively hides all symbols except > the ones which are explicitely declared to have default visibility > (with the macro JNIEXPORT which expands to > __attribute__((visibility("default")))). > > This was introduced by "6588413: Use -fvisibility=hidden for gcc > compiles" [1] in HS 21 and it is potentially a good change because it > hides all symbols by default and it enables certain compiler > optimizations on some platforms (see "How To Write Shared Libraries" > [2]). > > However, independently of this change, we still use export maps (i.e. > --version-script=mapfile_reorder) in addition to setting the explicit > symbol visibility. While [2] recommends this as good practice, I don't > see the real benefit of having both - > -fvisibility=hidden/__attribute__((visibility("default"))) and export > maps except if we were maintaining a versioned ABI. But as far as I > can tell, that's not the case for HotSpot. > > So finally my question: is there any real reason (except the fact that > "we always did it that way") why we would still need to use export > maps on Linux where symbol hiding is done with > -fvisibility=hidden/__attribute__((visibility("default"))) anyway? > Dropping the maps would make the maintenance of exported symbols > easier as we wouldn't have to keep the export map files and the > JNIEXPORT functions in sync. From past discussions isn't this because we need the map files to expose dynamically generated symbols? (And so we must then also add the other visible symbols.) Does that make the visibility attributes redundant? I'm not sure, but they serve as a clear statement of intent anyway. David > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-6588413 > [2] http://www.akkadia.org/drepper/dsohowto.pdf > From jeremymanson at google.com Tue Feb 4 23:09:19 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 4 Feb 2014 23:09:19 -0800 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <52F18B03.1000107@oracle.com> References: <52F18B03.1000107@oracle.com> Message-ID: Also, don't you statically link libstdc++ into Hotspot? It would break many, many things if the symbols from that were exported from Hotspot (pretty much anything with native code written in C++). Jeremy On Tue, Feb 4, 2014 at 4:51 PM, David Holmes wrote: > Hi Volker, > > > On 5/02/2014 2:18 AM, Volker Simonis wrote: > >> I know this is an old topic and actually I was involved myself in some >> of these discussions. Nevertheless, the topic regularly pops up again >> and every time this happens and I take a deeper look at the topic I >> have the feeling I still haven?t completely understood it. >> >> Current state: >> >> On Linux, we are currently compiling the HotSpot with the >> '-fvisibility=hidden' flag which effectively hides all symbols except >> the ones which are explicitely declared to have default visibility >> (with the macro JNIEXPORT which expands to >> __attribute__((visibility("default")))). >> >> This was introduced by "6588413: Use -fvisibility=hidden for gcc >> compiles" [1] in HS 21 and it is potentially a good change because it >> hides all symbols by default and it enables certain compiler >> optimizations on some platforms (see "How To Write Shared Libraries" >> [2]). >> >> However, independently of this change, we still use export maps (i.e. >> --version-script=mapfile_reorder) in addition to setting the explicit >> symbol visibility. While [2] recommends this as good practice, I don't >> see the real benefit of having both - >> -fvisibility=hidden/__attribute__((visibility("default"))) and export >> maps except if we were maintaining a versioned ABI. But as far as I >> can tell, that's not the case for HotSpot. >> >> So finally my question: is there any real reason (except the fact that >> "we always did it that way") why we would still need to use export >> maps on Linux where symbol hiding is done with >> -fvisibility=hidden/__attribute__((visibility("default"))) anyway? >> Dropping the maps would make the maintenance of exported symbols >> easier as we wouldn't have to keep the export map files and the >> JNIEXPORT functions in sync. >> > > From past discussions isn't this because we need the map files to expose > dynamically generated symbols? (And so we must then also add the other > visible symbols.) Does that make the visibility attributes redundant? I'm > not sure, but they serve as a clear statement of intent anyway. > > David > > > Thank you and best regards, >> Volker >> >> [1] https://bugs.openjdk.java.net/browse/JDK-6588413 >> [2] http://www.akkadia.org/drepper/dsohowto.pdf >> >> From david.holmes at oracle.com Tue Feb 4 23:16:33 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Feb 2014 17:16:33 +1000 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: References: <52F18B03.1000107@oracle.com> Message-ID: <52F1E551.2070304@oracle.com> On 5/02/2014 5:09 PM, Jeremy Manson wrote: > Also, don't you statically link libstdc++ into Hotspot? Normally yes. > It would break > many, many things if the symbols from that were exported from Hotspot > (pretty much anything with native code written in C++). Doe static linking automatically re-export all the visible symbols of the linked in library? That would seem undesirable under most circumstances. David > Jeremy > > > On Tue, Feb 4, 2014 at 4:51 PM, David Holmes > wrote: > > Hi Volker, > > > On 5/02/2014 2:18 AM, Volker Simonis wrote: > > I know this is an old topic and actually I was involved myself > in some > of these discussions. Nevertheless, the topic regularly pops up > again > and every time this happens and I take a deeper look at the topic I > have the feeling I still haven?t completely understood it. > > Current state: > > On Linux, we are currently compiling the HotSpot with the > '-fvisibility=hidden' flag which effectively hides all symbols > except > the ones which are explicitely declared to have default visibility > (with the macro JNIEXPORT which expands to > __attribute__((visibility("__default")))). > > This was introduced by "6588413: Use -fvisibility=hidden for gcc > compiles" [1] in HS 21 and it is potentially a good change > because it > hides all symbols by default and it enables certain compiler > optimizations on some platforms (see "How To Write Shared Libraries" > [2]). > > However, independently of this change, we still use export maps > (i.e. > --version-script=mapfile___reorder) in addition to setting the > explicit > symbol visibility. While [2] recommends this as good practice, I > don't > see the real benefit of having both - > -fvisibility=hidden/____attribute__((visibility("__default"))) > and export > maps except if we were maintaining a versioned ABI. But as far as I > can tell, that's not the case for HotSpot. > > So finally my question: is there any real reason (except the > fact that > "we always did it that way") why we would still need to use export > maps on Linux where symbol hiding is done with > -fvisibility=hidden/____attribute__((visibility("__default"))) > anyway? > Dropping the maps would make the maintenance of exported symbols > easier as we wouldn't have to keep the export map files and the > JNIEXPORT functions in sync. > > > From past discussions isn't this because we need the map files to > expose dynamically generated symbols? (And so we must then also add > the other visible symbols.) Does that make the visibility attributes > redundant? I'm not sure, but they serve as a clear statement of > intent anyway. > > David > > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/__browse/JDK-6588413 > > [2] http://www.akkadia.org/__drepper/dsohowto.pdf > > > From george.triantafillou at oracle.com Wed Feb 5 07:06:22 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 05 Feb 2014 10:06:22 -0500 Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) Message-ID: <52F2536E.1000907@oracle.com> Please review the following fix for bug 8021774: JBS: https://bugs.openjdk.java.net/browse/JDK-8021774 Webrev: http://cr.openjdk.java.net/~gtriantafill/8021774/webrev.00/ This backport fix for JDK8 is a test stabilization change. The goal of the change is to ignore warnings with -XX:NativeMemoryTracking on Solaris and Linux in order to achieve a full pass of jtreg runtime tests. Thank you, George From neale at sinenomine.net Wed Feb 5 07:20:05 2014 From: neale at sinenomine.net (Neale Ferguson) Date: Wed, 5 Feb 2014 15:20:05 +0000 Subject: Error building hotspot with shark/zero In-Reply-To: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> Message-ID: <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net> Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: Linking vm... sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' sharedRuntime.o:(.bss+0x0): first defined here sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' sharedRuntime.o:(.bss+0x8): first defined here sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' sharedRuntime.o:(.bss+0x10): first defined here sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' sharedRuntime.o:(.bss+0x18): first defined here sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so make[6]: stat: libjvm.so: Too many levels of symbolic links Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. Neale On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... > > On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: > >> Hi, >> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >> >> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >> >> line 72 looks like: >> >> llvm::Constant* get_external(const char* name, >> const llvm::FunctionType* sig) { >> return module()->getOrInsertFunction(name, sig); >> } >> >> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >> >> Neale > From harold.seigel at oracle.com Wed Feb 5 09:40:40 2014 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 05 Feb 2014 12:40:40 -0500 Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) In-Reply-To: <52F2536E.1000907@oracle.com> References: <52F2536E.1000907@oracle.com> Message-ID: <52F27798.6010403@oracle.com> Hi George, The changes look good. Thanks, Harold On 2/5/2014 10:06 AM, George Triantafillou wrote: > Please review the following fix for bug 8021774: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8021774 > Webrev: > http://cr.openjdk.java.net/~gtriantafill/8021774/webrev.00/ > > > This backport fix for JDK8 is a test stabilization change. The goal of > the change is to ignore warnings with -XX:NativeMemoryTracking on > Solaris and Linux in order to achieve a full pass of jtreg runtime tests. > > Thank you, > George > From christian.tornqvist at oracle.com Wed Feb 5 09:48:12 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 5 Feb 2014 12:48:12 -0500 Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) In-Reply-To: <52F2536E.1000907@oracle.com> References: <52F2536E.1000907@oracle.com> Message-ID: <017201cf229a$70ecf880$52c6e980$@oracle.com> Looks good. Thanks for fixing this. Thanks, Christian -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George Triantafillou Sent: Wednesday, February 5, 2014 10:06 AM To: hotspot-dev at openjdk.java.net Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) Please review the following fix for bug 8021774: JBS: https://bugs.openjdk.java.net/browse/JDK-8021774 Webrev: http://cr.openjdk.java.net/~gtriantafill/8021774/webrev.00/ This backport fix for JDK8 is a test stabilization change. The goal of the change is to ignore warnings with -XX:NativeMemoryTracking on Solaris and Linux in order to achieve a full pass of jtreg runtime tests. Thank you, George From volker.simonis at gmail.com Wed Feb 5 10:09:25 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Feb 2014 19:09:25 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <52F1E551.2070304@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> Message-ID: On Wed, Feb 5, 2014 at 8:16 AM, David Holmes wrote: > On 5/02/2014 5:09 PM, Jeremy Manson wrote: >> >> Also, don't you statically link libstdc++ into Hotspot? > > > Normally yes. > That's bad - security-wise as well as from a usability perspective: Security-wise because the JDK will need to be rebuild for every security fix in libgcc and libstdc++. I'm not sure if there's at least somebody actively and regularly looking at libgcc/libstdc++ security issues. Considering the fact, that the JDK is usually build on a "not so new" Linux release when it is released for the first time, this even increases the possibility that libgcc/libstdc++ are actively supported on that release for the full JDK life time. >From a user perspective, because users can only safely use/link C++ JNI libraries with the JDK which have been build against the exactly same libgcc/libstdc++ version. Others, like RedHat (OpenJDK/IcedTea) and SAP (SAP JVM) don't do this any more - i.e. they link libgcc/libstdc++ dynamically, without any problems. While I'm aware that dynamic linking imposes some compatibility risks as well if the same binary must support a bunch of different releases, I still think that is easier to mange. I think static linking of libgcc/libstdc++ is pre-gcc-2.9.2 paranoia, but that's my personal opinion. Also that's a totally different discussion not related to my initial question. > >> It would break >> many, many things if the symbols from that were exported from Hotspot >> (pretty much anything with native code written in C++). > > > Doe static linking automatically re-export all the visible symbols of the > linked in library? That would seem undesirable under most circumstances. > Yes, Jeremy is totally right. I did some tests and realized, that even if we use -fvisibility=hidden in the compile step of a file, this will not help if we make a static library (i.e. a '.a' archive) from it. Linking such an archive into a shared library, will still let the shared library export all "non-static" objects from the archive. So, considering that the OpenDJK by default still statically links libgcc/libstdc++ by default, this is one justification for the usage of map files. I did some more experiments and looked at the current build system and also realized the following: the build dynamically builds a list of all vtable symbols of all classes and puts them into the map file which is used to generate the libjvm.so. If I remember right, they are (or were) needed for the serviceability agent. Now that would be another justification for the usage of a map file as I don't now how we could otherwise export the vtable symbols of all classes. But the funny thing is that I've just realized that this technique isn't working any more with gcc 4.3 and above (which I think is the build compiler of jdk8). Here are the details: The vtable symbols are defined as weak symbols in the object files like so: 0000000000000000 V _ZTV10ArrayKlass If such an object file will be linked with gcc 4.1.2 without map file into the libjvm.so, the symbol would turn into a local data object like so: 0000000000e37160 d _ZTV10ArrayKlass However, if we use a map file which specifies that the symbol '_ZTV10ArrayKlass' should be exported, the libjvm.so will contain the following, global symbol: 0000000001423240 D _ZTV10arrayKlass Now I think this is the expected result of the whole dynamic map-file generation process. However, with gcc 4.3 and later, there's no difference if the corresponding vtable symbol is mentioned in the export map or not. The resulting libjvm.so always only contains a local data object (just use 'nm --defined-only --extern-only libjvm.so' to check). Now I'm not sure if the vtable symbols arn't used by the serviceability agent any more or if just nobody has realized until now that they are not in exported from the libjvm.so any more. In any case, the whole magic of constructing a link export file at build time seems unnecessary by now. I've CC-ed serviceability group to comment on this issue. I'll plan do write down all my findings in a more readable way within the next days. If there are any more/other comments on this topic I'll be highly interested. Regards, Volker > David > >> Jeremy >> >> >> On Tue, Feb 4, 2014 at 4:51 PM, David Holmes > > wrote: >> >> Hi Volker, >> >> >> On 5/02/2014 2:18 AM, Volker Simonis wrote: >> >> I know this is an old topic and actually I was involved myself >> in some >> of these discussions. Nevertheless, the topic regularly pops up >> again >> and every time this happens and I take a deeper look at the topic >> I >> have the feeling I still haven?t completely understood it. >> >> Current state: >> >> On Linux, we are currently compiling the HotSpot with the >> '-fvisibility=hidden' flag which effectively hides all symbols >> except >> the ones which are explicitely declared to have default visibility >> (with the macro JNIEXPORT which expands to >> __attribute__((visibility("__default")))). >> >> >> This was introduced by "6588413: Use -fvisibility=hidden for gcc >> compiles" [1] in HS 21 and it is potentially a good change >> because it >> hides all symbols by default and it enables certain compiler >> optimizations on some platforms (see "How To Write Shared >> Libraries" >> [2]). >> >> However, independently of this change, we still use export maps >> (i.e. >> --version-script=mapfile___reorder) in addition to setting the >> >> explicit >> symbol visibility. While [2] recommends this as good practice, I >> don't >> see the real benefit of having both - >> -fvisibility=hidden/____attribute__((visibility("__default"))) >> >> and export >> maps except if we were maintaining a versioned ABI. But as far as >> I >> can tell, that's not the case for HotSpot. >> >> So finally my question: is there any real reason (except the >> fact that >> "we always did it that way") why we would still need to use export >> maps on Linux where symbol hiding is done with >> -fvisibility=hidden/____attribute__((visibility("__default"))) >> >> anyway? >> Dropping the maps would make the maintenance of exported symbols >> easier as we wouldn't have to keep the export map files and the >> JNIEXPORT functions in sync. >> >> >> From past discussions isn't this because we need the map files to >> expose dynamically generated symbols? (And so we must then also add >> the other visible symbols.) Does that make the visibility attributes >> redundant? I'm not sure, but they serve as a clear statement of >> intent anyway. >> >> David >> >> >> Thank you and best regards, >> Volker >> >> [1] https://bugs.openjdk.java.net/__browse/JDK-6588413 >> >> [2] http://www.akkadia.org/__drepper/dsohowto.pdf >> >> >> > From coleen.phillimore at oracle.com Wed Feb 5 10:29:55 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Feb 2014 13:29:55 -0500 Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) In-Reply-To: <017201cf229a$70ecf880$52c6e980$@oracle.com> References: <52F2536E.1000907@oracle.com> <017201cf229a$70ecf880$52c6e980$@oracle.com> Message-ID: <52F28323.5010601@oracle.com> Looks good. Coleen On 2/5/14 12:48 PM, Christian Tornqvist wrote: > Looks good. Thanks for fixing this. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George Triantafillou > Sent: Wednesday, February 5, 2014 10:06 AM > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) > > Please review the following fix for bug 8021774: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8021774 > Webrev: http://cr.openjdk.java.net/~gtriantafill/8021774/webrev.00/ > > > This backport fix for JDK8 is a test stabilization change. The goal of the change is to ignore warnings with -XX:NativeMemoryTracking on Solaris and Linux in order to achieve a full pass of jtreg runtime tests. > > Thank you, > George > > From george.triantafillou at oracle.com Wed Feb 5 10:52:34 2014 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 05 Feb 2014 13:52:34 -0500 Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a warning in its output (backport fix for JDK8) In-Reply-To: <52F28323.5010601@oracle.com> References: <52F2536E.1000907@oracle.com> <017201cf229a$70ecf880$52c6e980$@oracle.com> <52F28323.5010601@oracle.com> Message-ID: <52F28872.3040202@oracle.com> Thanks for the review Coleen, Christian and Harold. -George On 2/5/2014 1:29 PM, Coleen Phillimore wrote: > > Looks good. > Coleen > > On 2/5/14 12:48 PM, Christian Tornqvist wrote: >> Looks good. Thanks for fixing this. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George >> Triantafillou >> Sent: Wednesday, February 5, 2014 10:06 AM >> To: hotspot-dev at openjdk.java.net >> Subject: RFR(XS): JDK-8021774: [TESTBUG] Tests failed because of a >> warning in its output (backport fix for JDK8) >> >> Please review the following fix for bug 8021774: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8021774 >> Webrev: >> http://cr.openjdk.java.net/~gtriantafill/8021774/webrev.00/ >> >> >> This backport fix for JDK8 is a test stabilization change. The goal >> of the change is to ignore warnings with -XX:NativeMemoryTracking on >> Solaris and Linux in order to achieve a full pass of jtreg runtime >> tests. >> >> Thank you, >> George >> >> > From coleen.phillimore at oracle.com Wed Feb 5 13:18:45 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Feb 2014 16:18:45 -0500 Subject: RFR: 8032010: Attempt to resolve abstract method in concrete class fails with AbstractMethodError In-Reply-To: <52EC277B.3070605@oracle.com> References: <52EC277B.3070605@oracle.com> Message-ID: <52F2AAB5.9080000@oracle.com> This looks good. Coleen On 1/31/14 5:45 PM, Calvin Cheung wrote: > This change, by removing a check in LinkResolver::resolve_method(), is > to conform with the recent change in JVMS-8 [1]. > The following check during method resolution is removed: > JVMS-5.4.3.3. Method Resolution > "If method lookup succeeds and the method is abstract, but C is not > abstract, method resolution throws an AbstractMethodError." > > bug: https://bugs.openjdk.java.net/browse/JDK-8032010 > > webrev: http://cr.openjdk.java.net/~ccheung/8032010/webrev/ > > tests: (on linux-x64) > vm.quick > jck vm and lang > jtreg on java/util/stream and the new testcase > defmeth > jprt > > thanks, > Calvin > > [1] http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.1.html#J From calvin.cheung at oracle.com Wed Feb 5 13:25:20 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 05 Feb 2014 13:25:20 -0800 Subject: RFR: 8032010: Attempt to resolve abstract method in concrete class fails with AbstractMethodError In-Reply-To: <52F2AAB5.9080000@oracle.com> References: <52EC277B.3070605@oracle.com> <52F2AAB5.9080000@oracle.com> Message-ID: <52F2AC40.2060402@oracle.com> Thanks for your review, Coleen. Calvin On 2/5/2014 1:18 PM, Coleen Phillimore wrote: > > This looks good. > Coleen > > On 1/31/14 5:45 PM, Calvin Cheung wrote: >> This change, by removing a check in LinkResolver::resolve_method(), >> is to conform with the recent change in JVMS-8 [1]. >> The following check during method resolution is removed: >> JVMS-5.4.3.3. Method Resolution >> "If method lookup succeeds and the method is abstract, but C is not >> abstract, method resolution throws an AbstractMethodError." >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8032010 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8032010/webrev/ >> >> tests: (on linux-x64) >> vm.quick >> jck vm and lang >> jtreg on java/util/stream and the new testcase >> defmeth >> jprt >> >> thanks, >> Calvin >> >> [1] http://cr.openjdk.java.net/~dlsmith/jsr335-0.9.1.html#J > From henry.jen at oracle.com Wed Feb 5 16:56:30 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 05 Feb 2014 16:56:30 -0800 Subject: RFR: 8033289: clang: clean up unused function warning In-Reply-To: <69560981.2P6taIEG9b@mgerdin03> References: <52EAD957.7090503@oracle.com> <69560981.2P6taIEG9b@mgerdin03> Message-ID: <52F2DDBE.4070502@oracle.com> Updated as suggested using #ifdef ASSERT intead, webrev at http://cr.openjdk.java.net/~henryjen/jdk9/8033289/1/webrev/ I need two reviewers from hotspot team or jdk9 reviewers is good? Cheers, Henry On 01/31/2014 01:11 AM, Mikael Gerdin wrote: > Hi, > > On Thursday 30 January 2014 14.59.35 Henry Jen wrote: >> Hi, >> >> Please review the fix that clean up unused function warning produced by >> clang 3.4. >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/ >> >> One of those is used only in assert, so I wrapped it in #ifndef PRODUCT. > > > 2793 #ifndef PRODUCT > 2794 // Function only used in assert, which will be disabled with NDEBUG > 2795 // ??? Somehow NDEBUG is not working, use PRODUCT > > This should be #ifdef ASSERT > > Assertions in hotspot are compiled in when ASSERT is defined. It's a common > mistake to mix usage of #ifndef PRODUCT and ASSERT. > We don't use NDEBUG in hotspot, I think you can skip the comment about the > function being only used in an assert, that's quite common in the vm. > > /Mikael > > >> >> I had done a round of jprt along with other clang clean up, which passes >> all builds target. >> >> Cheers, >> Henry > From coleen.phillimore at oracle.com Wed Feb 5 17:08:49 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 05 Feb 2014 20:08:49 -0500 Subject: RFR: 8033289: clang: clean up unused function warning In-Reply-To: <52F2DDBE.4070502@oracle.com> References: <52EAD957.7090503@oracle.com> <69560981.2P6taIEG9b@mgerdin03> <52F2DDBE.4070502@oracle.com> Message-ID: <52F2E0A1.9010405@oracle.com> These changes look fine. But they should be 1. rebased to hs-rt/hotspot repository 2. hg commit with the commit message (think jdk is the same format), 3. pushed via JPRT. To do #3, you must be in the hotspot repository and push the committed changes without the -stree option. If you're not sure what to do, let me or anyone on the hotspot team know. On 2/5/14 7:56 PM, Henry Jen wrote: > Updated as suggested using #ifdef ASSERT intead, webrev at > > http://cr.openjdk.java.net/~henryjen/jdk9/8033289/1/webrev/ > > I need two reviewers from hotspot team or jdk9 reviewers is good? All the openjdk roles are merged, but since the files are hotspot files, at least 2 hotspot reviewers are required. One must be a capital R reviewer in the openjdk sense. thanks, Coleen > > Cheers, > Henry > > On 01/31/2014 01:11 AM, Mikael Gerdin wrote: >> Hi, >> >> On Thursday 30 January 2014 14.59.35 Henry Jen wrote: >>> Hi, >>> >>> Please review the fix that clean up unused function warning produced by >>> clang 3.4. >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/ >>> >>> One of those is used only in assert, so I wrapped it in #ifndef >>> PRODUCT. >> >> >> 2793 #ifndef PRODUCT >> 2794 // Function only used in assert, which will be disabled with NDEBUG >> 2795 // ??? Somehow NDEBUG is not working, use PRODUCT >> >> This should be #ifdef ASSERT >> >> Assertions in hotspot are compiled in when ASSERT is defined. It's a >> common >> mistake to mix usage of #ifndef PRODUCT and ASSERT. >> We don't use NDEBUG in hotspot, I think you can skip the comment >> about the >> function being only used in an assert, that's quite common in the vm. >> >> /Mikael >> >> >>> >>> I had done a round of jprt along with other clang clean up, which >>> passes >>> all builds target. >>> >>> Cheers, >>> Henry >> From christian.thalinger at oracle.com Wed Feb 5 20:14:01 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 5 Feb 2014 20:14:01 -0800 Subject: Error building hotspot with shark/zero In-Reply-To: <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net> Message-ID: <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: https://bugs.openjdk.java.net/browse/JDK-7071823 On Feb 5, 2014, at 7:20 AM, Neale Ferguson wrote: > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: > > Linking vm... > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' > sharedRuntime.o:(.bss+0x0): first defined here > sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' > sharedRuntime.o:(.bss+0x8): first defined here > sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' > sharedRuntime.o:(.bss+0x10): first defined here > sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' > sharedRuntime.o:(.bss+0x18): first defined here > sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' > sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so > make[6]: stat: libjvm.so: Too many levels of symbolic links > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. > > Neale > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > >> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... >> >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: >> >>> Hi, >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >>> >>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >>> >>> line 72 looks like: >>> >>> llvm::Constant* get_external(const char* name, >>> const llvm::FunctionType* sig) { >>> return module()->getOrInsertFunction(name, sig); >>> } >>> >>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >>> >>> Neale >> > From neale at sinenomine.net Wed Feb 5 20:30:23 2014 From: neale at sinenomine.net (Neale Ferguson) Date: Thu, 6 Feb 2014 04:30:23 +0000 Subject: Error building hotspot with shark/zero In-Reply-To: <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net>, <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> Message-ID: I simply followed the instructions and did a hg clone and then used the get_source script to populate everything. I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script. -------- Original message -------- From: Christian Thalinger Date:2014/02/05 23:14 (GMT-05:00) To: Neale Ferguson Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: https://bugs.openjdk.java.net/browse/JDK-7071823 On Feb 5, 2014, at 7:20 AM, Neale Ferguson wrote: > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: > > Linking vm... > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' > sharedRuntime.o:(.bss+0x0): first defined here > sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' > sharedRuntime.o:(.bss+0x8): first defined here > sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' > sharedRuntime.o:(.bss+0x10): first defined here > sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' > sharedRuntime.o:(.bss+0x18): first defined here > sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' > sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so > make[6]: stat: libjvm.so: Too many levels of symbolic links > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. > > Neale > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > >> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... >> >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: >> >>> Hi, >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >>> >>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >>> >>> line 72 looks like: >>> >>> llvm::Constant* get_external(const char* name, >>> const llvm::FunctionType* sig) { >>> return module()->getOrInsertFunction(name, sig); >>> } >>> >>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >>> >>> Neale >> > From david.holmes at oracle.com Wed Feb 5 21:10:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Feb 2014 15:10:54 +1000 Subject: RFR: 8033289: clang: clean up unused function warning In-Reply-To: <52F2E0A1.9010405@oracle.com> References: <52EAD957.7090503@oracle.com> <69560981.2P6taIEG9b@mgerdin03> <52F2DDBE.4070502@oracle.com> <52F2E0A1.9010405@oracle.com> Message-ID: <52F3195E.5080907@oracle.com> Henry, On 6/02/2014 11:08 AM, Coleen Phillimore wrote: > > These changes look fine. You can count me as second Reviewer. David > But they should be 1. rebased to hs-rt/hotspot > repository 2. hg commit with the commit message (think jdk is the same > format), 3. pushed via JPRT. To do #3, you must be in the hotspot > repository and push the committed changes without the -stree option. > > If you're not sure what to do, let me or anyone on the hotspot team know. > On 2/5/14 7:56 PM, Henry Jen wrote: >> Updated as suggested using #ifdef ASSERT intead, webrev at >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/1/webrev/ >> >> I need two reviewers from hotspot team or jdk9 reviewers is good? > > All the openjdk roles are merged, but since the files are hotspot files, > at least 2 hotspot reviewers are required. One must be a capital R > reviewer in the openjdk sense. > > thanks, > Coleen > >> >> Cheers, >> Henry >> >> On 01/31/2014 01:11 AM, Mikael Gerdin wrote: >>> Hi, >>> >>> On Thursday 30 January 2014 14.59.35 Henry Jen wrote: >>>> Hi, >>>> >>>> Please review the fix that clean up unused function warning produced by >>>> clang 3.4. >>>> >>>> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/ >>>> >>>> One of those is used only in assert, so I wrapped it in #ifndef >>>> PRODUCT. >>> >>> >>> 2793 #ifndef PRODUCT >>> 2794 // Function only used in assert, which will be disabled with NDEBUG >>> 2795 // ??? Somehow NDEBUG is not working, use PRODUCT >>> >>> This should be #ifdef ASSERT >>> >>> Assertions in hotspot are compiled in when ASSERT is defined. It's a >>> common >>> mistake to mix usage of #ifndef PRODUCT and ASSERT. >>> We don't use NDEBUG in hotspot, I think you can skip the comment >>> about the >>> function being only used in an assert, that's quite common in the vm. >>> >>> /Mikael >>> >>> >>>> >>>> I had done a round of jprt along with other clang clean up, which >>>> passes >>>> all builds target. >>>> >>>> Cheers, >>>> Henry >>> > From henry.jen at oracle.com Wed Feb 5 21:41:58 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 05 Feb 2014 21:41:58 -0800 Subject: RFR: 8033289: clang: clean up unused function warning In-Reply-To: <52F3195E.5080907@oracle.com> References: <52EAD957.7090503@oracle.com> <69560981.2P6taIEG9b@mgerdin03> <52F2DDBE.4070502@oracle.com> <52F2E0A1.9010405@oracle.com> <52F3195E.5080907@oracle.com> Message-ID: <52F320A6.8060600@oracle.com> Great, thanks Coleen, David and Mikael for reviewing. Cheers, Henry On 02/05/2014 09:10 PM, David Holmes wrote: > Henry, > > On 6/02/2014 11:08 AM, Coleen Phillimore wrote: >> >> These changes look fine. > > You can count me as second Reviewer. > > David > >> But they should be 1. rebased to hs-rt/hotspot >> repository 2. hg commit with the commit message (think jdk is the same >> format), 3. pushed via JPRT. To do #3, you must be in the hotspot >> repository and push the committed changes without the -stree option. >> >> If you're not sure what to do, let me or anyone on the hotspot team know. > >> On 2/5/14 7:56 PM, Henry Jen wrote: >>> Updated as suggested using #ifdef ASSERT intead, webrev at >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/1/webrev/ >>> >>> I need two reviewers from hotspot team or jdk9 reviewers is good? >> >> All the openjdk roles are merged, but since the files are hotspot files, >> at least 2 hotspot reviewers are required. One must be a capital R >> reviewer in the openjdk sense. >> >> thanks, >> Coleen >> >>> >>> Cheers, >>> Henry >>> >>> On 01/31/2014 01:11 AM, Mikael Gerdin wrote: >>>> Hi, >>>> >>>> On Thursday 30 January 2014 14.59.35 Henry Jen wrote: >>>>> Hi, >>>>> >>>>> Please review the fix that clean up unused function warning >>>>> produced by >>>>> clang 3.4. >>>>> >>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8033289/webrev/ >>>>> >>>>> One of those is used only in assert, so I wrapped it in #ifndef >>>>> PRODUCT. >>>> >>>> >>>> 2793 #ifndef PRODUCT >>>> 2794 // Function only used in assert, which will be disabled with >>>> NDEBUG >>>> 2795 // ??? Somehow NDEBUG is not working, use PRODUCT >>>> >>>> This should be #ifdef ASSERT >>>> >>>> Assertions in hotspot are compiled in when ASSERT is defined. It's a >>>> common >>>> mistake to mix usage of #ifndef PRODUCT and ASSERT. >>>> We don't use NDEBUG in hotspot, I think you can skip the comment >>>> about the >>>> function being only used in an assert, that's quite common in the vm. >>>> >>>> /Mikael >>>> >>>> >>>>> >>>>> I had done a round of jprt along with other clang clean up, which >>>>> passes >>>>> all builds target. >>>>> >>>>> Cheers, >>>>> Henry >>>> >> From goetz.lindenmaier at sap.com Thu Feb 6 02:33:04 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 6 Feb 2014 10:33:04 +0000 Subject: Usage of C++ features Message-ID: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> Hi, wrt. our (SAPs) various ports which are running on old machines, built with old compilers for compatibility, I would like to find out about the OpenJDK policy regarding 'real' C++ features. Recently, we found increasing usage of C++ features. - 'throw()' in nmethod operator new - usage of namespace std:: - template template parameters in binaryTreeDictionary.hpp|cpp We would like to know whether you are planning to increase the usage of C++ or even use C++11 features. Or, whether you are planning to keep the policy to avoid C++ features that caused problems to compilers in the past. Best regards, Goetz. From david.holmes at oracle.com Thu Feb 6 03:27:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Feb 2014 21:27:51 +1000 Subject: Usage of C++ features In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> Message-ID: <52F371B7.1000401@oracle.com> Hi Goetz, On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > Hi, > > wrt. our (SAPs) various ports which are running on old machines, built > with old compilers for compatibility, I would like to find out about > the OpenJDK policy regarding 'real' C++ features. I don't think there is such a thing as "OpenJDK policy" for this. Things need to be evaluated on their merits taking into account a range of factors, including compiler compatibility issues. > Recently, we found increasing usage of C++ features. > > - 'throw()' in nmethod operator new > - usage of namespace std:: AFAICS only std::nothrow is in use, which combines with the use of throw() in numerous (most?) operator new definitions to make it clear that these don't throw any exceptions. That said the compiler folk have expressed interest in using C++ exceptions within the compiler. > - template template parameters in binaryTreeDictionary.hpp|cpp Can't comment on that. > We would like to know whether you are planning to increase the > usage of C++ or even use C++11 features. Or, whether you are planning > to keep the policy to avoid C++ features that caused problems to > compilers in the past. I can envisage usage of C++11 atomics at some point. But it depends on it being supported across sufficient compilers. What else is coming in C++11? I think everything has to be considered on a case-by-case basis. You presumably have some things in mind ? Just my 2c. I'm not a policy maker. :) Cheers, David > Best regards, > Goetz. > From mikael.gerdin at oracle.com Thu Feb 6 03:56:00 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 06 Feb 2014 12:56 +0100 Subject: Usage of C++ features In-Reply-To: <52F371B7.1000401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <52F371B7.1000401@oracle.com> Message-ID: <55670517.mQ9jZp9EHK@mgerdin03> On Thursday 06 February 2014 21.27.51 David Holmes wrote: > Hi Goetz, > > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > wrt. our (SAPs) various ports which are running on old machines, built > > with old compilers for compatibility, I would like to find out about > > the OpenJDK policy regarding 'real' C++ features. > > I don't think there is such a thing as "OpenJDK policy" for this. Things > need to be evaluated on their merits taking into account a range of > factors, including compiler compatibility issues. > > > Recently, we found increasing usage of C++ features. > > > > - 'throw()' in nmethod operator new > > > - usage of namespace std:: > AFAICS only std::nothrow is in use, which combines with the use of > throw() in numerous (most?) operator new definitions to make it clear > that these don't throw any exceptions. > > That said the compiler folk have expressed interest in using C++ > exceptions within the compiler. > > > - template template parameters in binaryTreeDictionary.hpp|cpp > > Can't comment on that. I have this lingering feeling that we shouldn't need to use template template parameters for the binaryTreeDictionary code but I haven't experimented with it. I'd prefer to simplify that just for the sake of sanity. /Mikael > > > We would like to know whether you are planning to increase the > > usage of C++ or even use C++11 features. Or, whether you are planning > > to keep the policy to avoid C++ features that caused problems to > > compilers in the past. > > I can envisage usage of C++11 atomics at some point. But it depends on > it being supported across sufficient compilers. What else is coming in > C++11? > > I think everything has to be considered on a case-by-case basis. You > presumably have some things in mind ? > > Just my 2c. I'm not a policy maker. :) > > Cheers, > David > > > Best regards, > > > > Goetz. From vitalyd at gmail.com Thu Feb 6 05:57:03 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 6 Feb 2014 08:57:03 -0500 Subject: Usage of C++ features In-Reply-To: <52F371B7.1000401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <52F371B7.1000401@oracle.com> Message-ID: C++11 has a lot of nice productivity/performance features as well; just to name a few: 1) lambdas 2) auto keyword 3) constexpr 4) move ctors 5) range based for loops 6) ctor chaining 7) final/override keywords 8) strongly typed enums 9) static assert There's more, but I could definitely see some of the above making the hotspot code more maintainable and readable (assuming compiler compatibility isn't an issue). Sent from my phone On Feb 6, 2014 6:34 AM, "David Holmes" wrote: > Hi Goetz, > > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > >> Hi, >> >> wrt. our (SAPs) various ports which are running on old machines, built >> with old compilers for compatibility, I would like to find out about >> the OpenJDK policy regarding 'real' C++ features. >> > > I don't think there is such a thing as "OpenJDK policy" for this. Things > need to be evaluated on their merits taking into account a range of > factors, including compiler compatibility issues. > > Recently, we found increasing usage of C++ features. >> >> - 'throw()' in nmethod operator new >> - usage of namespace std:: >> > > AFAICS only std::nothrow is in use, which combines with the use of throw() > in numerous (most?) operator new definitions to make it clear that these > don't throw any exceptions. > > That said the compiler folk have expressed interest in using C++ > exceptions within the compiler. > > - template template parameters in binaryTreeDictionary.hpp|cpp >> > > Can't comment on that. > > We would like to know whether you are planning to increase the >> usage of C++ or even use C++11 features. Or, whether you are planning >> to keep the policy to avoid C++ features that caused problems to >> compilers in the past. >> > > I can envisage usage of C++11 atomics at some point. But it depends on it > being supported across sufficient compilers. What else is coming in C++11? > > I think everything has to be considered on a case-by-case basis. You > presumably have some things in mind ? > > Just my 2c. I'm not a policy maker. :) > > Cheers, > David > > Best regards, >> Goetz. >> >> From igor.veresov at oracle.com Thu Feb 6 12:28:19 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 6 Feb 2014 12:28:19 -0800 Subject: Usage of C++ features In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> Message-ID: Definitely there are talks about this. More templates, exceptions, and if we?re lucky with our own set of compilers - STL. igor On Feb 6, 2014, at 2:33 AM, Lindenmaier, Goetz wrote: > Hi, > > wrt. our (SAPs) various ports which are running on old machines, built > with old compilers for compatibility, I would like to find out about > the OpenJDK policy regarding 'real' C++ features. > > Recently, we found increasing usage of C++ features. > > - 'throw()' in nmethod operator new > > - usage of namespace std:: > > - template template parameters in binaryTreeDictionary.hpp|cpp > > We would like to know whether you are planning to increase the > usage of C++ or even use C++11 features. Or, whether you are planning > to keep the policy to avoid C++ features that caused problems to > compilers in the past. > > Best regards, > Goetz. From alejandro.murillo at oracle.com Thu Feb 6 12:32:31 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 20:32:31 +0000 Subject: hg: hsx/jdk7u: 35 new changesets Message-ID: <20140206203232.6AF2A62A8E@hg.openjdk.java.net> Changeset: 2dc0faccfa1e Author: asaha Date: 2013-09-11 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/2dc0faccfa1e Merge ! .hgtags Changeset: 0c5ae7837ff5 Author: asaha Date: 2013-09-18 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/0c5ae7837ff5 Merge ! .hgtags Changeset: bdcd50ab61e5 Author: asaha Date: 2013-09-18 11:27 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/bdcd50ab61e5 Merge ! .hgtags Changeset: cc9a05c9ad5c Author: asaha Date: 2013-09-19 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/cc9a05c9ad5c Merge ! .hgtags Changeset: df2784aa1ab9 Author: asaha Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/df2784aa1ab9 Merge ! .hgtags Changeset: 7fd771847022 Author: asaha Date: 2013-09-26 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/7fd771847022 Merge ! .hgtags Changeset: 6a8e3930abcc Author: asaha Date: 2013-09-27 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/6a8e3930abcc Merge ! .hgtags Changeset: 8bc059902950 Author: asaha Date: 2013-09-27 13:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/8bc059902950 Merge ! .hgtags Changeset: 8f67f7a072c2 Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/8f67f7a072c2 Added tag jdk7u51-b00 for changeset f2479abad143 ! .hgtags Changeset: c5822e1d1baa Author: asaha Date: 2013-09-30 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/c5822e1d1baa Merge ! .hgtags Changeset: a9d80d729eb2 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a9d80d729eb2 Added tag jdk7u51-b01 for changeset c5822e1d1baa ! .hgtags Changeset: f019ffa367c2 Author: asaha Date: 2013-10-08 11:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f019ffa367c2 Merge ! .hgtags Changeset: f750621fb31b Author: asaha Date: 2013-10-09 09:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/f750621fb31b Merge ! .hgtags Changeset: dafd6c301c97 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/dafd6c301c97 Added tag jdk7u51-b02 for changeset f750621fb31b ! .hgtags Changeset: 8bc2f477bba4 Author: cl Date: 2013-10-15 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/8bc2f477bba4 Added tag jdk7u51-b03 for changeset dafd6c301c97 ! .hgtags Changeset: 1604b330bf96 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/1604b330bf96 Added tag jdk7u51-b04 for changeset 8bc2f477bba4 ! .hgtags Changeset: 15c531ebb19c Author: cl Date: 2013-10-29 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/15c531ebb19c Added tag jdk7u51-b05 for changeset 1604b330bf96 ! .hgtags Changeset: 75f0610e93bf Author: cl Date: 2013-11-05 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/75f0610e93bf Added tag jdk7u51-b06 for changeset 15c531ebb19c ! .hgtags Changeset: 467fc49c32dd Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/467fc49c32dd Added tag jdk7u51-b07 for changeset 75f0610e93bf ! .hgtags Changeset: 73ebe4e4f20e Author: cl Date: 2013-11-19 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/73ebe4e4f20e Added tag jdk7u51-b08 for changeset 467fc49c32dd ! .hgtags Changeset: 9868efbea429 Author: asaha Date: 2013-11-27 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/9868efbea429 Added tag jdk7u51-b09 for changeset 73ebe4e4f20e ! .hgtags Changeset: 573c4cfca7dd Author: katleman Date: 2013-12-04 10:10 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/573c4cfca7dd Added tag jdk7u51-b10 for changeset 9868efbea429 ! .hgtags Changeset: df53ec7eb789 Author: katleman Date: 2013-12-10 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/df53ec7eb789 Added tag jdk7u51-b11 for changeset 573c4cfca7dd ! .hgtags Changeset: 6c778574d873 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/6c778574d873 Added tag jdk7u51-b12 for changeset df53ec7eb789 ! .hgtags Changeset: 05742477836c Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/05742477836c Added tag jdk7u45-b33 for changeset b73c006b5d81 ! .hgtags Changeset: d0d5badd77ab Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/d0d5badd77ab Added tag jdk7u45-b34 for changeset 05742477836c ! .hgtags Changeset: 8a0fb2a53d19 Author: asaha Date: 2013-12-17 10:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/8a0fb2a53d19 Merge ! .hgtags Changeset: d2eeac0235ed Author: katleman Date: 2013-12-19 09:00 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/d2eeac0235ed Added tag jdk7u51-b13 for changeset 6c778574d873 ! .hgtags Changeset: 626e76f127a4 Author: asaha Date: 2013-12-19 09:31 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/626e76f127a4 Merge ! .hgtags Changeset: a831c212ee26 Author: katleman Date: 2013-12-20 18:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/a831c212ee26 Added tag jdk7u51-b31 for changeset 626e76f127a4 ! .hgtags Changeset: 162bb2b05002 Author: katleman Date: 2013-12-26 13:04 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/162bb2b05002 Added tag jdk7u51-b30 for changeset d2eeac0235ed ! .hgtags Changeset: b5ea303f23a5 Author: asaha Date: 2013-12-31 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/b5ea303f23a5 Merge ! .hgtags Changeset: 87f2193da40d Author: asaha Date: 2013-12-31 09:38 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/87f2193da40d Merge ! .hgtags Changeset: d4397128f8b6 Author: katleman Date: 2014-01-16 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/d4397128f8b6 Added tag jdk7u60-b03 for changeset 87f2193da40d ! .hgtags Changeset: ea798405286d Author: katleman Date: 2014-01-22 12:33 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/rev/ea798405286d Added tag jdk7u60-b04 for changeset d4397128f8b6 ! .hgtags From alejandro.murillo at oracle.com Thu Feb 6 12:32:50 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 20:32:50 +0000 Subject: hg: hsx/jdk7u/corba: 48 new changesets Message-ID: <20140206203328.C8FBD62A8F@hg.openjdk.java.net> Changeset: 59d790829419 Author: asaha Date: 2013-09-11 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/59d790829419 Merge ! .hgtags Changeset: 3832ff63e7fc Author: asaha Date: 2013-09-18 11:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3832ff63e7fc Merge ! .hgtags Changeset: 3092a6420d0d Author: asaha Date: 2013-09-18 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3092a6420d0d Merge ! .hgtags Changeset: e379f8068ea6 Author: asaha Date: 2013-09-19 15:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/e379f8068ea6 Merge ! .hgtags Changeset: 694aaf53fcc2 Author: asaha Date: 2013-09-24 10:52 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/694aaf53fcc2 Merge ! .hgtags Changeset: 0540b0b57ce4 Author: asaha Date: 2013-09-26 11:22 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/0540b0b57ce4 Merge ! .hgtags Changeset: fd88b48792ce Author: asaha Date: 2013-09-27 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/fd88b48792ce Merge ! .hgtags Changeset: bdd1f5afad32 Author: asaha Date: 2013-09-27 13:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/bdd1f5afad32 Merge ! .hgtags Changeset: 419d784bf801 Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/419d784bf801 Added tag jdk7u51-b00 for changeset b1f069eb48ed ! .hgtags Changeset: 8d884cf2e8cc Author: asaha Date: 2013-09-30 11:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8d884cf2e8cc Merge ! .hgtags Changeset: 8ce0ac5270b8 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8ce0ac5270b8 Added tag jdk7u51-b01 for changeset 8d884cf2e8cc ! .hgtags Changeset: d927facb63bc Author: asaha Date: 2013-10-08 11:42 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/d927facb63bc Merge ! .hgtags Changeset: 327035fbb043 Author: asaha Date: 2013-10-09 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/327035fbb043 Merge ! .hgtags Changeset: 3c186a6d2b86 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3c186a6d2b86 Added tag jdk7u51-b02 for changeset 327035fbb043 ! .hgtags Changeset: 6969598640b2 Author: cl Date: 2013-10-15 09:31 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/6969598640b2 Added tag jdk7u51-b03 for changeset 3c186a6d2b86 ! .hgtags Changeset: b18c17608d94 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b18c17608d94 Added tag jdk7u51-b04 for changeset 6969598640b2 ! .hgtags Changeset: 1c997cdaf0f8 Author: cl Date: 2013-10-29 09:08 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/1c997cdaf0f8 Added tag jdk7u51-b05 for changeset b18c17608d94 ! .hgtags Changeset: d39d92c2cab1 Author: alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/d39d92c2cab1 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oralce.com, mark.sheppard at oracle.com ! src/share/classes/javax/rmi/CORBA/Stub.java ! src/share/classes/javax/rmi/CORBA/Util.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java Changeset: 863d69d3dee0 Author: asaha Date: 2013-11-04 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/863d69d3dee0 Merge Changeset: 8f9d49f7e74c Author: cl Date: 2013-11-05 10:57 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8f9d49f7e74c Added tag jdk7u51-b06 for changeset 863d69d3dee0 ! .hgtags Changeset: 77d13acb85bf Author: asaha Date: 2013-10-29 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/77d13acb85bf Merge Changeset: b1548473f261 Author: msheppar Date: 2013-11-02 01:07 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/b1548473f261 8026193: Enhance CORBA stub factories Summary: modify com.sun.corba.se.impl.presenetation.rmi.StubFactoryDynamicBase inheritance structure. Reviewed-by: alanb, coffeys, ahgross ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryFactoryProxyImpl.java Changeset: 0a879f00b698 Author: msheppar Date: 2013-11-02 01:24 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/0a879f00b698 8025767: Enhance IIOP Streams Summary: modify org.omg.CORBA_2_3.portable.InputStream inheritance structure. Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/EncapsOutputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeInputStream.java ! src/share/classes/com/sun/corba/se/impl/encoding/TypeCodeOutputStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/CDREncapsCodec.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/InputStreamHook.java ! src/share/classes/com/sun/corba/se/impl/ior/EncapsulationUtility.java ! src/share/classes/com/sun/corba/se/impl/ior/ObjectKeyFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/ior/iiop/IIOPProfileImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/SharedCDRClientRequestDispatcherImpl.java ! src/share/classes/com/sun/corba/se/impl/resolver/INSURLOperationImpl.java ! src/share/classes/com/sun/corba/se/spi/servicecontext/ServiceContexts.java ! src/share/classes/org/omg/CORBA_2_3/portable/InputStream.java + src/share/classes/sun/corba/EncapsInputStreamFactory.java Changeset: 880cc2c3ba33 Author: asaha Date: 2013-11-05 12:03 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/880cc2c3ba33 Merge Changeset: 3910fba40bac Author: mfang Date: 2013-11-07 12:16 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3910fba40bac 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/share/classes/com/sun/tools/corba/se/idl/idl_ja.prp Changeset: 4baf8650e2c5 Author: mfang Date: 2013-11-07 12:50 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/4baf8650e2c5 Merge Changeset: 3f6dfcad33ac Author: coffeys Date: 2013-11-11 15:52 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3f6dfcad33ac 8027837: JDK-8021257 causes CORBA build failure on emdedded platforms Reviewed-by: dholmes ! make/Makefile Changeset: 652dbc49eb47 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/652dbc49eb47 Added tag jdk7u51-b07 for changeset 3f6dfcad33ac ! .hgtags Changeset: 8ce01c9da345 Author: mchung Date: 2013-11-07 20:48 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/8ce01c9da345 8027943: serial version of com.sun.corba.se.spi.orbutil.proxy.CompositeInvocationHandlerImpl changed in 7u45 Reviewed-by: msheppar, alanb, lancea ! src/share/classes/com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.java Changeset: 2ef8307ce38d Author: coffeys Date: 2013-11-11 15:52 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/2ef8307ce38d 8027837: JDK-8021257 causes CORBA build failure on emdedded platforms Reviewed-by: dholmes ! make/Makefile Changeset: 00c7d4007a2f Author: asaha Date: 2013-11-12 09:10 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/00c7d4007a2f Merge Changeset: 07177000db8f Author: cl Date: 2013-11-19 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/07177000db8f Added tag jdk7u51-b08 for changeset 00c7d4007a2f ! .hgtags Changeset: bb45667f58f5 Author: msheppar Date: 2013-11-24 13:09 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/bb45667f58f5 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung ! src/share/classes/org/omg/CORBA/ORB.java Changeset: eecfc296009b Author: asaha Date: 2013-11-27 08:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/eecfc296009b Added tag jdk7u51-b09 for changeset bb45667f58f5 ! .hgtags Changeset: a26d0e8ab102 Author: katleman Date: 2013-12-04 10:10 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/a26d0e8ab102 Added tag jdk7u51-b10 for changeset eecfc296009b ! .hgtags Changeset: 55a509ccc0e4 Author: katleman Date: 2013-12-10 13:15 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/55a509ccc0e4 Added tag jdk7u51-b11 for changeset a26d0e8ab102 ! .hgtags Changeset: e2f0036f712a Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/e2f0036f712a Added tag jdk7u51-b12 for changeset 55a509ccc0e4 ! .hgtags Changeset: aa24e046a2da Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/aa24e046a2da Added tag jdk7u45-b33 for changeset d641ac83157e ! .hgtags Changeset: fab1423e6ab8 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/fab1423e6ab8 Added tag jdk7u45-b34 for changeset aa24e046a2da ! .hgtags Changeset: bdfd3d51d3c9 Author: asaha Date: 2013-12-17 11:01 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/bdfd3d51d3c9 Merge ! .hgtags Changeset: 6563d12c48c9 Author: katleman Date: 2013-12-19 09:00 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/6563d12c48c9 Added tag jdk7u51-b13 for changeset e2f0036f712a ! .hgtags Changeset: 0ad990211737 Author: asaha Date: 2013-12-19 09:31 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/0ad990211737 Merge ! .hgtags Changeset: 171d49504c82 Author: katleman Date: 2013-12-20 18:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/171d49504c82 Added tag jdk7u51-b31 for changeset 0ad990211737 ! .hgtags Changeset: 00401b8a35fc Author: katleman Date: 2013-12-26 13:04 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/00401b8a35fc Added tag jdk7u51-b30 for changeset 6563d12c48c9 ! .hgtags Changeset: 62e0191837ed Author: asaha Date: 2013-12-31 08:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/62e0191837ed Merge ! .hgtags Changeset: d7e98ed925a3 Author: asaha Date: 2013-12-31 09:42 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/d7e98ed925a3 Merge ! .hgtags Changeset: 1a3aa4637b80 Author: katleman Date: 2014-01-16 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/1a3aa4637b80 Added tag jdk7u60-b03 for changeset d7e98ed925a3 ! .hgtags Changeset: 753698a91016 Author: katleman Date: 2014-01-22 12:33 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/753698a91016 Added tag jdk7u60-b04 for changeset 1a3aa4637b80 ! .hgtags From alejandro.murillo at oracle.com Thu Feb 6 12:33:51 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 20:33:51 +0000 Subject: hg: hsx/jdk7u/jaxp: 46 new changesets Message-ID: <20140206203505.A491162A90@hg.openjdk.java.net> Changeset: d439603c2c1d Author: joehw Date: 2013-08-26 20:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/d439603c2c1d 8022935: Enhance Apache resolver classes Reviewed-by: alanb, mchung, skoivu ! src/com/sun/org/apache/xml/internal/resolver/CatalogManager.java ! src/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java Changeset: 821f4884bf5a Author: asaha Date: 2013-08-27 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/821f4884bf5a Merge Changeset: b58b3eebb5d9 Author: asaha Date: 2013-09-04 12:28 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/b58b3eebb5d9 Merge Changeset: 71670df6abf8 Author: asaha Date: 2013-09-11 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/71670df6abf8 Merge Changeset: a21c2865342f Author: asaha Date: 2013-09-12 08:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/a21c2865342f Merge ! .hgtags Changeset: b5cd020bcc60 Author: asaha Date: 2013-09-18 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/b5cd020bcc60 Merge ! .hgtags Changeset: ed11b0eb4ce8 Author: asaha Date: 2013-09-18 11:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/ed11b0eb4ce8 Merge ! .hgtags Changeset: 1c4467ab7019 Author: asaha Date: 2013-09-19 15:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/1c4467ab7019 Merge ! .hgtags Changeset: ae069ad1324d Author: asaha Date: 2013-09-24 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/ae069ad1324d Merge ! .hgtags Changeset: 47eb61009d86 Author: asaha Date: 2013-09-26 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/47eb61009d86 Merge ! .hgtags Changeset: 0af40df02030 Author: asaha Date: 2013-09-27 12:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0af40df02030 Merge ! .hgtags Changeset: 3a348ded5559 Author: asaha Date: 2013-09-27 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/3a348ded5559 Merge ! .hgtags Changeset: 07fa2d34974d Author: asaha Date: 2013-09-30 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/07fa2d34974d Added tag jdk7u51-b00 for changeset 0a8b95184728 ! .hgtags Changeset: 2450ace952f4 Author: asaha Date: 2013-09-30 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/2450ace952f4 Merge ! .hgtags Changeset: f3bdb445348f Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/f3bdb445348f Added tag jdk7u51-b01 for changeset 2450ace952f4 ! .hgtags Changeset: 7a6fa252ff6f Author: asaha Date: 2013-10-08 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7a6fa252ff6f Merge ! .hgtags Changeset: 68def851cc6b Author: asaha Date: 2013-10-09 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/68def851cc6b Merge ! .hgtags Changeset: 0df316a3b311 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0df316a3b311 Added tag jdk7u51-b02 for changeset 68def851cc6b ! .hgtags Changeset: 1f0996368d6e Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/1f0996368d6e Added tag jdk7u51-b03 for changeset 0df316a3b311 ! .hgtags Changeset: 42be8e6266ab Author: joehw Date: 2013-10-22 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/42be8e6266ab 8025018: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, ahgross ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 0655a95d1609 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/0655a95d1609 Added tag jdk7u51-b04 for changeset 42be8e6266ab ! .hgtags Changeset: 13a15fc9b6bf Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/13a15fc9b6bf Added tag jdk7u51-b05 for changeset 0655a95d1609 ! .hgtags Changeset: bbbfbe6d0a9f Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/bbbfbe6d0a9f Added tag jdk7u51-b06 for changeset 13a15fc9b6bf ! .hgtags Changeset: 9736e845a3c1 Author: mfang Date: 2013-11-07 12:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/9736e845a3c1 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties Changeset: 8e4523e579bf Author: mfang Date: 2013-11-07 12:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/8e4523e579bf Merge Changeset: b38271b28253 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/b38271b28253 Added tag jdk7u51-b07 for changeset 8e4523e579bf ! .hgtags Changeset: 783ceae9b736 Author: joehw Date: 2013-11-14 09:47 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/783ceae9b736 8027201: Enhance JAX-P set up Reviewed-by: alanb, dfuchs, lancea, hawtin ! src/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java ! src/com/sun/org/apache/xalan/internal/lib/Extensions.java Changeset: 7875c882a751 Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7875c882a751 Added tag jdk7u51-b08 for changeset 783ceae9b736 ! .hgtags Changeset: 8c288622817f Author: asaha Date: 2013-11-27 08:21 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/8c288622817f Added tag jdk7u51-b09 for changeset 7875c882a751 ! .hgtags Changeset: 394a207d1250 Author: coffeys Date: 2013-11-21 19:36 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/394a207d1250 8028111: XML readers share the same entity expansion counter Reviewed-by: joehw, robm ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java Changeset: 55e8ea7085b7 Author: coffeys Date: 2013-11-26 19:33 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/55e8ea7085b7 8029038: Revise fix for XML readers share the same entity expansion counter Reviewed-by: joehw, mbankal ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/XMLParser.java ! src/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 65798d05674d Author: asaha Date: 2013-11-27 11:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/65798d05674d Merge Changeset: 70b5691c44d2 Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/70b5691c44d2 Added tag jdk7u51-b10 for changeset 65798d05674d ! .hgtags Changeset: 807946db29f4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/807946db29f4 Added tag jdk7u51-b11 for changeset 70b5691c44d2 ! .hgtags Changeset: 114654a331e2 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/114654a331e2 Added tag jdk7u51-b12 for changeset 807946db29f4 ! .hgtags Changeset: b5a83862ed2a Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/b5a83862ed2a Added tag jdk7u45-b33 for changeset 056494e83d15 ! .hgtags Changeset: 7fda9b300e07 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7fda9b300e07 Added tag jdk7u45-b34 for changeset b5a83862ed2a ! .hgtags Changeset: 57466a32e645 Author: asaha Date: 2013-12-17 11:12 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/57466a32e645 Merge ! .hgtags Changeset: 3161567adae9 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/3161567adae9 Added tag jdk7u51-b13 for changeset 114654a331e2 ! .hgtags Changeset: e85ee81daec2 Author: asaha Date: 2013-12-19 09:33 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/e85ee81daec2 Merge ! .hgtags Changeset: de5d093cca22 Author: katleman Date: 2013-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/de5d093cca22 Added tag jdk7u51-b31 for changeset e85ee81daec2 ! .hgtags Changeset: 47e89524451d Author: katleman Date: 2013-12-26 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/47e89524451d Added tag jdk7u51-b30 for changeset 3161567adae9 ! .hgtags Changeset: 5d1c151c6931 Author: asaha Date: 2013-12-31 08:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/5d1c151c6931 Merge ! .hgtags Changeset: 359b79d99538 Author: asaha Date: 2014-01-02 09:44 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/359b79d99538 Merge ! .hgtags Changeset: 7215972c2c30 Author: katleman Date: 2014-01-16 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/7215972c2c30 Added tag jdk7u60-b03 for changeset 359b79d99538 ! .hgtags Changeset: 673ea3822e59 Author: katleman Date: 2014-01-22 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxp/rev/673ea3822e59 Added tag jdk7u60-b04 for changeset 7215972c2c30 ! .hgtags From alejandro.murillo at oracle.com Thu Feb 6 12:35:18 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 20:35:18 +0000 Subject: hg: hsx/jdk7u/jaxws: 42 new changesets Message-ID: <20140206203646.9AC0C62A91@hg.openjdk.java.net> Changeset: 39ff85cc715a Author: asaha Date: 2013-09-12 08:10 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/39ff85cc715a Merge ! .hgtags Changeset: 59955e1a7dd9 Author: asaha Date: 2013-09-18 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/59955e1a7dd9 Merge ! .hgtags Changeset: e08f65847031 Author: asaha Date: 2013-09-18 11:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/e08f65847031 Merge ! .hgtags Changeset: abc0a1824ac1 Author: asaha Date: 2013-09-19 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/abc0a1824ac1 Merge ! .hgtags Changeset: f872a2c20c73 Author: asaha Date: 2013-09-24 10:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f872a2c20c73 Merge ! .hgtags Changeset: c89fb333a433 Author: asaha Date: 2013-09-26 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c89fb333a433 Merge ! .hgtags Changeset: 789accb40535 Author: asaha Date: 2013-09-27 12:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/789accb40535 Merge ! .hgtags Changeset: 633d2b660dc7 Author: asaha Date: 2013-09-27 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/633d2b660dc7 Merge ! .hgtags Changeset: abb36d7905e1 Author: asaha Date: 2013-09-30 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/abb36d7905e1 Added tag jdk7u51-b00 for changeset 5524cced32d3 ! .hgtags Changeset: db9e3328f393 Author: asaha Date: 2013-09-30 11:14 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/db9e3328f393 Merge ! .hgtags Changeset: 37c05268d345 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/37c05268d345 Added tag jdk7u51-b01 for changeset db9e3328f393 ! .hgtags Changeset: 33b208594508 Author: asaha Date: 2013-10-08 11:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/33b208594508 Merge ! .hgtags Changeset: 92a4787cb361 Author: asaha Date: 2013-10-09 09:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/92a4787cb361 Merge ! .hgtags Changeset: 2240523feb96 Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/2240523feb96 Added tag jdk7u51-b02 for changeset 92a4787cb361 ! .hgtags Changeset: 50eb8741c48b Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/50eb8741c48b Added tag jdk7u51-b03 for changeset 2240523feb96 ! .hgtags Changeset: d2c4d2c9fc71 Author: mkos Date: 2013-10-16 10:23 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d2c4d2c9fc71 8010935: Better XML handling Reviewed-by: mchung, mgrebac, mullan ! src/share/jaxws_classes/com/sun/tools/internal/jxc/model/nav/APTNavigator.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/EagerNType.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/TypeReference.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeAnyTypeImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeModelBuilder.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeTypeInfoSetImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/Navigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeTypeInfoSet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/ElementBeanInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/JAXBContextImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/ArrayProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/SingleMapNodeProperty.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Lister.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/TransducedAccessor.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/RuntimeModeler.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/model/WrapperBeanGenerator.java Changeset: 74ebb62c1324 Author: mullan Date: 2013-10-16 10:26 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/74ebb62c1324 Merge Changeset: c4f7cc35e47a Author: mullan Date: 2013-10-17 17:37 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c4f7cc35e47a 8026826: JDK 7 fix for 8010935 broke the build Reviewed-by: prr + src/share/jaxws_classes/com/sun/tools/internal/xjc/model/nav/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/api/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/property/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/Utils.java + src/share/jaxws_classes/com/sun/xml/internal/ws/model/Utils.java Changeset: f8f0617c0310 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f8f0617c0310 Added tag jdk7u51-b04 for changeset c4f7cc35e47a ! .hgtags Changeset: 49fc29e8890c Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/49fc29e8890c Added tag jdk7u51-b05 for changeset f8f0617c0310 ! .hgtags Changeset: f6dd9063f3b3 Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f6dd9063f3b3 Added tag jdk7u51-b06 for changeset 49fc29e8890c ! .hgtags Changeset: b0ef08d5e517 Author: mkos Date: 2013-11-08 20:15 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/b0ef08d5e517 8027224: test regression - ClassNotFoundException Summary: test regression; fix also reviewed by Filipp Zkinkin, Iaroslav Savytskyi, Alexander Fomin Reviewed-by: mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: c3a650bee848 Author: mkos Date: 2013-11-09 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c3a650bee848 8028090: reverting change - changeset pushed with incorrect commit message, linked to wrong issue Reviewed-by: asaha ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: da128632f015 Author: mkos Date: 2013-11-09 10:19 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/da128632f015 8027378: Two closed/javax/xml/8005432 fails with jdk7u51b04 Summary: test regression; fix also reviewed by Maxim Soloviev, Alexander Fomin Reviewed-by: mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/fault/SOAPFaultBuilder.java Changeset: 71a314d55844 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/71a314d55844 Added tag jdk7u51-b07 for changeset da128632f015 ! .hgtags Changeset: 1d160e2b9f7b Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/1d160e2b9f7b Added tag jdk7u51-b08 for changeset 71a314d55844 ! .hgtags Changeset: 3b53d5ea0aec Author: mkos Date: 2013-11-21 11:15 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/3b53d5ea0aec 8028382: Two javax/xml/8005433 tests still fail after the fix JDK-8028147 Summary: test regression; fix also reviewed by Iaroslav Savytskyi, Alexander Fomin Reviewed-by: mchung ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/nav/ReflectionNavigator.java Changeset: 53a566a724e5 Author: asaha Date: 2013-11-27 08:22 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/53a566a724e5 Added tag jdk7u51-b09 for changeset 3b53d5ea0aec ! .hgtags Changeset: 708507f4795c Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/708507f4795c Added tag jdk7u51-b10 for changeset 53a566a724e5 ! .hgtags Changeset: 7c7c2ea4b680 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/7c7c2ea4b680 Added tag jdk7u51-b11 for changeset 708507f4795c ! .hgtags Changeset: 81a1b110f70c Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/81a1b110f70c Added tag jdk7u51-b12 for changeset 7c7c2ea4b680 ! .hgtags Changeset: e7df5d6b23c6 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/e7df5d6b23c6 Added tag jdk7u45-b33 for changeset e040abab3625 ! .hgtags Changeset: c654ba4b2392 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/c654ba4b2392 Added tag jdk7u45-b34 for changeset e7df5d6b23c6 ! .hgtags Changeset: 6f9e7eece4ff Author: asaha Date: 2013-12-17 11:13 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/6f9e7eece4ff Merge ! .hgtags Changeset: 5dbeb9983f10 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/5dbeb9983f10 Added tag jdk7u51-b13 for changeset 81a1b110f70c ! .hgtags Changeset: eb79f394916e Author: asaha Date: 2013-12-19 09:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/eb79f394916e Merge ! .hgtags Changeset: d7a922b0feda Author: katleman Date: 2013-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d7a922b0feda Added tag jdk7u51-b31 for changeset eb79f394916e ! .hgtags Changeset: 914783f40149 Author: katleman Date: 2013-12-26 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/914783f40149 Added tag jdk7u51-b30 for changeset 5dbeb9983f10 ! .hgtags Changeset: f660bfe052d9 Author: asaha Date: 2013-12-31 08:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/f660bfe052d9 Merge ! .hgtags Changeset: d4ba4e1ed3ec Author: asaha Date: 2014-01-02 09:45 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/d4ba4e1ed3ec Merge ! .hgtags ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/ModelBuilder.java Changeset: bef313c7ff7a Author: katleman Date: 2014-01-16 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/bef313c7ff7a Added tag jdk7u60-b03 for changeset d4ba4e1ed3ec ! .hgtags Changeset: 30afd3e2e704 Author: katleman Date: 2014-01-22 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jaxws/rev/30afd3e2e704 Added tag jdk7u60-b04 for changeset bef313c7ff7a ! .hgtags From alejandro.murillo at oracle.com Thu Feb 6 12:37:53 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 20:37:53 +0000 Subject: hg: hsx/jdk7u/jdk: 97 new changesets Message-ID: <20140206205554.9437162A92@hg.openjdk.java.net> Changeset: 050746671449 Author: lancea Date: 2013-08-15 11:46 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/050746671449 8022904: Enhance JDBC Parsers Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: d6d233ee9422 Author: weijun Date: 2013-08-17 06:51 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d6d233ee9422 8022931: Enhance Kerberos exceptions Reviewed-by: xuelei, ahgross ! src/share/classes/javax/security/auth/kerberos/KeyTab.java Changeset: c0ff56eaaa96 Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c0ff56eaaa96 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java Changeset: 4b7df9a8efc3 Author: weijun Date: 2013-08-19 22:43 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4b7df9a8efc3 8022945: Enhance JNDI implementation classes Reviewed-by: xuelei, ahgross, skoivu ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: f43bc2c60d21 Author: erikj Date: 2013-08-19 17:51 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f43bc2c60d21 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/bridge/Jabswitch/Makefile Changeset: 9305237ab3d4 Author: asaha Date: 2013-08-20 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9305237ab3d4 Merge Changeset: c7cf5b83f7dd Author: valeriep Date: 2013-08-21 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c7cf5b83f7dd 8022927: Input validation for byte/endian conversions Summary: Add additional boundary checks Reviewed-by: ascarpino ! src/share/classes/sun/security/provider/ByteArrayAccess.java Changeset: 3d00b699d5d2 Author: asaha Date: 2013-08-22 08:54 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3d00b699d5d2 Merge Changeset: 995b32f013f5 Author: malenkov Date: 2013-09-02 16:56 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/995b32f013f5 8023245: Enhance Beans decoding Reviewed-by: art, skoivu, alanb ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: fd6170becf78 Author: asaha Date: 2013-08-27 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/fd6170becf78 Merge Changeset: ddd59bc77e60 Author: asaha Date: 2013-09-04 08:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ddd59bc77e60 Merge Changeset: 30e41fbd2e24 Author: asaha Date: 2013-09-04 12:29 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/30e41fbd2e24 Merge Changeset: d533e96c7acc Author: xuelei Date: 2013-09-05 18:17 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d533e96c7acc 8023069: Enhance TLS connections Summary: Also reviewed by Alexander Fomin and Andrew Gross Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java ! src/share/classes/sun/security/rsa/RSAPadding.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 1b998b8306b9 Author: sherman Date: 2013-09-10 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1b998b8306b9 8022868: missing codepage Cp290 at java runtime Summary: to add cp290 and cp300 Reviewed-by: alanb, coffeys + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map ! make/tools/CharsetMapping/extsbcs ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/IBM300.java Changeset: eac032b93d19 Author: asaha Date: 2013-09-11 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/eac032b93d19 Merge Changeset: a5a90a118ce0 Author: asaha Date: 2013-09-12 08:11 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a5a90a118ce0 Merge ! .hgtags Changeset: 41dc340af6aa Author: sherman Date: 2013-09-12 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/41dc340af6aa 8024668: api/java_nio/charset/Charset/index.html#Methods JCK-runtime test fails with 7u45 b11 Summary: to add IBM290 into make/sun/nio/cs/FILES_java.gmk Reviewed-by: alanb, coffeys ! make/sun/nio/cs/FILES_java.gmk Changeset: abe1cb2d27cb Author: weijun Date: 2013-09-13 15:17 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/abe1cb2d27cb 8024306: Enhance Subject consistency Summary: Also reviewed by Alexander Fomin Reviewed-by: mullan, ahgross ! src/share/classes/javax/security/auth/Subject.java Changeset: d5f36e1c927e Author: weijun Date: 2013-09-13 15:22 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d5f36e1c927e 8023672: Enhance jar file validation Summary: Also reviewed by Chris Ries and Alexander Fomin Reviewed-by: mullan, sherman ! src/share/classes/java/util/jar/JarVerifier.java Changeset: 1a975041e36e Author: vadim Date: 2013-09-13 12:52 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1a975041e36e 8023057: Enhance start up image display Reviewed-by: anthony, serb, mschoene ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m ! src/share/native/sun/awt/splashscreen/splashscreen_impl.c ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: f4737bbf6ca7 Author: bae Date: 2013-09-13 19:19 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f4737bbf6ca7 8024697: Fix for 8020983 causes Xcheck:jni warnings Reviewed-by: prr, jchen ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: 089e3a70de1d Author: coleenp Date: 2013-09-16 14:22 -0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/089e3a70de1d 8021271: Better buffering in ObjC code Summary: Improve buffering in ObjC code Reviewed-by: serb, hseigel, coleenp Contributed-by: gerard.ziemski at oracle.com ! make/common/Release.gmk ! make/java/Makefile Changeset: 77f5558b5215 Author: erikj Date: 2013-09-19 13:32 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/77f5558b5215 8023771: when USER_RELEASE_SUFFIX is set in order to add a string to java -version, build number in the bundles names should not be changed to b00 Reviewed-by: dholmes, ihse ! make/common/shared/Defs.gmk Changeset: 9d29c19f1de1 Author: vadim Date: 2013-09-19 20:56 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9d29c19f1de1 8025034: Improve layout lookups Reviewed-by: mschoene, vadim, srl ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: b85c94444634 Author: erikj Date: 2013-09-23 17:38 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b85c94444634 8025170: jdk7u51 7u-1-prebuild is failing since 9/19 Reviewed-by: tbell, ihse ! make/common/shared/Defs.gmk Changeset: 627abacf40db Author: asaha Date: 2013-09-30 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/627abacf40db Merge ! .hgtags Changeset: 2e35e0dbd2b6 Author: asaha Date: 2013-09-30 11:45 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2e35e0dbd2b6 Added tag jdk7u51-b00 for changeset 3c9a6d9eafd3 + .hgtags Changeset: 48e447472911 Author: asaha Date: 2013-09-30 11:51 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/48e447472911 Merge ! .hgtags Changeset: d76613074ff3 Author: asaha Date: 2013-09-30 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d76613074ff3 Merge ! .hgtags Changeset: 4ef9342e2599 Author: cl Date: 2013-10-01 08:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4ef9342e2599 Added tag jdk7u51-b01 for changeset d76613074ff3 ! .hgtags Changeset: 7f2fc6c7c6dd Author: weijun Date: 2013-09-19 10:40 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7f2fc6c7c6dd 8024302: Clarify jar verifications 8023338: Update jarsigner to encourage timestamping Reviewed-by: mullan, ahgross ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! test/sun/security/tools/jarsigner/TimestampCheck.java ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/ts.sh + test/sun/security/tools/jarsigner/warnings.sh Changeset: dc04e86b0dac Author: malenkov Date: 2013-10-04 19:39 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/dc04e86b0dac 8025448: Enhance listening events Reviewed-by: art, skoivu ! src/share/classes/javax/swing/event/EventListenerList.java Changeset: 15c242aefefd Author: dfuchs Date: 2013-10-07 12:09 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/15c242aefefd 8024867: Enhance logging start up Reviewed-by: mchung, hawtin ! src/share/classes/java/util/logging/LogManager.java Changeset: 35644fe4a796 Author: weijun Date: 2013-10-09 18:58 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/35644fe4a796 8026037: [TESTBUG] sun/security/tools/jarsigner/warnings.sh test fails on Solaris Reviewed-by: chegar Contributed-by: Artem Smotrakov ! test/sun/security/tools/jarsigner/warnings.sh Changeset: fb057871f094 Author: asaha Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/fb057871f094 Merge ! .hgtags Changeset: 6be222726f6d Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6be222726f6d Added tag jdk7u51-b02 for changeset fb057871f094 ! .hgtags Changeset: 8e542d28b8ec Author: jfranck Date: 2013-10-11 11:22 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8e542d28b8ec 8023301: Enhance generic classes Reviewed-by: mchung, hawtin ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java Changeset: 9fbac37835f2 Author: weijun Date: 2013-10-12 10:22 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9fbac37835f2 8026304: jarsigner output bad grammar Reviewed-by: chegar, coffeys Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/tools/JarSignerResources.java Changeset: 232d21f4de76 Author: mcherkas Date: 2013-10-03 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/232d21f4de76 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: alexp, malenkov ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 6b3c195c73b0 Author: xuelei Date: 2013-10-14 18:35 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6b3c195c73b0 8025026: Enhance canonicalization Summary: Don't use cached null xmlns definition. Also reviewed by Alexander Fomin Reviewed-by: mullan, hawtin ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: 0797c957fdb9 Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0797c957fdb9 Added tag jdk7u51-b03 for changeset 6b3c195c73b0 ! .hgtags Changeset: aef5cd4ac081 Author: prr Date: 2013-10-15 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/aef5cd4ac081 8026176: Enhance document printing Reviewed-by: bae, jgodinez ! src/share/classes/javax/print/SimpleDoc.java Changeset: 2197764aee8b Author: xuelei Date: 2013-10-15 20:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2197764aee8b 8026204: Enhance auth login contexts Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: cd8026b9d403 Author: malenkov Date: 2013-10-16 14:02 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cd8026b9d403 8026172: Enhance UI Management Reviewed-by: art, skoivu ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 5c20ac773584 Author: xuelei Date: 2013-10-16 20:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5c20ac773584 8025758: Enhance Naming management Summary: Enforce package access control with current context. Also reviewed by Alexander Fomin Reviewed-by: weijun, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: dd60bcc30d64 Author: jchen Date: 2013-10-16 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/dd60bcc30d64 8024461: [macosx] Java crashed on mac10.9 for swing and 2d function manual test Reviewed-by: prr, vadim, serb ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c Changeset: ac44ec0de12a Author: prr Date: 2013-10-20 06:12 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ac44ec0de12a 8024530: Enhance font process resilience Reviewed-by: mschoene, bae, srl, prr ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEScripts.h ! src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LETableReference.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/TibetanReordering.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: 496c51673dec Author: sjiang Date: 2013-10-21 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/496c51673dec 7068126: Enhance SNMP statuses Reviewed-by: dfuchs, hawtin ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibEntry.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibNode.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java Changeset: 5348ecf3da7f Author: weijun Date: 2013-10-17 09:58 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5348ecf3da7f 8025014: Enhance Security Policy 6727821: Enhance JAAS Configuration Reviewed-by: xuelei, hawtin ! src/share/classes/javax/security/auth/Policy.java ! src/share/classes/javax/security/auth/login/Configuration.java Changeset: cd2808b7e276 Author: xuelei Date: 2013-07-29 19:02 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cd2808b7e276 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/P11Util.java ! src/share/classes/sun/security/util/KeyUtil.java + test/com/sun/crypto/provider/TLS/TestLeadingZeroes.java + test/sun/security/pkcs11/tls/TestLeadingZeroesP11.java Changeset: 96431826ae3a Author: coffeys Date: 2013-10-22 09:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/96431826ae3a Merge Changeset: 3fd08b034937 Author: cl Date: 2013-10-22 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3fd08b034937 Added tag jdk7u51-b04 for changeset 96431826ae3a ! .hgtags Changeset: 8ee582bb96a6 Author: xuelei Date: 2013-10-24 10:07 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8ee582bb96a6 8027204: Revise the update of 8026204 and 8025758 Summary: Rivise the update to use system class loader with null TCCL. Also reviewed by Alexander Fomin Reviewed-by: weijun, mchung, ahgross ! src/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/share/classes/javax/security/auth/login/LoginContext.java Changeset: ec12a8266386 Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ec12a8266386 Added tag jdk7u51-b05 for changeset 8ee582bb96a6 ! .hgtags Changeset: 07004bb53c3c Author: xuelei Date: 2013-10-23 21:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/07004bb53c3c 8026417: Enhance XML canonicalization Summary: Copy before use mutable byte arrays. Also reviewed by Alexander Fomin Reviewed-by: weijun, mullan, hawtin, ahgross ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java Changeset: 8a60b069f9cd Author: asaha Date: 2013-10-31 14:40 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8a60b069f9cd Merge Changeset: 8afbbdc15c3c Author: kshefov Date: 2013-06-21 17:53 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/8afbbdc15c3c 8015976: OpenJDK part of bug JDK-8015812 [TEST_BUG] Tests have conflicting test descriptions Reviewed-by: coffeys, alanb ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html ! test/java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java ! test/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java Changeset: 32842dd53611 Author: aefimov Date: 2013-10-24 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/32842dd53611 8025255: (tz) Support tzdata2013g 8026772: test/sun/util/resources/TimeZone/Bug6317929.java failing Reviewed-by: okutsu, mfang ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! test/ProblemList.txt ! test/sun/util/resources/TimeZone/Bug6317929.java Changeset: 594ae80153af Author: alanb Date: 2013-10-24 19:21 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/594ae80153af 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bateman at oracle.com, mark.sheppard at oracle.com ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 982700bf473b Author: cl Date: 2013-11-05 10:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/982700bf473b Added tag jdk7u51-b06 for changeset 594ae80153af ! .hgtags Changeset: 9b3b76f0b195 Author: mfang Date: 2013-11-07 12:20 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9b3b76f0b195 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/linux/doc/man/ja/jarsigner.1 ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/solaris/doc/sun/man/man1/ja/jarsigner.1 Changeset: 7b84e6514c29 Author: rgallard Date: 2013-11-08 13:50 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7b84e6514c29 8028057: Modify jarsigner man page documentation to document CCC 8024302: Clarify jar verifications Reviewed-by: weijun ! src/bsd/doc/man/jarsigner.1 ! src/linux/doc/man/jarsigner.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 Changeset: 40fca6b57cd8 Author: cl Date: 2013-11-12 08:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/40fca6b57cd8 Added tag jdk7u51-b07 for changeset 7b84e6514c29 ! .hgtags Changeset: 9afd02dabdf9 Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9afd02dabdf9 Added tag jdk7u51-b08 for changeset 40fca6b57cd8 ! .hgtags Changeset: 909ea1f47e0b Author: coffeys Date: 2013-11-21 13:39 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/909ea1f47e0b 8022698: javax/script/GetInterfaceTest.java fails since 7u45 b04 with -agentvm option Reviewed-by: sundar ! test/javax/script/GetInterfaceTest.java Changeset: e6160aedadd5 Author: michaelm Date: 2013-11-01 10:40 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e6160aedadd5 8011786: Better applet networking Summary: add checkListen() to client socket binds and new interpretation for port number 0 in SocketPermission Reviewed-by: chegar, alanb ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/lib/security/java.policy ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java Changeset: 2bce3c0856af Author: michaelm Date: 2013-11-20 15:28 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2bce3c0856af 8028453: AsynchronousSocketChannel.connect() requires SocketPermission due to bind to local address (win) Reviewed-by: alanb, chegar ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java Changeset: 33ae35eeb5a4 Author: msheppar Date: 2013-11-24 13:08 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/33ae35eeb5a4 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung + test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java Changeset: 216138d587a7 Author: asaha Date: 2013-11-27 08:24 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/216138d587a7 Added tag jdk7u51-b09 for changeset 33ae35eeb5a4 ! .hgtags Changeset: e935cd4139c6 Author: michaelm Date: 2013-11-22 00:08 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e935cd4139c6 8028293: Check local configuration for actual ephemeral port range Reviewed-by: alanb, chegar, smarks ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows + src/solaris/classes/sun/net/PortConfig.java ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h + src/solaris/native/sun/net/portconfig.c + src/windows/classes/sun/net/PortConfig.java + src/windows/native/sun/net/portconfig.c ! test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java ! test/java/rmi/registry/readTest/readTest.sh ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 4a6e31d94b29 Author: michaelm Date: 2013-11-22 01:15 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4a6e31d94b29 8028823: java/net/Makefile tabs converted to spaces Reviewed-by: mduigou ! make/java/net/Makefile Changeset: 41c4df1de66a Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/41c4df1de66a Added tag jdk7u51-b10 for changeset 4a6e31d94b29 ! .hgtags Changeset: f0425ecbbb0c Author: aefimov Date: 2013-11-15 13:31 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f0425ecbbb0c 8027370: Support tzdata2013h Reviewed-by: sherman, coffeys ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/southamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f5eee4f1d5b4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/f5eee4f1d5b4 Added tag jdk7u51-b11 for changeset f0425ecbbb0c ! .hgtags Changeset: d19a89fdfb9b Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d19a89fdfb9b Added tag jdk7u51-b12 for changeset f5eee4f1d5b4 ! .hgtags Changeset: 402d54c7d8ce Author: mcherkas Date: 2013-10-03 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/402d54c7d8ce 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: alexp, malenkov ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 34e8f9f26ae6 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/34e8f9f26ae6 Added tag jdk7u45-b33 for changeset 402d54c7d8ce ! .hgtags Changeset: 0cf7bf25b314 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/0cf7bf25b314 Added tag jdk7u45-b34 for changeset 34e8f9f26ae6 ! .hgtags Changeset: 107c98c89f70 Author: asaha Date: 2013-12-17 11:14 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/107c98c89f70 Merge ! .hgtags Changeset: ef58b2b9a9a1 Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ef58b2b9a9a1 Added tag jdk7u51-b13 for changeset d19a89fdfb9b ! .hgtags Changeset: 5bca0d0969b1 Author: asaha Date: 2013-12-19 09:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5bca0d0969b1 Merge ! .hgtags Changeset: a1f5b8329c33 Author: katleman Date: 2013-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a1f5b8329c33 Added tag jdk7u51-b31 for changeset 5bca0d0969b1 ! .hgtags Changeset: e401eec2663a Author: katleman Date: 2013-12-26 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e401eec2663a Added tag jdk7u51-b30 for changeset ef58b2b9a9a1 ! .hgtags Changeset: e238cdb9e11c Author: asaha Date: 2013-12-31 09:00 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/e238cdb9e11c Merge ! .hgtags Changeset: b1bcc999a8f1 Author: asaha Date: 2014-01-02 09:48 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b1bcc999a8f1 Merge ! .hgtags ! make/common/Release.gmk ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/native/java/net/net_util_md.c ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/rmi/testlibrary/TestLibrary.java Changeset: 9af71eceaee6 Author: katleman Date: 2014-01-16 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9af71eceaee6 Added tag jdk7u60-b03 for changeset b1bcc999a8f1 ! .hgtags Changeset: 48b6bddcd0bf Author: uta Date: 2013-05-27 15:18 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/48b6bddcd0bf 8014394: (fs) WatchService failing when watching \\server\$d Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsConstants.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: a774c34382cc Author: alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a774c34382cc 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java Changeset: 4e1095e23665 Author: robm Date: 2013-12-27 15:39 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/4e1095e23665 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! test/java/nio/channels/SocketChannel/ShortWrite.java Changeset: a1f5b443727c Author: coffeys Date: 2013-11-21 13:39 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/a1f5b443727c 8022698: javax/script/GetInterfaceTest.java fails since 7u45 b04 with -agentvm option Reviewed-by: sundar ! test/javax/script/GetInterfaceTest.java Changeset: 21528ae4d923 Author: coffeys Date: 2014-01-02 15:26 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/21528ae4d923 Merge Changeset: 1331fa69ef12 Author: dbuck Date: 2014-01-08 02:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/1331fa69ef12 6571600: JNI use results in UnsatisfiedLinkError looking for libmawt.so Summary: Fix is to call dladdr with name less likely to cause name conflict. Reviewed-by: serb, art ! src/solaris/native/sun/awt/awt_LoadLibrary.c Changeset: aaa6b578707e Author: dfuchs Date: 2014-01-15 20:25 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/aaa6b578707e 8019853: Break logging and AWT circular dependency Summary: Break logging and AWT circular dependency, which was at the root cause for 8023258 - Logger.getLogger() after ImageIO.read() returns different logger instance Reviewed-by: mchung, art ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! test/java/util/logging/TestAppletLoggerContext.java + test/java/util/logging/TestLoggingWithMainAppContext.java Changeset: 17cf9917fdc8 Author: dfuchs Date: 2014-01-15 20:29 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/17cf9917fdc8 8026404: Logging in Applet can trigger ACE: access denied ("java.lang.RuntimePermission" "modifyThreadGroup") Summary: The test 'threadGroup.getParent() == null' can sometimes throw ACE and needs to be wrapped in doPrivileged. Reviewed-by: alanb, mchung, dholmes ! src/share/classes/sun/awt/AppContext.java + test/java/util/logging/TestMainAppContext.java Changeset: 628c6d46263b Author: vlivanov Date: 2014-01-17 01:54 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/628c6d46263b 8009222: java.lang.IllegalArgumentException: not invocable, no method type when attempting to get getter method handle for a static field Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + test/java/lang/invoke/8009222/Test8009222.java Changeset: efc8886310cb Author: lana Date: 2014-01-20 12:12 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/efc8886310cb Merge ! src/share/classes/java/util/logging/LogManager.java Changeset: 19cc3b567644 Author: katleman Date: 2014-01-22 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/19cc3b567644 Added tag jdk7u60-b04 for changeset efc8886310cb ! .hgtags From christian.thalinger at oracle.com Thu Feb 6 13:48:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Feb 2014 13:48:25 -0800 Subject: Error building hotspot with shark/zero In-Reply-To: References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net>, <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> Message-ID: <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> Can you talk to Andrew (CCed) about integrating your changes? On Feb 5, 2014, at 8:30 PM, Neale Ferguson wrote: > I simply followed the instructions and did a hg clone and then used the get_source script to populate everything. > > I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script. > > > -------- Original message -------- > From: Christian Thalinger > Date:2014/02/05 23:14 (GMT-05:00) > To: Neale Ferguson > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Error building hotspot with shark/zero > > This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: > > https://bugs.openjdk.java.net/browse/JDK-7071823 > > On Feb 5, 2014, at 7:20 AM, Neale Ferguson wrote: > > > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: > > > > Linking vm... > > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' > > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > > sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' > > sharedRuntime.o:(.bss+0x0): first defined here > > sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' > > sharedRuntime.o:(.bss+0x8): first defined here > > sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' > > sharedRuntime.o:(.bss+0x10): first defined here > > sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' > > sharedRuntime.o:(.bss+0x18): first defined here > > sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' > > sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so > > make[6]: stat: libjvm.so: Too many levels of symbolic links > > > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. > > > > Neale > > > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > > > >> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... > >> > >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson wrote: > >> > >>> Hi, > >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: > >>> > >>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, > >>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' > >>> > >>> line 72 looks like: > >>> > >>> llvm::Constant* get_external(const char* name, > >>> const llvm::FunctionType* sig) { > >>> return module()->getOrInsertFunction(name, sig); > >>> } > >>> > >>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. > >>> > >>> Neale > >> > > From alejandro.murillo at oracle.com Thu Feb 6 14:00:27 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 06 Feb 2014 22:00:27 +0000 Subject: hg: hsx/jdk7u/langtools: 37 new changesets Message-ID: <20140206220154.AF64762A98@hg.openjdk.java.net> Changeset: 591b0e947c04 Author: asaha Date: 2013-09-12 08:13 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/591b0e947c04 Merge ! .hgtags Changeset: 058d55941249 Author: asaha Date: 2013-09-18 11:21 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/058d55941249 Merge ! .hgtags Changeset: 7e9fe0a89f90 Author: asaha Date: 2013-09-18 11:36 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/7e9fe0a89f90 Merge ! .hgtags Changeset: 83fcd22f90e4 Author: asaha Date: 2013-09-19 15:33 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/83fcd22f90e4 Merge ! .hgtags Changeset: 083ce047cf94 Author: asaha Date: 2013-09-24 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/083ce047cf94 Merge ! .hgtags Changeset: b1295b13534f Author: asaha Date: 2013-09-26 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/b1295b13534f Merge ! .hgtags Changeset: f8576d750234 Author: asaha Date: 2013-09-27 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/f8576d750234 Merge ! .hgtags Changeset: e4db78716919 Author: asaha Date: 2013-09-27 13:18 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/e4db78716919 Merge ! .hgtags Changeset: 5e8ed6530196 Author: asaha Date: 2013-09-30 11:00 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/5e8ed6530196 Added tag jdk7u51-b00 for changeset 18d1864abca9 ! .hgtags Changeset: 14d1cf2630ae Author: asaha Date: 2013-09-30 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/14d1cf2630ae Merge ! .hgtags Changeset: 91fd49745ba1 Author: cl Date: 2013-10-01 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/91fd49745ba1 Added tag jdk7u51-b01 for changeset 14d1cf2630ae ! .hgtags Changeset: 13cf4886911f Author: asaha Date: 2013-10-08 12:01 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/13cf4886911f Merge ! .hgtags Changeset: f0168ccf171e Author: asaha Date: 2013-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/f0168ccf171e Merge ! .hgtags Changeset: 33f986894a3e Author: cl Date: 2013-10-10 10:16 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/33f986894a3e Added tag jdk7u51-b02 for changeset f0168ccf171e ! .hgtags Changeset: 9a4b7362a592 Author: cl Date: 2013-10-15 09:32 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/9a4b7362a592 Added tag jdk7u51-b03 for changeset 33f986894a3e ! .hgtags Changeset: c8d1379f16eb Author: cl Date: 2013-10-22 22:24 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/c8d1379f16eb Added tag jdk7u51-b04 for changeset 9a4b7362a592 ! .hgtags Changeset: 1e8c8518497b Author: cl Date: 2013-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/1e8c8518497b Added tag jdk7u51-b05 for changeset c8d1379f16eb ! .hgtags Changeset: 253a82945c71 Author: cl Date: 2013-11-05 10:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/253a82945c71 Added tag jdk7u51-b06 for changeset 1e8c8518497b ! .hgtags Changeset: 60d5dc8c5c8c Author: mfang Date: 2013-11-07 12:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/60d5dc8c5c8c 8027787: 7u51 l10n resource file translation update 1 Reviewed-by: yhuang ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties Changeset: 009a4086b2a6 Author: mfang Date: 2013-11-07 12:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/009a4086b2a6 Merge Changeset: cccd0d52003d Author: cl Date: 2013-11-12 08:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/cccd0d52003d Added tag jdk7u51-b07 for changeset 009a4086b2a6 ! .hgtags Changeset: d8a69a841acd Author: cl Date: 2013-11-19 08:37 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/d8a69a841acd Added tag jdk7u51-b08 for changeset cccd0d52003d ! .hgtags Changeset: 7e33fc6adc82 Author: asaha Date: 2013-11-27 08:26 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/7e33fc6adc82 Added tag jdk7u51-b09 for changeset d8a69a841acd ! .hgtags Changeset: c9d8d8793d93 Author: katleman Date: 2013-12-04 10:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/c9d8d8793d93 Added tag jdk7u51-b10 for changeset 7e33fc6adc82 ! .hgtags Changeset: 5b44df2114e4 Author: katleman Date: 2013-12-10 13:16 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/5b44df2114e4 Added tag jdk7u51-b11 for changeset c9d8d8793d93 ! .hgtags Changeset: 4d0807934c30 Author: katleman Date: 2013-12-14 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/4d0807934c30 Added tag jdk7u51-b12 for changeset 5b44df2114e4 ! .hgtags Changeset: bcb3e939d046 Author: cl Date: 2013-11-25 11:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/bcb3e939d046 Added tag jdk7u45-b33 for changeset ef7bdbe7f1fa ! .hgtags Changeset: efbda7abd821 Author: katleman Date: 2013-12-06 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/efbda7abd821 Added tag jdk7u45-b34 for changeset bcb3e939d046 ! .hgtags Changeset: 96d897736590 Author: asaha Date: 2013-12-17 11:20 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/96d897736590 Merge ! .hgtags Changeset: ada23e55d76a Author: katleman Date: 2013-12-19 09:01 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/ada23e55d76a Added tag jdk7u51-b13 for changeset 4d0807934c30 ! .hgtags Changeset: e3d4896d52ab Author: asaha Date: 2013-12-19 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/e3d4896d52ab Merge ! .hgtags Changeset: 5d36d5fb1078 Author: katleman Date: 2013-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/5d36d5fb1078 Added tag jdk7u51-b31 for changeset e3d4896d52ab ! .hgtags Changeset: aed2651202db Author: katleman Date: 2013-12-26 13:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/aed2651202db Added tag jdk7u51-b30 for changeset ada23e55d76a ! .hgtags Changeset: d03b91d1f50d Author: asaha Date: 2013-12-31 09:02 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/d03b91d1f50d Merge ! .hgtags Changeset: 4170784840d5 Author: asaha Date: 2014-01-02 10:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/4170784840d5 Merge ! .hgtags Changeset: 772aad4e9681 Author: katleman Date: 2014-01-16 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/772aad4e9681 Added tag jdk7u60-b03 for changeset 4170784840d5 ! .hgtags Changeset: 744287fccf3b Author: katleman Date: 2014-01-22 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/langtools/rev/744287fccf3b Added tag jdk7u60-b04 for changeset 772aad4e9681 ! .hgtags From alejandro.murillo at oracle.com Thu Feb 6 14:03:29 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 06 Feb 2014 15:03:29 -0700 Subject: Fwd: Re: Question on 8024648 : 8016131 breaks Zero port In-Reply-To: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> Message-ID: <52F406B1.70300@oracle.com> can we get 2 hotspot reviewers quickly check this change ? thanks Alejandro -------- Original Message -------- Subject: Re: Question on 8024648 : 8016131 breaks Zero port Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) From: Andrew Hughes To: Alejandro E Murillo CC: Se?n Coffey , Omair Majid , jdk7u-dev at openjdk.java.net ----- Original Message ----- Here's the webrev: http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ My OpenJDK username is andrew (should already be included in the commit) The changes are as follows: * Bring in defs.make to a number of makefiles which expect JVM_VARIANT_ZERO or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that sets it. This is a regression caused by the new build which instead sets these via configure and $(SPEC). There is code for handling the old build (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) * Update the call_wrapper function following 8024648. I've updated the bug summary to reflect that it fixes changes from both bugs, but we can split them into two separate bugs if you prefer. Without the 7141246 fix, the build fails in seconds. With the webrev applied: $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-andrew_2014_02_06_19_43-b00) OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld Hello World -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From alejandro.murillo at oracle.com Thu Feb 6 14:10:21 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 06 Feb 2014 15:10:21 -0700 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F406B1.70300@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> Message-ID: <52F4084D.9060605@oracle.com> I forgot to change the "subject". The change is and has been approved for 7u60 (hs24.60) Thanks Alejandro On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: > > can we get 2 hotspot reviewers quickly check this change ? > thanks > Alejandro > > -------- Original Message -------- > Subject: Re: Question on 8024648 : 8016131 breaks Zero port > Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) > From: Andrew Hughes > To: Alejandro E Murillo > CC: Se?n Coffey , Omair Majid > , jdk7u-dev at openjdk.java.net > > > > ----- Original Message ----- > > > Here's the webrev: > > http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ > > My OpenJDK username is andrew (should already be included in the commit) > > The changes are as follows: > > * Bring in defs.make to a number of makefiles which expect > JVM_VARIANT_ZERO > or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that > sets > it. This is a regression caused by the new build which instead sets these > via configure and $(SPEC). There is code for handling the old build > (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) > * Update the call_wrapper function following 8024648. > > I've updated the bug summary to reflect that it fixes changes from both > bugs, but we can split them into two separate bugs if you prefer. Without > the 7141246 fix, the build fails in seconds. > > With the webrev applied: > > $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version > openjdk version "1.7.0-internal" > OpenJDK Runtime Environment (build > 1.7.0-internal-andrew_2014_02_06_19_43-b00) > OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) > > $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld > Hello World > > -- Alejandro From coleen.phillimore at oracle.com Thu Feb 6 14:35:09 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Feb 2014 17:35:09 -0500 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F4084D.9060605@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> Message-ID: <52F40E1D.6080704@oracle.com> This looks fine. Coleen On 2/6/14 5:10 PM, Alejandro E Murillo wrote: > I forgot to change the "subject". > The change is and has been approved for 7u60 (hs24.60) > Thanks > > Alejandro > > On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >> >> can we get 2 hotspot reviewers quickly check this change ? >> thanks >> Alejandro >> >> -------- Original Message -------- >> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >> From: Andrew Hughes >> To: Alejandro E Murillo >> CC: Se?n Coffey , Omair Majid >> , jdk7u-dev at openjdk.java.net >> >> >> >> ----- Original Message ----- >> >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >> >> My OpenJDK username is andrew (should already be included in the commit) >> >> The changes are as follows: >> >> * Bring in defs.make to a number of makefiles which expect >> JVM_VARIANT_ZERO >> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >> sets >> it. This is a regression caused by the new build which instead sets >> these >> via configure and $(SPEC). There is code for handling the old build >> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >> * Update the call_wrapper function following 8024648. >> >> I've updated the bug summary to reflect that it fixes changes from both >> bugs, but we can split them into two separate bugs if you prefer. >> Without >> the 7141246 fix, the build fails in seconds. >> >> With the webrev applied: >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >> openjdk version "1.7.0-internal" >> OpenJDK Runtime Environment (build >> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >> Hello World >> >> > From serguei.spitsyn at oracle.com Thu Feb 6 14:45:03 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 06 Feb 2014 22:45:03 +0000 Subject: hg: hsx/jdk7u/hotspot: 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check Message-ID: <20140206224510.7101362A9B@hg.openjdk.java.net> Changeset: d40d2a206cab Author: sspitsyn Date: 2014-02-06 16:23 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d40d2a206cab 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check Summary: SA should have a knowledge about the invokehandle bytecode Reviewed-by: twisti, sla, sspitsyn, sjiang, dsamersoff Contributed-by: olivier.lagneau at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java From gnu.andrew at redhat.com Thu Feb 6 14:46:51 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Feb 2014 17:46:51 -0500 (EST) Subject: Error building hotspot with shark/zero In-Reply-To: <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net> <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> Message-ID: <1974355445.5752274.1391726811480.JavaMail.root@redhat.com> ----- Original Message ----- > Can you talk to Andrew (CCed) about integrating your changes? > > On Feb 5, 2014, at 8:30 PM, Neale Ferguson wrote: > > > I simply followed the instructions and did a hg clone and then used the > > get_source script to populate everything. > > > > I did find a patch that removed generate_stubs etc and things ran to > > completion. There were certain methods that needed adding to > > sharkMemoryManager such as allocateCodeSection. Other issues included > > createPHI and CreateCall parameters having changed. Also llvm-config > > --ldflags doesn't return -lot info so I had to provide a quick and dirty > > fix to the generic profile script. > > The obvious thing that occurs to me is that: 8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke is only present in 8 and not 7u. That added support for LLVM 3.3 IIRC. There were also Makefile changes required for Zero that probably apply to Shark too: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012451.html (notably gcc.make has conditionals on Shark but doesn't bring in defs.make where they are set) > > > > -------- Original message -------- > > From: Christian Thalinger > > Date:2014/02/05 23:14 (GMT-05:00) > > To: Neale Ferguson > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: Error building hotspot with shark/zero > > > > This is odd. What version of OpenJDK 7 are you using as this got fixed a > > long time ago: > > > > https://bugs.openjdk.java.net/browse/JDK-7071823 > > > > On Feb 5, 2014, at 7:20 AM, Neale Ferguson wrote: > > > > > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now > > > but I now crap out with: > > > > > > Linking vm... > > > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > > > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of > > > `SharedRuntime::generate_stubs()' > > > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > > > sharedRuntime_zero.o:(.bss+0x18): multiple definition of > > > `SharedRuntime::_wrong_method_blob' > > > sharedRuntime.o:(.bss+0x0): first defined here > > > sharedRuntime_zero.o:(.bss+0x20): multiple definition of > > > `SharedRuntime::_ic_miss_blob' > > > sharedRuntime.o:(.bss+0x8): first defined here > > > sharedRuntime_zero.o:(.bss+0x28): multiple definition of > > > `SharedRuntime::_resolve_opt_virtual_call_blob' > > > sharedRuntime.o:(.bss+0x10): first defined here > > > sharedRuntime_zero.o:(.bss+0x30): multiple definition of > > > `SharedRuntime::_resolve_virtual_call_blob' > > > sharedRuntime.o:(.bss+0x18): first defined here > > > sharedRuntime_zero.o:(.bss+0x38): multiple definition of > > > `SharedRuntime::_resolve_static_call_blob' > > > sharedRuntime.o:(.bss+0x20): first defined > > > heresharedRuntime_zero.o:(.bss+0x8): multiple definition of > > > `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): > > > first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition > > > of > > > `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): > > > first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition > > > of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first > > > defined herecollect2: ld returned 1 exit statusln: accessing > > > `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed > > > to get security context of `libjvm.so': Too many levels of symbolic > > > linksERROR: Cannot chcon libjvm.so > > > make[6]: stat: libjvm.so: Too many levels of symbolic links > > > > > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs > > > defined and there doesn't appear to be conditional logic that needs to > > > be triggered to stop it, so is it a Makefile thing? As for the "too many > > > levels of symbolic links", because the link failed the symlink ends up > > > pointing to itself. > > > > > > Neale > > > > > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > > > > > >> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some > > >> method signatures have changed. Let?s see if I can make it work... > > >> > > >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson > > >> wrote: > > >> > > >>> Hi, > > >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the > > >>> following when using llvm-3.4: > > >>> > > >>> In file included from > > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, > > >>> from > > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: > > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In > > >>> member function 'llvm::Constant* SharkContext::get_external(const > > >>> char*, const llvm::FunctionType*)': > > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: > > >>> error: invalid conversion from 'const llvm::FunctionType*' to > > >>> 'llvm::FunctionType*' > > >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: > > >>> error: initializing argument 2 of 'llvm::Constant* > > >>> llvm::Module::getOrInsertFunction(llvm::StringRef, > > >>> llvm::FunctionType*)' > > >>> > > >>> line 72 looks like: > > >>> > > >>> llvm::Constant* get_external(const char* name, > > >>> const llvm::FunctionType* sig) { > > >>> return module()->getOrInsertFunction(name, sig); > > >>> } > > >>> > > >>> Before I go too far with this I thought I'd find out if this was a > > >>> known issue. I note there were other issues getting this far, like > > >>> where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so > > >>> there are probably other changes of significance. > > >>> > > >>> Neale > > >> > > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From vladimir.kozlov at oracle.com Thu Feb 6 15:04:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 06 Feb 2014 15:04:37 -0800 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F4084D.9060605@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> Message-ID: <52F41505.3000401@oracle.com> Did these changes pass all our builds on all platforms? I mean Hotspot builds and Full forest control builds in JPRT. Thanks, Vladimir On 2/6/14 2:10 PM, Alejandro E Murillo wrote: > I forgot to change the "subject". > The change is and has been approved for 7u60 (hs24.60) > Thanks > > Alejandro > > On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >> >> can we get 2 hotspot reviewers quickly check this change ? >> thanks >> Alejandro >> >> -------- Original Message -------- >> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >> From: Andrew Hughes >> To: Alejandro E Murillo >> CC: Se?n Coffey , Omair Majid >> , jdk7u-dev at openjdk.java.net >> >> >> >> ----- Original Message ----- >> >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >> >> My OpenJDK username is andrew (should already be included in the commit) >> >> The changes are as follows: >> >> * Bring in defs.make to a number of makefiles which expect >> JVM_VARIANT_ZERO >> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >> sets >> it. This is a regression caused by the new build which instead sets these >> via configure and $(SPEC). There is code for handling the old build >> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >> * Update the call_wrapper function following 8024648. >> >> I've updated the bug summary to reflect that it fixes changes from both >> bugs, but we can split them into two separate bugs if you prefer. Without >> the 7141246 fix, the build fails in seconds. >> >> With the webrev applied: >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >> openjdk version "1.7.0-internal" >> OpenJDK Runtime Environment (build >> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >> Hello World >> >> > From serguei.spitsyn at oracle.com Thu Feb 6 15:17:53 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 06 Feb 2014 15:17:53 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F01569.3070201@oracle.com> References: <52F01569.3070201@oracle.com> Message-ID: <52F41821.10403@oracle.com> Runtime team, This fix was reviewed by Vladimir K. and me. Just wanted to make sure if you would like to review it as well. If not, then I will push it. Thanks, Serguei On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8025841 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 > > > Summary: > > The fix contributed by Oleg Mazurov to improve profiling data quality. > It moves the "vtable stub" dynamic code notification to the right > place. > I've already reviewed the fix, and it looks good to me. > > Bug report description: > > "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets > scheduled when > a new chunk of memory for subsequent vtable and itable stubs is > allocated. > That chunk is uninitialized (contains zeros or garbage) although > due to the fact > that the actual event delivery is deferred, at least one vtable > comes out right. > > This event should describe an individual vtable/itable stub (base > address and size) > and only after it's been created (memory is actually populated > with code). > Where VM diagnostic messages about vtable/itable stubs are issued > upon > -XX:+PrintAdapterHandlers appears exactly the right place for > JVMTI events as well. > > Getting vtables/itables right is important in the context of > performance analysis as > that dynamically generated code may accumulate quite noticeable > CPU time > (especially itabes), sometimes larger than the actual Java methods > called." > > > Testing: > Oleg tested it in the Oracle Studio Performance Analyzer environment. > nsk.jvmti, nsk.jdi, nsk.jdwp, > In progress: Jtreg com/sun/jdi, java/lang/instrument > > > Thanks, > Serguei > From coleen.phillimore at oracle.com Thu Feb 6 15:32:13 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Feb 2014 18:32:13 -0500 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F41821.10403@oracle.com> References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> Message-ID: <52F41B7D.6090206@oracle.com> Hi, I clicked on this a couple times. It seems okay but isn't there a safer way to identify code blobs that are vtable stubs, without looking at the name (which can change in while creating it). A comment at least when you create "vtable chunks" would be good. It seems that someone might want to rename it "vtable or itable buffers", or something like that. thanks, Coleen On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: > Runtime team, > > This fix was reviewed by Vladimir K. and me. > Just wanted to make sure if you would like to review it as well. > If not, then I will push it. > > Thanks, > Serguei > > On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8025841 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >> >> >> Summary: >> >> The fix contributed by Oleg Mazurov to improve profiling data quality. >> It moves the "vtable stub" dynamic code notification to the right >> place. >> I've already reviewed the fix, and it looks good to me. >> >> Bug report description: >> >> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets >> scheduled when >> a new chunk of memory for subsequent vtable and itable stubs is >> allocated. >> That chunk is uninitialized (contains zeros or garbage) although >> due to the fact >> that the actual event delivery is deferred, at least one vtable >> comes out right. >> >> This event should describe an individual vtable/itable stub (base >> address and size) >> and only after it's been created (memory is actually populated >> with code). >> Where VM diagnostic messages about vtable/itable stubs are issued >> upon >> -XX:+PrintAdapterHandlers appears exactly the right place for >> JVMTI events as well. >> >> Getting vtables/itables right is important in the context of >> performance analysis as >> that dynamically generated code may accumulate quite noticeable >> CPU time >> (especially itabes), sometimes larger than the actual Java >> methods called." >> >> >> Testing: >> Oleg tested it in the Oracle Studio Performance Analyzer environment. >> nsk.jvmti, nsk.jdi, nsk.jdwp, >> In progress: Jtreg com/sun/jdi, java/lang/instrument >> >> >> Thanks, >> Serguei >> > From oleg.mazurov at oracle.com Thu Feb 6 15:52:28 2014 From: oleg.mazurov at oracle.com (Oleg Mazurov) Date: Thu, 6 Feb 2014 15:52:28 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F41B7D.6090206@oracle.com> References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> <52F41B7D.6090206@oracle.com> Message-ID: My understanding was that a buffer blob was just that - a buffer. Could potentially contain code fragments of different kinds. Thus, is_buffer_blob() was the closest type available. Agree that a dependency on its name is not reliable, though testing will reveal if the condition turns false for "vtable chunks" due to a name change (I had to deal with that particular test, Serguei should be able to identify it). Adding a comment to where the name is defined (vtableStubs.cpp) that such a dependency exists is a good idea. Thanks, -- Oleg On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote: > > Hi, I clicked on this a couple times. It seems okay but isn't there a safer way to identify code blobs that are vtable stubs, without looking at the name (which can change in while creating it). A comment at least when you create "vtable chunks" would be good. It seems that someone might want to rename it "vtable or itable buffers", or something like that. > > thanks, > Coleen > > On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: >> Runtime team, >> >> This fix was reviewed by Vladimir K. and me. >> Just wanted to make sure if you would like to review it as well. >> If not, then I will push it. >> >> Thanks, >> Serguei >> >> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8025841 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >>> >>> Summary: >>> >>> The fix contributed by Oleg Mazurov to improve profiling data quality. >>> It moves the "vtable stub" dynamic code notification to the right place. >>> I've already reviewed the fix, and it looks good to me. >>> >>> Bug report description: >>> >>> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled when >>> a new chunk of memory for subsequent vtable and itable stubs is allocated. >>> That chunk is uninitialized (contains zeros or garbage) although due to the fact >>> that the actual event delivery is deferred, at least one vtable comes out right. >>> >>> This event should describe an individual vtable/itable stub (base address and size) >>> and only after it's been created (memory is actually populated with code). >>> Where VM diagnostic messages about vtable/itable stubs are issued upon >>> -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI events as well. >>> >>> Getting vtables/itables right is important in the context of performance analysis as >>> that dynamically generated code may accumulate quite noticeable CPU time >>> (especially itabes), sometimes larger than the actual Java methods called." >>> >>> >>> Testing: >>> Oleg tested it in the Oracle Studio Performance Analyzer environment. >>> nsk.jvmti, nsk.jdi, nsk.jdwp, >>> In progress: Jtreg com/sun/jdi, java/lang/instrument >>> >>> >>> Thanks, >>> Serguei >>> >> > From coleen.phillimore at oracle.com Thu Feb 6 16:23:05 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 06 Feb 2014 19:23:05 -0500 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> <52F41B7D.6090206@oracle.com> Message-ID: <52F42769.3040603@oracle.com> Okay, thanks for adding a comment. Coleen On 2/6/14 6:52 PM, Oleg Mazurov wrote: > My understanding was that a buffer blob was just that - a buffer. > Could potentially contain code fragments of different kinds. > Thus, is_buffer_blob() was the closest type available. Agree that a > dependency on its name is not reliable, though testing > will reveal if the condition turns false for "vtable chunks" due to a > name change (I had to deal with that particular test, Serguei > should be able to identify it). Adding a comment to where the name is > defined (vtableStubs.cpp) that such a dependency exists > is a good idea. > Thanks, > > -- Oleg > > On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote: > >> >> Hi, I clicked on this a couple times. It seems okay but isn't there >> a safer way to identify code blobs that are vtable stubs, without >> looking at the name (which can change in while creating it). A >> comment at least when you create "vtable chunks" would be good. It >> seems that someone might want to rename it "vtable or itable >> buffers", or something like that. >> >> thanks, >> Coleen >> >> On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: >>> Runtime team, >>> >>> This fix was reviewed by Vladimir K. and me. >>> Just wanted to make sure if you would like to review it as well. >>> If not, then I will push it. >>> >>> Thanks, >>> Serguei >>> >>> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8025841 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >>>> >>>> >>>> Summary: >>>> >>>> The fix contributed by Oleg Mazurov to improve profiling data >>>> quality. >>>> It moves the "vtable stub" dynamic code notification to the right >>>> place. >>>> I've already reviewed the fix, and it looks good to me. >>>> >>>> Bug report description: >>>> >>>> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets >>>> scheduled when >>>> a new chunk of memory for subsequent vtable and itable stubs is >>>> allocated. >>>> That chunk is uninitialized (contains zeros or garbage) >>>> although due to the fact >>>> that the actual event delivery is deferred, at least one vtable >>>> comes out right. >>>> >>>> This event should describe an individual vtable/itable stub >>>> (base address and size) >>>> and only after it's been created (memory is actually populated >>>> with code). >>>> Where VM diagnostic messages about vtable/itable stubs are >>>> issued upon >>>> -XX:+PrintAdapterHandlers appears exactly the right place for >>>> JVMTI events as well. >>>> >>>> Getting vtables/itables right is important in the context of >>>> performance analysis as >>>> that dynamically generated code may accumulate quite noticeable >>>> CPU time >>>> (especially itabes), sometimes larger than the actual Java >>>> methods called." >>>> >>>> >>>> Testing: >>>> Oleg tested it in the Oracle Studio Performance Analyzer >>>> environment. >>>> nsk.jvmti, nsk.jdi, nsk.jdwp, >>>> In progress: Jtreg com/sun/jdi, java/lang/instrument >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From christian.thalinger at oracle.com Thu Feb 6 17:07:42 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 6 Feb 2014 17:07:42 -0800 Subject: Usage of C++ features In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> Message-ID: <28F21B9D-B056-49D8-9CEA-D72F57EAC104@oracle.com> On Feb 6, 2014, at 12:28 PM, Igor Veresov wrote: > Definitely there are talks about this. > More templates, exceptions https://bugs.openjdk.java.net/browse/JDK-8023056 > , and if we?re lucky with our own set of compilers - STL. > > igor > > On Feb 6, 2014, at 2:33 AM, Lindenmaier, Goetz wrote: > >> Hi, >> >> wrt. our (SAPs) various ports which are running on old machines, built >> with old compilers for compatibility, I would like to find out about >> the OpenJDK policy regarding 'real' C++ features. >> >> Recently, we found increasing usage of C++ features. >> >> - 'throw()' in nmethod operator new >> >> - usage of namespace std:: >> >> - template template parameters in binaryTreeDictionary.hpp|cpp >> >> We would like to know whether you are planning to increase the >> usage of C++ or even use C++11 features. Or, whether you are planning >> to keep the policy to avoid C++ features that caused problems to >> compilers in the past. >> >> Best regards, >> Goetz. > From alejandro.murillo at oracle.com Thu Feb 6 17:08:59 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 06 Feb 2014 18:08:59 -0700 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F41505.3000401@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F41505.3000401@oracle.com> Message-ID: <52F4322B.60700@oracle.com> I just got the patch from Andrews not sure what testing he did. Andrew? I'm in the process of submitting a control job, was planning to do the hotspot one during the submission This is a backport from 8 Thanks Alejandro On 2/6/2014 4:04 PM, Vladimir Kozlov wrote: > Did these changes pass all our builds on all platforms? I mean Hotspot > builds and Full forest control builds in JPRT. > > Thanks, > Vladimir > > On 2/6/14 2:10 PM, Alejandro E Murillo wrote: >> I forgot to change the "subject". >> The change is and has been approved for 7u60 (hs24.60) >> Thanks >> >> Alejandro >> >> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >>> >>> can we get 2 hotspot reviewers quickly check this change ? >>> thanks >>> Alejandro >>> >>> -------- Original Message -------- >>> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >>> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >>> From: Andrew Hughes >>> To: Alejandro E Murillo >>> CC: Se?n Coffey , Omair Majid >>> , jdk7u-dev at openjdk.java.net >>> >>> >>> >>> ----- Original Message ----- >>> >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >>> >>> My OpenJDK username is andrew (should already be included in the >>> commit) >>> >>> The changes are as follows: >>> >>> * Bring in defs.make to a number of makefiles which expect >>> JVM_VARIANT_ZERO >>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >>> sets >>> it. This is a regression caused by the new build which instead sets >>> these >>> via configure and $(SPEC). There is code for handling the old build >>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >>> * Update the call_wrapper function following 8024648. >>> >>> I've updated the bug summary to reflect that it fixes changes from both >>> bugs, but we can split them into two separate bugs if you prefer. >>> Without >>> the 7141246 fix, the build fails in seconds. >>> >>> With the webrev applied: >>> >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >>> openjdk version "1.7.0-internal" >>> OpenJDK Runtime Environment (build >>> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >>> >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >>> Hello World >>> >>> >> -- Alejandro From john.r.rose at oracle.com Thu Feb 6 17:40:35 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Feb 2014 17:40:35 -0800 Subject: Usage of C++ features In-Reply-To: <52F371B7.1000401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <52F371B7.1000401@oracle.com> Message-ID: <7113D50F-A668-45B2-9542-31FC5F35D561@oracle.com> On Feb 6, 2014, at 3:27 AM, David Holmes wrote: > That said the compiler folk have expressed interest in using C++ exceptions within the compiler. On Feb 6, 2014, at 5:07 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8023056 The HotSpot project as a whole is not likely to be an early adopter of new C++ mechanisms, especially those which require specialized run-time or link-time support. For example, it took us many years to embrace templates, because anything other than the most straightforward uses (compile-time, macro-like) risked bugs or poor performance (speed or code-size) on one or more of our many platforms. Now that STL is widely used, it appears that all C++ compilers handle templates well. For reasons like this HotSpot must be a follower of C++ uptake, so the technology can lead in other dimensions such as portability. It's not good enough for us that one or two reference implementations of C++ (out of windows, gcc, clang, Solaris, etc.) are solid and performant on some C++ feature in order for HotSpot to use it. C++ exceptions probably have special expenses in addition to stability and portability risks. I would not be surprised if the low-level details of C++ non-local exits and unwind handlers will interfere with some other aspect of HotSpot, such as the JVM's own stack walking requirements. Or, the fine-grained nature of C++ destructor ordering might (on some platforms, until implementations mature) inflate some combination of exception table metadata and/or exit path code and/or object size. You can think of it this way also: Platform-specific problems and their workarounds are a significant project cost even now, so branching out into new parts of the C++ language needs to be done with an eye towards managing that cost. On the other hand, managing the cost also includes testing proposals for new C++ code patterns from time to time. It is possible (though I am skeptical) that C++ exceptions could simplify some parts of our source code, such as the compiler, with reasonable costs on all platforms. ? John From david.holmes at oracle.com Thu Feb 6 21:14:17 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Feb 2014 15:14:17 +1000 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F4084D.9060605@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> Message-ID: <52F46BA9.3060204@oracle.com> I have a concern here. First this general situation is a mess. We started adding the new-build support in hs24 but JDK 8 is using hs25, so all this SPEC and JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here would be to get this stuff backed out of 7u and return to a completely configure-ignorant build system. That said I'm not sure that is really the issue with ZERO/SHARK builds. My concern with the proposed patch is that defs.make is not intended to be included by every other Makefile and/or .make file. We all know by now that the hotspot build system is complex, convoluted and fragile. When you do a hotspot build there are multiple nested sub-makes involved, as well as build file generation and use. The "big picture" intent is that defs.make contains all the high-level stuff needed by the "top" level makefile targets. buildtree.make will then generate other .make files using that information. It is very difficult to see exactly which .make file will get used by which phase of the overall build. Unfortunately this leads to a tendency where if a "low-level" file needs access to X, which is defined in defs.make, then the "solution" is just to include defs.make in that file. We did the same thing for buildtree.make in JDK 8. But I have reservations about also doing it for gcc.make and vm.make. I think it is the wrong solution - we should be passing the needed variables/values through the files generated by buildtree.make. If this was to go ahead as-is I would want to know that there has been a comparison of all the build commands before and after to ensure no unintended changes have been introduced. A set of successful builds is not in itself sufficient. David On 7/02/2014 8:10 AM, Alejandro E Murillo wrote: > I forgot to change the "subject". > The change is and has been approved for 7u60 (hs24.60) > Thanks > > Alejandro > > On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >> >> can we get 2 hotspot reviewers quickly check this change ? >> thanks >> Alejandro >> >> -------- Original Message -------- >> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >> From: Andrew Hughes >> To: Alejandro E Murillo >> CC: Se?n Coffey , Omair Majid >> , jdk7u-dev at openjdk.java.net >> >> >> >> ----- Original Message ----- >> >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >> >> My OpenJDK username is andrew (should already be included in the commit) >> >> The changes are as follows: >> >> * Bring in defs.make to a number of makefiles which expect >> JVM_VARIANT_ZERO >> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >> sets >> it. This is a regression caused by the new build which instead sets these >> via configure and $(SPEC). There is code for handling the old build >> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >> * Update the call_wrapper function following 8024648. >> >> I've updated the bug summary to reflect that it fixes changes from both >> bugs, but we can split them into two separate bugs if you prefer. Without >> the 7141246 fix, the build fails in seconds. >> >> With the webrev applied: >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >> openjdk version "1.7.0-internal" >> OpenJDK Runtime Environment (build >> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >> >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >> Hello World >> >> > From david.holmes at oracle.com Thu Feb 6 23:36:15 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Feb 2014 17:36:15 +1000 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F46BA9.3060204@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> Message-ID: <52F48CEF.4000806@oracle.com> To expand on a solution for this ... Note that in vm.make and gcc.make the only uses of the JVM_VARIANT variables relates to ZERO and ZEROSHARK. That is the real problem in my view (it was natural to use them as they were very prominent). Looking through the build process it seems to me that in the generated flags.make we will have: include zero|shark.make include gcc.make And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH will also be zero but that doesn't help with shark.) Aside: note that here zero or shark is the VARIANT but that isn't exposed in the generated makefiles as the VARIANT is already implicit in the path to which the file was generated eg hotspot/__/product Similarly the generated vm.make will include flags.make before the repo version of vm.make so it too can use TYPE to identify ZERO or SHARK. If I knew how to build zero/shark I'd test this out. :( David ----- On 7/02/2014 3:14 PM, David Holmes wrote: > I have a concern here. > > First this general situation is a mess. We started adding the new-build > support in hs24 but JDK 8 is using hs25, so all this SPEC and > JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here > would be to get this stuff backed out of 7u and return to a completely > configure-ignorant build system. That said I'm not sure that is really > the issue with ZERO/SHARK builds. > > My concern with the proposed patch is that defs.make is not intended to > be included by every other Makefile and/or .make file. We all know by > now that the hotspot build system is complex, convoluted and fragile. > When you do a hotspot build there are multiple nested sub-makes > involved, as well as build file generation and use. The "big picture" > intent is that defs.make contains all the high-level stuff needed by the > "top" level makefile targets. buildtree.make will then generate other > .make files using that information. It is very difficult to see exactly > which .make file will get used by which phase of the overall build. > Unfortunately this leads to a tendency where if a "low-level" file needs > access to X, which is defined in defs.make, then the "solution" is just > to include defs.make in that file. We did the same thing for > buildtree.make in JDK 8. But I have reservations about also doing it for > gcc.make and vm.make. I think it is the wrong solution - we should be > passing the needed variables/values through the files generated by > buildtree.make. > > If this was to go ahead as-is I would want to know that there has been a > comparison of all the build commands before and after to ensure no > unintended changes have been introduced. A set of successful builds is > not in itself sufficient. > > David > > On 7/02/2014 8:10 AM, Alejandro E Murillo wrote: >> I forgot to change the "subject". >> The change is and has been approved for 7u60 (hs24.60) >> Thanks >> >> Alejandro >> >> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >>> >>> can we get 2 hotspot reviewers quickly check this change ? >>> thanks >>> Alejandro >>> >>> -------- Original Message -------- >>> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >>> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >>> From: Andrew Hughes >>> To: Alejandro E Murillo >>> CC: Se?n Coffey , Omair Majid >>> , jdk7u-dev at openjdk.java.net >>> >>> >>> >>> ----- Original Message ----- >>> >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >>> >>> My OpenJDK username is andrew (should already be included in the commit) >>> >>> The changes are as follows: >>> >>> * Bring in defs.make to a number of makefiles which expect >>> JVM_VARIANT_ZERO >>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >>> sets >>> it. This is a regression caused by the new build which instead sets >>> these >>> via configure and $(SPEC). There is code for handling the old build >>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >>> * Update the call_wrapper function following 8024648. >>> >>> I've updated the bug summary to reflect that it fixes changes from both >>> bugs, but we can split them into two separate bugs if you prefer. >>> Without >>> the 7141246 fix, the build fails in seconds. >>> >>> With the webrev applied: >>> >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >>> openjdk version "1.7.0-internal" >>> OpenJDK Runtime Environment (build >>> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >>> >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >>> Hello World >>> >>> >> From christian.tornqvist at oracle.com Fri Feb 7 03:47:58 2014 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 7 Feb 2014 06:47:58 -0500 Subject: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message In-Reply-To: <48645969-EC27-44A9-8BB4-96F4D84F2BA9@oracle.com> References: <01ed01cf22ea$430d4af0$c927e0d0$@oracle.com> <2FD9E106-8627-48F2-8849-C892B0B6733E@oracle.com> <02a601cf2381$2a2e3b60$7e8ab220$@oracle.com> <48645969-EC27-44A9-8BB4-96F4D84F2BA9@oracle.com> Message-ID: <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> Expanding this to hotspot-dev since I'm making changes to test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java as part of this change. Updated the exception message and modified the test to allow options sent via -vmoption/-vmoptions in jtreg to be passed to the spawned Java process. New webrev at: http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.01/ Thanks, Christian From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Thursday, February 6, 2014 4:46 PM To: Christian Tornqvist Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message I respectfully disagree. If I want to e.g. run all tests in interpreted mode for whatever reason (maybe there is a bug in the compiler and I want to see if it happens in interpreted mode too) then I want ALL tests to run with the flags I specify. No matter what they do. On Feb 6, 2014, at 1:19 PM, Christian Tornqvist > wrote: Hi Chris, This is one of those tests that doesn't need any of the extra options, we're simply verifying the error message. There are several cases where we shouldn't pass the flags and I think this might be one of them. Thanks, Christian From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Wednesday, February 5, 2014 11:03 PM To: Christian Tornqvist Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message Not so much about this particular change but the way testing is done. I don't really like how we are spawning other Java processes: 41 ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-cp", ".", "ClassFile"); As far as I can see there is no code that passes on the flags which are defined with either -vmoption or JAVA_VM_ARGS. If I tell the testing framework to use a particular flag then I expect all Java processes to use them. Can we please change that? On Feb 5, 2014, at 7:19 PM, Christian Tornqvist < christian.tornqvist at oracle.com> wrote: Hi everyone, This change is about making the UnsupportedClassVersionError message a bit more user friendly. Webrev can be found at: http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8016644 Thanks, Christian From goetz.lindenmaier at sap.com Fri Feb 7 04:01:15 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Feb 2014 12:01:15 +0000 Subject: Usage of C++ features In-Reply-To: <55670517.mQ9jZp9EHK@mgerdin03> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <52F371B7.1000401@oracle.com> <55670517.mQ9jZp9EHK@mgerdin03> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA007B@DEWDFEMB12A.global.corp.sap> Hi, Thanks a lot for all the feedback! To summarize, there is nothing in the pipe besides the exceptions in the compiler, but the desire to use new features/stl once compiler issues are resolved. > I have this lingering feeling that we shouldn't need to use template template > parameters for the binaryTreeDictionary code but I haven't experimented with Yes Mikael, you are right. You don't need them. I would appreciate a lot if the following webrev would be considered as contribution to jdk9 and jdk8u20. http://cr.openjdk.java.net/~goetz/webrevs/rm_tmptmp_param/ If I don't get any objections I'll open a bug and mail a proper RFR? I compiled it on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with SS12u1. I tested dbg, fdbg and opt builds. I did some simple tests. Tonight the change will run with all our tests on the ppc port, build on windows and sparc included. Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Donnerstag, 6. Februar 2014 12:56 To: hotspot-dev at openjdk.java.net Cc: David Holmes; Lindenmaier, Goetz Subject: Re: Usage of C++ features On Thursday 06 February 2014 21.27.51 David Holmes wrote: > Hi Goetz, > > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > wrt. our (SAPs) various ports which are running on old machines, built > > with old compilers for compatibility, I would like to find out about > > the OpenJDK policy regarding 'real' C++ features. > > I don't think there is such a thing as "OpenJDK policy" for this. Things > need to be evaluated on their merits taking into account a range of > factors, including compiler compatibility issues. > > > Recently, we found increasing usage of C++ features. > > > > - 'throw()' in nmethod operator new > > > - usage of namespace std:: > AFAICS only std::nothrow is in use, which combines with the use of > throw() in numerous (most?) operator new definitions to make it clear > that these don't throw any exceptions. > > That said the compiler folk have expressed interest in using C++ > exceptions within the compiler. > > > - template template parameters in binaryTreeDictionary.hpp|cpp > > Can't comment on that. I have this lingering feeling that we shouldn't need to use template template parameters for the binaryTreeDictionary code but I haven't experimented with it. I'd prefer to simplify that just for the sake of sanity. /Mikael > > > We would like to know whether you are planning to increase the > > usage of C++ or even use C++11 features. Or, whether you are planning > > to keep the policy to avoid C++ features that caused problems to > > compilers in the past. > > I can envisage usage of C++11 atomics at some point. But it depends on > it being supported across sufficient compilers. What else is coming in > C++11? > > I think everything has to be considered on a case-by-case basis. You > presumably have some things in mind ? > > Just my 2c. I'm not a policy maker. :) > > Cheers, > David > > > Best regards, > > > > Goetz. From david.holmes at oracle.com Fri Feb 7 04:09:54 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Feb 2014 22:09:54 +1000 Subject: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message In-Reply-To: <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> References: <01ed01cf22ea$430d4af0$c927e0d0$@oracle.com> <2FD9E106-8627-48F2-8849-C892B0B6733E@oracle.com> <02a601cf2381$2a2e3b60$7e8ab220$@oracle.com> <48645969-EC27-44A9-8BB4-96F4D84F2BA9@oracle.com> <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> Message-ID: <52F4CD12.6060507@oracle.com> Hi Christian, Looking only at the exception message changes these seem okay. Though I note that if we also disallow really early class file versions then this needs to be a range rather than a max. But lets worry about that if/when it is an issue :) Thanks, david On 7/02/2014 9:47 PM, Christian Tornqvist wrote: > Expanding this to hotspot-dev since I?m making changes to > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java as part > of this change. > > Updated the exception message and modified the test to allow options > sent via ?vmoption/-vmoptions in jtreg to be passed to the spawned Java > process. > > New webrev at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.01/ > > Thanks, > > Christian > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:* Thursday, February 6, 2014 4:46 PM > *To:* Christian Tornqvist > *Cc:* hotspot-runtime-dev at openjdk.java.net > *Subject:* Re: RFR(S): JDK-8016644 - Improve > UnsupportedClassVersionError message > > I respectfully disagree. If I want to e.g. run all tests in interpreted > mode for whatever reason (maybe there is a bug in the compiler and I > want to see if it happens in interpreted mode too) then I want ALL tests > to run with the flags I specify. No matter what they do. > > On Feb 6, 2014, at 1:19 PM, Christian Tornqvist > > > wrote: > > > > Hi Chris, > > This is one of those tests that doesn?t need any of the extra > options, we?re simply verifying the error message. There are several > cases where we shouldn?t pass the flags and I think this might be > one of them. > > Thanks, > > Christian > > *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com] > *Sent:*Wednesday, February 5, 2014 11:03 PM > *To:*Christian Tornqvist > *Cc:*hotspot-runtime-dev at openjdk.java.net > > *Subject:*Re: RFR(S): JDK-8016644 - Improve > UnsupportedClassVersionError message > > Not so much about this particular change but the way testing is > done. I don?t really like how we are spawning other Java processes: > > 41 ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-cp", ".", "ClassFile"); > > As far as I can see there is no code that passes on the flags which > are defined with either -vmoption or JAVA_VM_ARGS. If I tell the > testing framework to use a particular flag then I expect all Java > processes to use them. > > Can we please change that? > > On Feb 5, 2014, at 7:19 PM, Christian Tornqvist > > wrote: > > > > > Hi everyone, > > This change is about making the UnsupportedClassVersionError > message a bit more user friendly. > > Webrev can be found at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.00/ > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8016644 > > Thanks, > > Christian > From mikael.gerdin at oracle.com Fri Feb 7 04:33:19 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 07 Feb 2014 13:33:19 +0100 Subject: Usage of C++ features In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA007B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <55670517.mQ9jZp9EHK@mgerdin03> <4295855A5C1DE049A61835A1887419CC2CEA007B@DEWDFEMB12A.global.corp.sap> Message-ID: <3826568.9Ni48Uo8p4@mgerdin03> Hi Goetz, On Friday 07 February 2014 12.01.15 Lindenmaier, Goetz wrote: > Hi, > > Thanks a lot for all the feedback! To summarize, there is nothing in > the pipe besides the exceptions in the compiler, but the desire to > use new features/stl once compiler issues are resolved. > > > I have this lingering feeling that we shouldn't need to use template > > template parameters for the binaryTreeDictionary code but I haven't > > experimented with > Yes Mikael, you are right. You don't need them. > I would appreciate a lot if the following webrev would be > considered as contribution to jdk9 and jdk8u20. > http://cr.openjdk.java.net/~goetz/webrevs/rm_tmptmp_param/ > > If I don't get any objections I'll open a bug and mail a proper > RFR? As I hinted in my mail, I'd welcome this change. I had a quick look through the patches and I noticed that you removed a get_chunk from binaryTreeDictionary.cpp, you should remember to point that out when you send the RFR. Also, you forgot a - dictionary()->get_chunk(word_size, FreeBlockDictionary::atLeast); + dictionary()->get_chunk(word_size, FreeBlockDictionary::exactly); Do you have any further input on this? Are you running with exactly instead of atLeast here or is this just a mis- merge? We'd appreciate any feedback you have about the policy in this code. /Mikael > > I compiled it on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with > SS12u1. I tested dbg, fdbg and opt builds. I did some simple tests. > Tonight the change will run with all our tests on the ppc port, build on > windows and sparc included. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Donnerstag, 6. Februar 2014 12:56 > To: hotspot-dev at openjdk.java.net > Cc: David Holmes; Lindenmaier, Goetz > Subject: Re: Usage of C++ features > > On Thursday 06 February 2014 21.27.51 David Holmes wrote: > > Hi Goetz, > > > > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > wrt. our (SAPs) various ports which are running on old machines, built > > > with old compilers for compatibility, I would like to find out about > > > the OpenJDK policy regarding 'real' C++ features. > > > > I don't think there is such a thing as "OpenJDK policy" for this. Things > > need to be evaluated on their merits taking into account a range of > > factors, including compiler compatibility issues. > > > > > Recently, we found increasing usage of C++ features. > > > > > > - 'throw()' in nmethod operator new > > > > > - usage of namespace std:: > > AFAICS only std::nothrow is in use, which combines with the use of > > throw() in numerous (most?) operator new definitions to make it clear > > that these don't throw any exceptions. > > > > That said the compiler folk have expressed interest in using C++ > > exceptions within the compiler. > > > > > - template template parameters in binaryTreeDictionary.hpp|cpp > > > > Can't comment on that. > > I have this lingering feeling that we shouldn't need to use template > template parameters for the binaryTreeDictionary code but I haven't > experimented with it. > I'd prefer to simplify that just for the sake of sanity. > > /Mikael > > > > We would like to know whether you are planning to increase the > > > usage of C++ or even use C++11 features. Or, whether you are planning > > > to keep the policy to avoid C++ features that caused problems to > > > compilers in the past. > > > > I can envisage usage of C++11 atomics at some point. But it depends on > > it being supported across sufficient compilers. What else is coming in > > C++11? > > > > I think everything has to be considered on a case-by-case basis. You > > presumably have some things in mind ? > > > > Just my 2c. I'm not a policy maker. :) > > > > Cheers, > > David > > > > > Best regards, > > > > > > Goetz. From staffan.larsen at oracle.com Fri Feb 7 04:59:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Feb 2014 13:59:09 +0100 Subject: RFR(S): JDK-8033926 Update hotspot/make/jprt.properties to use jdk9 instead of jdk8 Message-ID: <9CCCBF7D-FCB7-4E50-BE0A-EC873C08327A@oracle.com> The first complete promoted build of jdk9 is now available and we can (finally) switch to using jdk9 in JPRT. Erik Joelson is currently updating the JPRT queues for jdk9. As soon as that work is done I will verify the proposed changes below by doing a complete JPRT run and then push the changes to hs-rt. The changes have already been tried out on the staging JPRT queue. webrev: http://cr.openjdk.java.net/~sla/8033926/webrev.00 Thanks, /Staffan From goetz.lindenmaier at sap.com Fri Feb 7 05:48:26 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Feb 2014 13:48:26 +0000 Subject: Usage of C++ features In-Reply-To: <3826568.9Ni48Uo8p4@mgerdin03> References: <4295855A5C1DE049A61835A1887419CC2CE9F965@DEWDFEMB12A.global.corp.sap> <55670517.mQ9jZp9EHK@mgerdin03> <4295855A5C1DE049A61835A1887419CC2CEA007B@DEWDFEMB12A.global.corp.sap> <3826568.9Ni48Uo8p4@mgerdin03> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA00D7@DEWDFEMB12A.global.corp.sap> Hi Mikael, I removed the get_chunk as it seems wrong and unused. It's a good point to mention it in the RFR. Thanks, the ::exact was a mismatch! I fixed the webrev. Thanks for your feedback, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Freitag, 7. Februar 2014 13:33 To: Lindenmaier, Goetz Cc: hotspot-dev at openjdk.java.net; David Holmes Subject: Re: Usage of C++ features Hi Goetz, On Friday 07 February 2014 12.01.15 Lindenmaier, Goetz wrote: > Hi, > > Thanks a lot for all the feedback! To summarize, there is nothing in > the pipe besides the exceptions in the compiler, but the desire to > use new features/stl once compiler issues are resolved. > > > I have this lingering feeling that we shouldn't need to use template > > template parameters for the binaryTreeDictionary code but I haven't > > experimented with > Yes Mikael, you are right. You don't need them. > I would appreciate a lot if the following webrev would be > considered as contribution to jdk9 and jdk8u20. > http://cr.openjdk.java.net/~goetz/webrevs/rm_tmptmp_param/ > > If I don't get any objections I'll open a bug and mail a proper > RFR? As I hinted in my mail, I'd welcome this change. I had a quick look through the patches and I noticed that you removed a get_chunk from binaryTreeDictionary.cpp, you should remember to point that out when you send the RFR. Also, you forgot a - dictionary()->get_chunk(word_size, FreeBlockDictionary::atLeast); + dictionary()->get_chunk(word_size, FreeBlockDictionary::exactly); Do you have any further input on this? Are you running with exactly instead of atLeast here or is this just a mis- merge? We'd appreciate any feedback you have about the policy in this code. /Mikael > > I compiled it on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with > SS12u1. I tested dbg, fdbg and opt builds. I did some simple tests. > Tonight the change will run with all our tests on the ppc port, build on > windows and sparc included. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] > Sent: Donnerstag, 6. Februar 2014 12:56 > To: hotspot-dev at openjdk.java.net > Cc: David Holmes; Lindenmaier, Goetz > Subject: Re: Usage of C++ features > > On Thursday 06 February 2014 21.27.51 David Holmes wrote: > > Hi Goetz, > > > > On 6/02/2014 8:33 PM, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > wrt. our (SAPs) various ports which are running on old machines, built > > > with old compilers for compatibility, I would like to find out about > > > the OpenJDK policy regarding 'real' C++ features. > > > > I don't think there is such a thing as "OpenJDK policy" for this. Things > > need to be evaluated on their merits taking into account a range of > > factors, including compiler compatibility issues. > > > > > Recently, we found increasing usage of C++ features. > > > > > > - 'throw()' in nmethod operator new > > > > > - usage of namespace std:: > > AFAICS only std::nothrow is in use, which combines with the use of > > throw() in numerous (most?) operator new definitions to make it clear > > that these don't throw any exceptions. > > > > That said the compiler folk have expressed interest in using C++ > > exceptions within the compiler. > > > > > - template template parameters in binaryTreeDictionary.hpp|cpp > > > > Can't comment on that. > > I have this lingering feeling that we shouldn't need to use template > template parameters for the binaryTreeDictionary code but I haven't > experimented with it. > I'd prefer to simplify that just for the sake of sanity. > > /Mikael > > > > We would like to know whether you are planning to increase the > > > usage of C++ or even use C++11 features. Or, whether you are planning > > > to keep the policy to avoid C++ features that caused problems to > > > compilers in the past. > > > > I can envisage usage of C++11 atomics at some point. But it depends on > > it being supported across sufficient compilers. What else is coming in > > C++11? > > > > I think everything has to be considered on a case-by-case basis. You > > presumably have some things in mind ? > > > > Just my 2c. I'm not a policy maker. :) > > > > Cheers, > > David > > > > > Best regards, > > > > > > Goetz. From thomas.schatzl at oracle.com Fri Feb 7 06:15:33 2014 From: thomas.schatzl at oracle.com (thomas.schatzl at oracle.com) Date: Fri, 07 Feb 2014 14:15:33 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20140207141544.2928062AC4@hg.openjdk.java.net> Changeset: 1bbccbe38470 Author: johnc Date: 2013-02-19 16:22 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1bbccbe38470 8006628: NEED_TEST for JDK-8002870 Summary: Regression test for 8000311. Verifies that PLABStats works with zero parallel GC threads. Reviewed-by: jmasa, johnc Contributed-by: Filipp Zhinkin + test/gc/8000311/Test8000311.java Changeset: 1448ebfef4f1 Author: tschatzl Date: 2014-02-07 12:44 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1448ebfef4f1 8033443: Test8000311 fails after latest changes to parallelize string and symbol table unlink Summary: When string and symbol table unlink are not performed in parallel, the claim index we check is not updated, and so a guarantee fails. Take this into account when checking the guarantee. Reviewed-by: brutisso, jwilhelm ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From staffan.larsen at oracle.com Fri Feb 7 06:46:15 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Feb 2014 15:46:15 +0100 Subject: RFR(S): JDK-8033926 Update hotspot/make/jprt.properties to use jdk9 instead of jdk8 In-Reply-To: <9CCCBF7D-FCB7-4E50-BE0A-EC873C08327A@oracle.com> References: <9CCCBF7D-FCB7-4E50-BE0A-EC873C08327A@oracle.com> Message-ID: <8D46E1B3-AF1E-414C-994A-2F5CB7A663ED@oracle.com> My test job on hotspotwest completed successfully: http://prt-web.us.oracle.com//archive/2014/02/2014-02-07-133458.staffan.hotspot/JobStatus.txt All queues except Stockholm have been updated to support jdk9. /Staffan On 7 feb 2014, at 13:59, Staffan Larsen wrote: > The first complete promoted build of jdk9 is now available and we can (finally) switch to using jdk9 in JPRT. Erik Joelson is currently updating the JPRT queues for jdk9. As soon as that work is done I will verify the proposed changes below by doing a complete JPRT run and then push the changes to hs-rt. The changes have already been tried out on the staging JPRT queue. > > webrev: http://cr.openjdk.java.net/~sla/8033926/webrev.00 > > Thanks, > /Staffan From neale at sinenomine.net Fri Feb 7 06:51:36 2014 From: neale at sinenomine.net (Neale Ferguson) Date: Fri, 7 Feb 2014 14:51:36 +0000 Subject: Error building hotspot with shark/zero In-Reply-To: <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net>, <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> Message-ID: <8951A8C6-EA2C-48EB-B9D9-A34C2C98B50A@sinenomine.net> I had intended sending the diffs, but didn't realize that when get_source.sh is executed it just sucks in the source files and doesn't use hg to get them. I had envisaged just doing a hg diff to get the patchset but now I'll have to go and do it manually. It may take some time as I have to do some work on the LLVM SystemZ JIT. Neale On Feb 6, 2014, at 4:48 PM, Christian Thalinger wrote: Can you talk to Andrew (CCed) about integrating your changes? On Feb 5, 2014, at 8:30 PM, Neale Ferguson > wrote: I simply followed the instructions and did a hg clone and then used the get_source script to populate everything. I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script. -------- Original message -------- From: Christian Thalinger Date:2014/02/05 23:14 (GMT-05:00) To: Neale Ferguson Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: https://bugs.openjdk.java.net/browse/JDK-7071823 On Feb 5, 2014, at 7:20 AM, Neale Ferguson > wrote: > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: > > Linking vm... > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' > sharedRuntime.o:(.bss+0x0): first defined here > sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' > sharedRuntime.o:(.bss+0x8): first defined here > sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' > sharedRuntime.o:(.bss+0x10): first defined here > sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' > sharedRuntime.o:(.bss+0x18): first defined here > sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' > sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so > make[6]: stat: libjvm.so: Too many levels of symbolic links > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. > > Neale > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > >> I haven?t tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let?s see if I can make it work... >> >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson > wrote: >> >>> Hi, >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >>> >>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >>> >>> line 72 looks like: >>> >>> llvm::Constant* get_external(const char* name, >>> const llvm::FunctionType* sig) { >>> return module()->getOrInsertFunction(name, sig); >>> } >>> >>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >>> >>> Neale >> > From goetz.lindenmaier at sap.com Fri Feb 7 07:02:18 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 7 Feb 2014 15:02:18 +0000 Subject: Error building hotspot with shark/zero In-Reply-To: <8951A8C6-EA2C-48EB-B9D9-A34C2C98B50A@sinenomine.net> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net>, <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> <8951A8C6-EA2C-48EB-B9D9-A34C2C98B50A@sinenomine.net> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA0141@DEWDFEMB12A.global.corp.sap> Hi Neale, it should be hg repositories. You have to go into /hotspot, in there hg diff should work. The get_source script pulls several independent hg repositories into the main you already pulled. Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Neale Ferguson Sent: Freitag, 7. Februar 2014 15:52 To: Christian Thalinger Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero I had intended sending the diffs, but didn't realize that when get_source.sh is executed it just sucks in the source files and doesn't use hg to get them. I had envisaged just doing a hg diff to get the patchset but now I'll have to go and do it manually. It may take some time as I have to do some work on the LLVM SystemZ JIT. Neale On Feb 6, 2014, at 4:48 PM, Christian Thalinger wrote: Can you talk to Andrew (CCed) about integrating your changes? On Feb 5, 2014, at 8:30 PM, Neale Ferguson > wrote: I simply followed the instructions and did a hg clone and then used the get_source script to populate everything. I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script. -------- Original message -------- From: Christian Thalinger Date:2014/02/05 23:14 (GMT-05:00) To: Neale Ferguson Cc: hotspot-dev at openjdk.java.net Subject: Re: Error building hotspot with shark/zero This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: https://bugs.openjdk.java.net/browse/JDK-7071823 On Feb 5, 2014, at 7:20 AM, Neale Ferguson > wrote: > Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: > > Linking vm... > sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': > sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' > sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here > sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' > sharedRuntime.o:(.bss+0x0): first defined here > sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' > sharedRuntime.o:(.bss+0x8): first defined here > sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' > sharedRuntime.o:(.bss+0x10): first defined here > sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' > sharedRuntime.o:(.bss+0x18): first defined here > sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' > sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so > make[6]: stat: libjvm.so: Too many levels of symbolic links > > Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. > > Neale > > On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: > >> I haven't tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let's see if I can make it work... >> >> On Feb 3, 2014, at 11:50 AM, Neale Ferguson > wrote: >> >>> Hi, >>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >>> >>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >>> >>> line 72 looks like: >>> >>> llvm::Constant* get_external(const char* name, >>> const llvm::FunctionType* sig) { >>> return module()->getOrInsertFunction(name, sig); >>> } >>> >>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >>> >>> Neale >> > From neale at sinenomine.net Fri Feb 7 07:08:31 2014 From: neale at sinenomine.net (Neale Ferguson) Date: Fri, 7 Feb 2014 15:08:31 +0000 Subject: Error building hotspot with shark/zero In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA0141@DEWDFEMB12A.global.corp.sap> References: <94AA92B7-D2B1-4752-B294-ECB80DBBEAD9@oracle.com> <82CCC11B-C7BB-4D56-B91F-8C07C54367DC@sinenomine.net>, <0B0729D8-1F58-4CB2-88E7-1578E2F95131@oracle.com> <7D900B71-D831-4D94-B405-D83B3947E7A2@oracle.com> <8951A8C6-EA2C-48EB-B9D9-A34C2C98B50A@sinenomine.net> <4295855A5C1DE049A61835A1887419CC2CEA0141@DEWDFEMB12A.global.corp.sap> Message-ID: D'oh! That's great. I'll hg diff and post On Feb 7, 2014, at 10:02 AM, Lindenmaier, Goetz wrote: > Hi Neale, > > it should be hg repositories. You have to go into /hotspot, in there hg diff should > work. > > The get_source script pulls several independent hg repositories into the > main you already pulled. > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Neale Ferguson > Sent: Freitag, 7. Februar 2014 15:52 > To: Christian Thalinger > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Error building hotspot with shark/zero > > I had intended sending the diffs, but didn't realize that when get_source.sh is executed it just sucks in the source files and doesn't use hg to get them. I had envisaged just doing a hg diff to get the patchset but now I'll have to go and do it manually. It may take some time as I have to do some work on the LLVM SystemZ JIT. > > Neale > > On Feb 6, 2014, at 4:48 PM, Christian Thalinger wrote: > > Can you talk to Andrew (CCed) about integrating your changes? > > On Feb 5, 2014, at 8:30 PM, Neale Ferguson > wrote: > > I simply followed the instructions and did a hg clone and then used the get_source script to populate everything. > > I did find a patch that removed generate_stubs etc and things ran to completion. There were certain methods that needed adding to sharkMemoryManager such as allocateCodeSection. Other issues included createPHI and CreateCall parameters having changed. Also llvm-config --ldflags doesn't return -lot info so I had to provide a quick and dirty fix to the generic profile script. > > > -------- Original message -------- > From: Christian Thalinger > Date:2014/02/05 23:14 (GMT-05:00) > To: Neale Ferguson > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Error building hotspot with shark/zero > > This is odd. What version of OpenJDK 7 are you using as this got fixed a long time ago: > > https://bugs.openjdk.java.net/browse/JDK-7071823 > > On Feb 5, 2014, at 7:20 AM, Neale Ferguson > wrote: > >> Getting closer with LLVM 3.4 and openJDK. Everything compiles cleanly now but I now crap out with: >> >> Linking vm... >> sharedRuntime_zero.o: In function `SharedRuntime::generate_stubs()': >> sharedRuntime_zero.cpp:(.text+0x3bc): multiple definition of `SharedRuntime::generate_stubs()' >> sharedRuntime.o:sharedRuntime.cpp:(.text+0x1328): first defined here >> sharedRuntime_zero.o:(.bss+0x18): multiple definition of `SharedRuntime::_wrong_method_blob' >> sharedRuntime.o:(.bss+0x0): first defined here >> sharedRuntime_zero.o:(.bss+0x20): multiple definition of `SharedRuntime::_ic_miss_blob' >> sharedRuntime.o:(.bss+0x8): first defined here >> sharedRuntime_zero.o:(.bss+0x28): multiple definition of `SharedRuntime::_resolve_opt_virtual_call_blob' >> sharedRuntime.o:(.bss+0x10): first defined here >> sharedRuntime_zero.o:(.bss+0x30): multiple definition of `SharedRuntime::_resolve_virtual_call_blob' >> sharedRuntime.o:(.bss+0x18): first defined here >> sharedRuntime_zero.o:(.bss+0x38): multiple definition of `SharedRuntime::_resolve_static_call_blob' >> sharedRuntime.o:(.bss+0x20): first defined heresharedRuntime_zero.o:(.bss+0x8): multiple definition of `SharedRuntime::_polling_page_safepoint_handler_blob'sharedRuntime.o:(.bss+0x38): first defined heresharedRuntime_zero.o:(.bss+0x10): multiple definition of `SharedRuntime::_polling_page_return_handler_blob'sharedRuntime.o:(.bss+0x40): first defined heresharedRuntime_zero.o:(.bss+0x0): multiple definition of `SharedRuntime::_deopt_blob'sharedRuntime.o:(.bss+0x28): first defined herecollect2: ld returned 1 exit statusln: accessing `libjvm.so.1': Too many levels of symbolic links/usr/bin/chcon: failed to get security context of `libjvm.so': Too many levels of symbolic linksERROR: Cannot chcon libjvm.so >> make[6]: stat: libjvm.so: Too many levels of symbolic links >> >> Both sharedRuntime.cpp and sharedRuntime_zero.cpp have generate_stubs defined and there doesn't appear to be conditional logic that needs to be triggered to stop it, so is it a Makefile thing? As for the "too many levels of symbolic links", because the link failed the symlink ends up pointing to itself. >> >> Neale >> >> On Feb 3, 2014, at 7:08 PM, Christian Thalinger wrote: >> >>> I haven't tried LLVM 3.4 yet (compiling it right now) but it seems some method signatures have changed. Let's see if I can make it work... >>> >>> On Feb 3, 2014, at 11:50 AM, Neale Ferguson > wrote: >>> >>>> Hi, >>>> I'm attempting build openJDK7 with SHARK/ZERO and am encountering the following when using llvm-3.4: >>>> >>>> In file included from /home/neale/openjdk7/hotspot/src/share/vm/shark/llvmValue.hpp:30, >>>> from /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkBlock.cpp:29: >>>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp: In member function 'llvm::Constant* SharkContext::get_external(const char*, const llvm::FunctionType*)': >>>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: invalid conversion from 'const llvm::FunctionType*' to 'llvm::FunctionType*' >>>> /home/neale/openjdk7/hotspot/src/share/vm/shark/sharkContext.hpp:72: error: initializing argument 2 of 'llvm::Constant* llvm::Module::getOrInsertFunction(llvm::StringRef, llvm::FunctionType*)' >>>> >>>> line 72 looks like: >>>> >>>> llvm::Constant* get_external(const char* name, >>>> const llvm::FunctionType* sig) { >>>> return module()->getOrInsertFunction(name, sig); >>>> } >>>> >>>> Before I go too far with this I thought I'd find out if this was a known issue. I note there were other issues getting this far, like where 3.4 keeps its include files (in /usr/include/llvm/IR/...) so there are probably other changes of significance. >>>> >>>> Neale >>> >> > > From gnu.andrew at redhat.com Fri Feb 7 07:53:28 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Feb 2014 10:53:28 -0500 (EST) Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F4322B.60700@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F41505.3000401@oracle.com> <52F4322B.60700@oracle.com> Message-ID: <447461755.6133793.1391788408687.JavaMail.root@redhat.com> ----- Original Message ----- > > I just got the patch from Andrews > not sure what testing he did. > Andrew? > > I'm in the process of submitting a control job, > was planning to do the hotspot one during the submission > This is a backport from 8 > Full build on x86_64, as shown in my post. I can't do JPRT builds as we don't have access to this (still). > Thanks > Alejandro > > > On 2/6/2014 4:04 PM, Vladimir Kozlov wrote: > > Did these changes pass all our builds on all platforms? I mean Hotspot > > builds and Full forest control builds in JPRT. > > > > Thanks, > > Vladimir > > > > On 2/6/14 2:10 PM, Alejandro E Murillo wrote: > >> I forgot to change the "subject". > >> The change is and has been approved for 7u60 (hs24.60) > >> Thanks > >> > >> Alejandro > >> > >> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: > >>> > >>> can we get 2 hotspot reviewers quickly check this change ? > >>> thanks > >>> Alejandro > >>> > >>> -------- Original Message -------- > >>> Subject: Re: Question on 8024648 : 8016131 breaks Zero port > >>> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) > >>> From: Andrew Hughes > >>> To: Alejandro E Murillo > >>> CC: Se?n Coffey , Omair Majid > >>> , jdk7u-dev at openjdk.java.net > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> > >>> > >>> Here's the webrev: > >>> > >>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ > >>> > >>> My OpenJDK username is andrew (should already be included in the > >>> commit) > >>> > >>> The changes are as follows: > >>> > >>> * Bring in defs.make to a number of makefiles which expect > >>> JVM_VARIANT_ZERO > >>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that > >>> sets > >>> it. This is a regression caused by the new build which instead sets > >>> these > >>> via configure and $(SPEC). There is code for handling the old build > >>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) > >>> * Update the call_wrapper function following 8024648. > >>> > >>> I've updated the bug summary to reflect that it fixes changes from both > >>> bugs, but we can split them into two separate bugs if you prefer. > >>> Without > >>> the 7141246 fix, the build fails in seconds. > >>> > >>> With the webrev applied: > >>> > >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version > >>> openjdk version "1.7.0-internal" > >>> OpenJDK Runtime Environment (build > >>> 1.7.0-internal-andrew_2014_02_06_19_43-b00) > >>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) > >>> > >>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld > >>> Hello World > >>> > >>> > >> > > -- > Alejandro > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri Feb 7 08:11:12 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 7 Feb 2014 11:11:12 -0500 (EST) Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F46BA9.3060204@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> Message-ID: <722720902.6144853.1391789472697.JavaMail.root@redhat.com> ----- Original Message ----- > I have a concern here. > > First this general situation is a mess. We started adding the new-build > support in hs24 but JDK 8 is using hs25, so all this SPEC and > JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here > would be to get this stuff backed out of 7u and return to a completely > configure-ignorant build system. That said I'm not sure that is really > the issue with ZERO/SHARK builds. > Backing out: 7141246: build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built Reviewed-by: dholmes, ohair would also work, or at least the Zero/Shark changes there. I note you reviewed this, but it clearly wasn't tested with Zero. With this change introduced, a Zero build can't even find its makefiles any more. > My concern with the proposed patch is that defs.make is not intended to > be included by every other Makefile and/or .make file. We all know by > now that the hotspot build system is complex, convoluted and fragile. > When you do a hotspot build there are multiple nested sub-makes > involved, as well as build file generation and use. The "big picture" > intent is that defs.make contains all the high-level stuff needed by the > "top" level makefile targets. buildtree.make will then generate other > .make files using that information. It is very difficult to see exactly > which .make file will get used by which phase of the overall build. > Unfortunately this leads to a tendency where if a "low-level" file needs > access to X, which is defined in defs.make, then the "solution" is just > to include defs.make in that file. We did the same thing for > buildtree.make in JDK 8. But I have reservations about also doing it for > gcc.make and vm.make. I think it is the wrong solution - we should be > passing the needed variables/values through the files generated by > buildtree.make. > Each change was introduced separately in IcedTea, as they were caught at different times. changeset: 4224:a57f19258524 user: andrew date: Fri Jan 04 22:21:54 2013 +0000 summary: Include defs.make in buildtree.make so ZERO_BUILD is recognised and JVM_VARIANT_ZERO set. changeset: 4894:56f4e181b8d4 user: andrew date: Wed Sep 11 16:55:12 2013 +0100 summary: Set ZERO_BUILD in flags.make so it is set on rebuilds changeset: 4971:02f0bce4ac32 user: andrew date: Tue Nov 12 17:58:35 2013 +0000 summary: Include defs.make in vm.make so VM_LITTLE_ENDIAN is defined on Zero builds I agree it may not be the best solution for all, which is why I only fixed buildtree.make at first, where it's most obviously wrong. However, I don't know the makefiles well enough to suggest another solution and just adding defs.make does work for us. We did have another solution for gcc.make, at least for the Zero part: changeset: 4279:4fd8e7ebca9a parent: 4260:7e12b7098f20 user: andrew date: Thu Jan 17 12:07:28 2013 +0000 summary: Make sure libffi cflags and libs are used. diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/gcc.make --- a/make/linux/makefiles/gcc.make Mon Jan 14 16:38:37 2013 +0000 +++ b/make/linux/makefiles/gcc.make Thu Jan 17 12:07:28 2013 +0000 @@ -75,9 +75,6 @@ VM_PICFLAG/AOUT = VM_PICFLAG = $(VM_PICFLAG/$(LINK_INTO)) -ifeq ($(JVM_VARIANT_ZERO), true) -CFLAGS += $(LIBFFI_CFLAGS) -endif ifeq ($(JVM_VARIANT_ZEROSHARK), true) CFLAGS += $(LIBFFI_CFLAGS) CFLAGS += $(LLVM_CFLAGS) diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/vm.make --- a/make/linux/makefiles/vm.make Mon Jan 14 16:38:37 2013 +0000 +++ b/make/linux/makefiles/vm.make Thu Jan 17 12:07:28 2013 +0000 @@ -284,9 +284,6 @@ LIBS_VM += $(LIBS) endif -ifeq ($(JVM_VARIANT_ZERO), true) - LIBS_VM += $(LIBFFI_LIBS) -endif ifeq ($(JVM_VARIANT_ZEROSHARK), true) LIBS_VM += $(LIBFFI_LIBS) $(LLVM_LIBS) LFLAGS_VM += $(LLVM_LDFLAGS) diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/zero.make --- a/make/linux/makefiles/zero.make Mon Jan 14 16:38:37 2013 +0000 +++ b/make/linux/makefiles/zero.make Thu Jan 17 12:07:28 2013 +0000 @@ -30,3 +30,7 @@ # Install libjvm.so, etc in in server directory. VM_SUBDIR = server + +# Make sure libffi is included +CFLAGS += $(LIBFFI_CFLAGS) +LIBS_VM += $(LIBFFI_LIBS) That leaves Shark still broken but maybe something similar could be done with the LLVM flags instead. I haven't tested Shark with this patch and that's much more involved. I've also never had a working build of it anyway. > If this was to go ahead as-is I would want to know that there has been a > comparison of all the build commands before and after to ensure no > unintended changes have been introduced. A set of successful builds is > not in itself sufficient. Assuming you run jdk_generic_profile.sh first, setting ZERO_BUILD=true is sufficient to build Zero. > > David > > On 7/02/2014 8:10 AM, Alejandro E Murillo wrote: > > I forgot to change the "subject". > > The change is and has been approved for 7u60 (hs24.60) > > Thanks > > > > Alejandro > > > > On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: > >> > >> can we get 2 hotspot reviewers quickly check this change ? > >> thanks > >> Alejandro > >> > >> -------- Original Message -------- > >> Subject: Re: Question on 8024648 : 8016131 breaks Zero port > >> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) > >> From: Andrew Hughes > >> To: Alejandro E Murillo > >> CC: Se?n Coffey , Omair Majid > >> , jdk7u-dev at openjdk.java.net > >> > >> > >> > >> ----- Original Message ----- > >> > >> > >> Here's the webrev: > >> > >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ > >> > >> My OpenJDK username is andrew (should already be included in the commit) > >> > >> The changes are as follows: > >> > >> * Bring in defs.make to a number of makefiles which expect > >> JVM_VARIANT_ZERO > >> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that > >> sets > >> it. This is a regression caused by the new build which instead sets these > >> via configure and $(SPEC). There is code for handling the old build > >> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) > >> * Update the call_wrapper function following 8024648. > >> > >> I've updated the bug summary to reflect that it fixes changes from both > >> bugs, but we can split them into two separate bugs if you prefer. Without > >> the 7141246 fix, the build fails in seconds. > >> > >> With the webrev applied: > >> > >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version > >> openjdk version "1.7.0-internal" > >> OpenJDK Runtime Environment (build > >> 1.7.0-internal-andrew_2014_02_06_19_43-b00) > >> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) > >> > >> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld > >> Hello World > >> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sergei.kovalev at oracle.com Fri Feb 7 02:10:24 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 07 Feb 2014 14:10:24 +0400 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof Message-ID: <52F4B110.1020206@oracle.com> Hello everyone, I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. The issue reproducible only on the host where it was initially discovered. For testing I chose demo/jvmti/hprof/OptionsTest.java test. I identified that failure occurs only with below sequence: hprof = new DemoRun("hprof", "cpu=times,depth=0"); hprof = new DemoRun("hprof", "cpu=old,depth=0"); here second line leads to fail with probability 1/10000. Using process monitor "ProcMon" by Sysinternals I discovered that issue caused by slippage in delete operation. According event log: Normal file system operations looks like: "3:21:16.7185415 AM","java.exe","3532","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created" Operation that leads to fail: "3:52:30.6024647 AM","java.exe","3924","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","*DELETE PENDING*","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0" So this is not the test issue. To avoid IO operation failures I propose to use unique file name for each iteration. In this case test would not overwrite file and would not depend on filesystem performance. For example above code will looks like: hprof = new DemoRun("options", "cpu=old,depth=0"); hprof = new DemoRun("optins1", "depth=0"); Please let me know if you have any comments or suggestion. -- With best regards, Sergei From coleen.phillimore at oracle.com Fri Feb 7 08:31:46 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Feb 2014 11:31:46 -0500 Subject: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message In-Reply-To: <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> References: <01ed01cf22ea$430d4af0$c927e0d0$@oracle.com> <2FD9E106-8627-48F2-8849-C892B0B6733E@oracle.com> <02a601cf2381$2a2e3b60$7e8ab220$@oracle.com> <48645969-EC27-44A9-8BB4-96F4D84F2BA9@oracle.com> <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> Message-ID: <52F50A72.4060402@oracle.com> Nice. Now an informative message. Thanks, Coleen On 2/7/14 6:47 AM, Christian Tornqvist wrote: > Expanding this to hotspot-dev since I'm making changes to > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java as part of > this change. > > > > Updated the exception message and modified the test to allow options sent > via -vmoption/-vmoptions in jtreg to be passed to the spawned Java process. > > > > New webrev at: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.01/ > > > > Thanks, > > Christian > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, February 6, 2014 4:46 PM > To: Christian Tornqvist > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError > message > > > > I respectfully disagree. If I want to e.g. run all tests in interpreted > mode for whatever reason (maybe there is a bug in the compiler and I want to > see if it happens in interpreted mode too) then I want ALL tests to run with > the flags I specify. No matter what they do. > > > > On Feb 6, 2014, at 1:19 PM, Christian Tornqvist > > > wrote: > > > > > > Hi Chris, > > > > This is one of those tests that doesn't need any of the extra options, we're > simply verifying the error message. There are several cases where we > shouldn't pass the flags and I think this might be one of them. > > > > Thanks, > > Christian > > > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, February 5, 2014 11:03 PM > To: Christian Tornqvist > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError > message > > > > Not so much about this particular change but the way testing is done. I > don't really like how we are spawning other Java processes: > > 41 ProcessBuilder pb = > ProcessTools.createJavaProcessBuilder("-cp", ".", "ClassFile"); > > As far as I can see there is no code that passes on the flags which are > defined with either -vmoption or JAVA_VM_ARGS. If I tell the testing > framework to use a particular flag then I expect all Java processes to use > them. > > > > Can we please change that? > > > > On Feb 5, 2014, at 7:19 PM, Christian Tornqvist < > christian.tornqvist at oracle.com> > wrote: > > > > > > > Hi everyone, > > > > This change is about making the UnsupportedClassVersionError message a bit > more user friendly. > > > > Webrev can be found at: > > > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.00/ > > > > Bug: > > > https://bugs.openjdk.java.net/browse/JDK-8016644 > > > > Thanks, > > Christian > > > From dl at cs.oswego.edu Fri Feb 7 10:37:01 2014 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 07 Feb 2014 13:37:01 -0500 Subject: Draft JEP on enhanced volatiles Message-ID: <52F527CD.5040804@cs.oswego.edu> [To core-libs-dev; separately cross-posted to hotspot-dev and compiler-dev.] Now that the JMM update project is live (see http://openjdk.java.net/projects/jmm/), it would be helpful to get some preliminary feedback on one of its sure-to-be-needed counterparts: finally supporting a reasonable way to express atomic and/or ordered access operations beyond volatile-read/write. Some of you might know that the lack of these has often been discusses as a source of frustration and problems. One reason for nopt dealing with it sooner is the lack of a basis for even specifying such things, to be fixed with JMM update. But we also need some way for people to express them. The only good means for doing so appear to require a small amount of syntax support. Most people who have seen it seem to agree that the ".volatile" proposal below is the approach most likely to succeed. (We've considered a lot of others.) I'm hoping that members of libs, hotspot, and compiler groups can give it a sanity check before submitting (hopefully in a week or so). Thanks! Draft JEP proposal Title: Enhanced Volatiles Author: Doug Lea [...other metadata elided for now...] Summary ------- This JEP results in a means for programmers to invoke the equivalents of java.util.concurrent.atomic methods on volatile fields. Motivation ---------- As concurrent and parallel programming in Java continue to expand, programmers are increasingly frustrated by not being able to use Java constructions for arranging atomic operations for the fields of individual classes; for example atomically incrementing a "count" field. Until now the only ways to achieve these effects were to use a stand-alone AtomicInteger (adding both space overhead and additional concurrency issues to manage indirection) or, in some situations, to use atomic FieldUpdates (often encountering more overhead than the operation itself), or to use JVM Unsafe intrinsics. Because intrinsics are preferable on performance grounds, their use has been increasingly common, to the detriment of safety and portability. Without this JEP, these problems are expected to become worse as atomic APIs expand to cover additional access consistency policies (aligned with the recent C++11 memory model) as part of Java Memory Model revisions. Description ----------- The target solution requires a syntax enhancement, a few library enhancements, and compiler support. We model the extended operations on volatile integers via an interface VolatileInt, that also captures the functionality of AtomicInteger (which will also be updated to reflect Java Memory Model revisions as part of this JEP). A tentative version is below. Similar interfaces are needed for other primitive and reference types. We then enable access to corresponding methods for (typically volatile) fields using the ".volatile" prefix. For example: class Usage { volatile int count; int incrementCount() { return count.volatile.incrementAndGet(); } } The ".volatile" syntax is slightly unusual, but we are confident that it is syntactically unambiguous and semantically specifiable. New syntax is required to avoid ambiguities with existing usages, especially for volatile references -- invocations of methods on the reference versus the referent would be indistinguishable. The ".volatile" prefix introduces a scope for operations on these "L-values", not their retrieved contents. However, just using the prefix itself without a method invocation (as in "count.volatile;") would be meaningless and illegal. We also expect to allow volatile operations on array elements in addition to fields. The main task is to translate these calls into corresponding JVM intrinsics. The most likely option is for the source compiler to use method handles. This and other techniques are known to suffice, but are subject to further exploration. Minor enhancements to intrinsics and a few additional JDK library methods may also be needed. Here is a tentative VolatileInt interface. Those for other types are similar. The final released versions will surely differ in small ways. interface VolatileInt { int get(); int getRelaxed(); int getAcquire(); int getSequential(); void set(int x); void setRelaxed(int x); void setRelease(int x); void setSequential(int x); int getAndSet(int x); boolean compareAndSet(int e, int x); boolean compareAndSetAcquire(int e, int x); boolean compareAndSetRelease(int e, int x); boolean weakCompareAndSet(int e, int x); boolean weakCompareAndSetAcquire(int e, int x); boolean weakCompareAndSetRelease(int e, int x); int getAndAdd(int x); int addAndGet(int x); int getAndIncrement(); int incrementAndGet(); int getAndDecrement(); int decrementAndGet(); } Alternatives ------------ We considered instead introducing new forms of "value type" that support volatile operations. However, this would be inconsistent with properties of other types, and would also require more effort for programmers to use. We also considered expanding reliance on java.util.concurrent.atomic FieldUpdaters, but their dynamic overhead and usage limitations make them unsuitable. Several other alternatives (including those based on field references) have been raised and dismissed as unworkable on syntactic, efficiency, and/or usability grounds over the many years that these issues has been discussed. Risks and Assumptions --------------------- We are confident of feasibility. However, we expect that it will require more experimentation to arrive at compilation techniques that result in efficient enough implementation for routine use in the performance-critical contexts where these constructs are most often needed. The use of method handles may be impacted by and may impact JVM method handle support. Impact ------ A large number of usages in java.util.concurrent (and a few elsewhere in JDK) could be simplified and updated to use this support. From staffan.larsen at oracle.com Fri Feb 7 11:16:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 7 Feb 2014 20:16:28 +0100 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: <52F4B110.1020206@oracle.com> References: <52F4B110.1020206@oracle.com> Message-ID: Yes, using different output files for the different runs sounds like a good approach. I don?t think the argument to DemoRun() specifies the output file name, though. /Staffan On 7 feb 2014, at 11:10, Sergei Kovalev wrote: > Hello everyone, > > I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. > > The issue reproducible only on the host where it was initially discovered. > > For testing I chose demo/jvmti/hprof/OptionsTest.java test. I identified that failure occurs only with below sequence: > > hprof = new DemoRun("hprof", "cpu=times,depth=0"); > hprof = new DemoRun("hprof", "cpu=old,depth=0"); > > here second line leads to fail with probability 1/10000. Using process monitor "ProcMon" by Sysinternals I discovered that issue caused by slippage in delete operation. According event log: > > Normal file system operations looks like: > "3:21:16.7185415 AM","java.exe","3532","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created" > > Operation that leads to fail: > "3:52:30.6024647 AM","java.exe","3924","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","*DELETE PENDING*","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0" > > So this is not the test issue. > To avoid IO operation failures I propose to use unique file name for each iteration. In this case test would not overwrite file and would not depend on filesystem performance. > For example above code will looks like: > > hprof = new DemoRun("options", "cpu=old,depth=0"); > hprof = new DemoRun("optins1", "depth=0"); > > Please let me know if you have any comments or suggestion. > > -- > With best regards, > Sergei > From david.holmes at oracle.com Fri Feb 7 12:53:58 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 08 Feb 2014 06:53:58 +1000 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <722720902.6144853.1391789472697.JavaMail.root@redhat.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <722720902.6144853.1391789472697.JavaMail.root@redhat.com> Message-ID: <52F547E6.605@oracle.com> On 8/02/2014 2:11 AM, Andrew Hughes wrote: > ----- Original Message ----- >> I have a concern here. >> >> First this general situation is a mess. We started adding the new-build >> support in hs24 but JDK 8 is using hs25, so all this SPEC and >> JVM_VARIANT stuff is completely unwanted in JDK 7u. My preference here >> would be to get this stuff backed out of 7u and return to a completely >> configure-ignorant build system. That said I'm not sure that is really >> the issue with ZERO/SHARK builds. >> > > Backing out: > > 7141246: build-infra merge: Introduce new JVM_VARIANT* to control which kind of jvm gets built > Reviewed-by: dholmes, ohair > > would also work, or at least the Zero/Shark changes there. I note you > reviewed this, but it clearly wasn't tested with Zero. With this change > introduced, a Zero build can't even find its makefiles any more. We don't/can't test zero/shark. The situation has always been that the zero/shark communities need to check any changes and come back to us with patches when needed. Some engineers have been able to devote their own time to aiding in this area. Hopefully you saw my follow-up email with a proposed simpler fix. Thanks, David >> My concern with the proposed patch is that defs.make is not intended to >> be included by every other Makefile and/or .make file. We all know by >> now that the hotspot build system is complex, convoluted and fragile. >> When you do a hotspot build there are multiple nested sub-makes >> involved, as well as build file generation and use. The "big picture" >> intent is that defs.make contains all the high-level stuff needed by the >> "top" level makefile targets. buildtree.make will then generate other >> .make files using that information. It is very difficult to see exactly >> which .make file will get used by which phase of the overall build. >> Unfortunately this leads to a tendency where if a "low-level" file needs >> access to X, which is defined in defs.make, then the "solution" is just >> to include defs.make in that file. We did the same thing for >> buildtree.make in JDK 8. But I have reservations about also doing it for >> gcc.make and vm.make. I think it is the wrong solution - we should be >> passing the needed variables/values through the files generated by >> buildtree.make. >> > > Each change was introduced separately in IcedTea, as they were caught at > different times. > > changeset: 4224:a57f19258524 > user: andrew > date: Fri Jan 04 22:21:54 2013 +0000 > summary: Include defs.make in buildtree.make so ZERO_BUILD is recognised and JVM_VARIANT_ZERO set. > > changeset: 4894:56f4e181b8d4 > user: andrew > date: Wed Sep 11 16:55:12 2013 +0100 > summary: Set ZERO_BUILD in flags.make so it is set on rebuilds > > changeset: 4971:02f0bce4ac32 > user: andrew > date: Tue Nov 12 17:58:35 2013 +0000 > summary: Include defs.make in vm.make so VM_LITTLE_ENDIAN is defined on Zero builds > > I agree it may not be the best solution for all, which > is why I only fixed buildtree.make at first, where it's most obviously > wrong. However, I don't know the makefiles well enough to suggest another > solution and just adding defs.make does work for us. We did have another > solution for gcc.make, at least for the Zero part: > > changeset: 4279:4fd8e7ebca9a > parent: 4260:7e12b7098f20 > user: andrew > date: Thu Jan 17 12:07:28 2013 +0000 > summary: Make sure libffi cflags and libs are used. > > diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make Mon Jan 14 16:38:37 2013 +0000 > +++ b/make/linux/makefiles/gcc.make Thu Jan 17 12:07:28 2013 +0000 > @@ -75,9 +75,6 @@ > VM_PICFLAG/AOUT = > VM_PICFLAG = $(VM_PICFLAG/$(LINK_INTO)) > > -ifeq ($(JVM_VARIANT_ZERO), true) > -CFLAGS += $(LIBFFI_CFLAGS) > -endif > ifeq ($(JVM_VARIANT_ZEROSHARK), true) > CFLAGS += $(LIBFFI_CFLAGS) > CFLAGS += $(LLVM_CFLAGS) > diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/vm.make > --- a/make/linux/makefiles/vm.make Mon Jan 14 16:38:37 2013 +0000 > +++ b/make/linux/makefiles/vm.make Thu Jan 17 12:07:28 2013 +0000 > @@ -284,9 +284,6 @@ > > LIBS_VM += $(LIBS) > endif > -ifeq ($(JVM_VARIANT_ZERO), true) > - LIBS_VM += $(LIBFFI_LIBS) > -endif > ifeq ($(JVM_VARIANT_ZEROSHARK), true) > LIBS_VM += $(LIBFFI_LIBS) $(LLVM_LIBS) > LFLAGS_VM += $(LLVM_LDFLAGS) > diff -r 7e12b7098f20 -r 4fd8e7ebca9a make/linux/makefiles/zero.make > --- a/make/linux/makefiles/zero.make Mon Jan 14 16:38:37 2013 +0000 > +++ b/make/linux/makefiles/zero.make Thu Jan 17 12:07:28 2013 +0000 > @@ -30,3 +30,7 @@ > > # Install libjvm.so, etc in in server directory. > VM_SUBDIR = server > + > +# Make sure libffi is included > +CFLAGS += $(LIBFFI_CFLAGS) > +LIBS_VM += $(LIBFFI_LIBS) > > That leaves Shark still broken but maybe something similar could be done > with the LLVM flags instead. I haven't tested Shark with this patch and > that's much more involved. I've also never had a working build of it > anyway. > >> If this was to go ahead as-is I would want to know that there has been a >> comparison of all the build commands before and after to ensure no >> unintended changes have been introduced. A set of successful builds is >> not in itself sufficient. > > Assuming you run jdk_generic_profile.sh first, setting ZERO_BUILD=true > is sufficient to build Zero. > >> >> David >> >> On 7/02/2014 8:10 AM, Alejandro E Murillo wrote: >>> I forgot to change the "subject". >>> The change is and has been approved for 7u60 (hs24.60) >>> Thanks >>> >>> Alejandro >>> >>> On 2/6/2014 3:03 PM, Alejandro E Murillo wrote: >>>> >>>> can we get 2 hotspot reviewers quickly check this change ? >>>> thanks >>>> Alejandro >>>> >>>> -------- Original Message -------- >>>> Subject: Re: Question on 8024648 : 8016131 breaks Zero port >>>> Date: Thu, 6 Feb 2014 16:21:29 -0500 (EST) >>>> From: Andrew Hughes >>>> To: Alejandro E Murillo >>>> CC: Se?n Coffey , Omair Majid >>>> , jdk7u-dev at openjdk.java.net >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> >>>> Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/ >>>> >>>> My OpenJDK username is andrew (should already be included in the commit) >>>> >>>> The changes are as follows: >>>> >>>> * Bring in defs.make to a number of makefiles which expect >>>> JVM_VARIANT_ZERO >>>> or JVM_VARIANT_ZEROSHARK to be set, but don't parse the makefile that >>>> sets >>>> it. This is a regression caused by the new build which instead sets these >>>> via configure and $(SPEC). There is code for handling the old build >>>> (ZERO_BUILD=true) in defs.make but it isn't brought in. (see 7141246) >>>> * Update the call_wrapper function following 8024648. >>>> >>>> I've updated the bug summary to reflect that it fixes changes from both >>>> bugs, but we can split them into two separate bugs if you prefer. Without >>>> the 7141246 fix, the build fails in seconds. >>>> >>>> With the webrev applied: >>>> >>>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java -version >>>> openjdk version "1.7.0-internal" >>>> OpenJDK Runtime Environment (build >>>> 1.7.0-internal-andrew_2014_02_06_19_43-b00) >>>> OpenJDK 64-Bit Zero VM (build 24.80-b01, interpreted mode) >>>> >>>> $ /mnt/builder/hsx-jdk7u/j2sdk-image/bin/java HelloWorld >>>> Hello World >>>> >>>> >>> >> > From dean.long at oracle.com Fri Feb 7 13:06:14 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 07 Feb 2014 13:06:14 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> <52F41B7D.6090206@oracle.com> Message-ID: <52F54AC6.8020804@oracle.com> What's the cost for adding a new BufferBlob subtype? We already have AdapterBlob and MethodHandlesAdapterBlob. dl On 2/6/2014 3:52 PM, Oleg Mazurov wrote: > My understanding was that a buffer blob was just that - a buffer. Could potentially contain code fragments of different kinds. > Thus, is_buffer_blob() was the closest type available. Agree that a dependency on its name is not reliable, though testing > will reveal if the condition turns false for "vtable chunks" due to a name change (I had to deal with that particular test, Serguei > should be able to identify it). Adding a comment to where the name is defined (vtableStubs.cpp) that such a dependency exists > is a good idea. > Thanks, > > -- Oleg > > On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote: > >> Hi, I clicked on this a couple times. It seems okay but isn't there a safer way to identify code blobs that are vtable stubs, without looking at the name (which can change in while creating it). A comment at least when you create "vtable chunks" would be good. It seems that someone might want to rename it "vtable or itable buffers", or something like that. >> >> thanks, >> Coleen >> >> On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: >>> Runtime team, >>> >>> This fix was reviewed by Vladimir K. and me. >>> Just wanted to make sure if you would like to review it as well. >>> If not, then I will push it. >>> >>> Thanks, >>> Serguei >>> >>> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8025841 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >>>> >>>> Summary: >>>> >>>> The fix contributed by Oleg Mazurov to improve profiling data quality. >>>> It moves the "vtable stub" dynamic code notification to the right place. >>>> I've already reviewed the fix, and it looks good to me. >>>> >>>> Bug report description: >>>> >>>> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled when >>>> a new chunk of memory for subsequent vtable and itable stubs is allocated. >>>> That chunk is uninitialized (contains zeros or garbage) although due to the fact >>>> that the actual event delivery is deferred, at least one vtable comes out right. >>>> >>>> This event should describe an individual vtable/itable stub (base address and size) >>>> and only after it's been created (memory is actually populated with code). >>>> Where VM diagnostic messages about vtable/itable stubs are issued upon >>>> -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI events as well. >>>> >>>> Getting vtables/itables right is important in the context of performance analysis as >>>> that dynamically generated code may accumulate quite noticeable CPU time >>>> (especially itabes), sometimes larger than the actual Java methods called." >>>> >>>> >>>> Testing: >>>> Oleg tested it in the Oracle Studio Performance Analyzer environment. >>>> nsk.jvmti, nsk.jdi, nsk.jdwp, >>>> In progress: Jtreg com/sun/jdi, java/lang/instrument >>>> >>>> >>>> Thanks, >>>> Serguei >>>> From alejandro.murillo at oracle.com Fri Feb 7 13:13:15 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 07 Feb 2014 21:13:15 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.80-b01 for changeset 1448ebfef4f1 Message-ID: <20140207211317.DA24662ADE@hg.openjdk.java.net> Changeset: 653393f945e7 Author: amurillo Date: 2014-02-07 11:48 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/653393f945e7 Added tag hs24.80-b01 for changeset 1448ebfef4f1 ! .hgtags From coleen.phillimore at oracle.com Fri Feb 7 14:53:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 07 Feb 2014 17:53:56 -0500 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52EBB103.5090907@oracle.com> References: <52EBB103.5090907@oracle.com> Message-ID: <52F56404.4070206@oracle.com> On 1/31/14 9:19 AM, Dmitry Samersoff wrote: > Hi Everyone, > > I would like to start a discussion about future of hotspot debugger, > known as serviceability agent or SA. > > How you typically use it? What do you expect from it? What is missed? > > Please, share your stories and wishes. > > And please, fill the small quiz: > > 1. How often do you use SA? I tried once, but I think it was broken. > > 2. On what platform do you use SA? > > 3. Do you use it to analyze life processes or coredumps? I would use it to analyze core files, not live processes. I would only use the command line version not the web interface. > > 5. What other debuggers do you use to debug hotspot issues With permgen removal, native debuggers like gdb and dbx are very effective for looking at hotspot code, since Metadata are represented as C++ objects. Getting the name of methods and classes is still a bit tricky in a core file because there are a few levels of indirection. Also with FDS we can have native debug information from product builds which will help greatly for customer issues. I've said before that I believe the SA should be discontinued unless the problem of duplicated hotspot code in it can be resolved. We are in the process of changing many things in the code and the tax of a duplicate implementation in Java is too high. Find a way to use the libjvm.so or a libjvm_sa.so to retrieve hotspot internals. Coleen > > -Dmitry > From oleg.mazurov at oracle.com Fri Feb 7 15:55:53 2014 From: oleg.mazurov at oracle.com (Oleg Mazurov) Date: Fri, 07 Feb 2014 15:55:53 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F54AC6.8020804@oracle.com> References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> <52F41B7D.6090206@oracle.com> <52F54AC6.8020804@oracle.com> Message-ID: <52F57289.3080201@oracle.com> The cost might be minimal but that would be a move in the wrong direction in my opinion. A larger problem is that BufferBlobs being just placeholders for dynamic code should not be reported via JVMTI at all: when they are created they usually contain no executable code and actual objects placed into such blobs are reported separately (that wasn't true for vtable/itable stubs before this fix). That the same address, that of a BufferBlob and its first object, could be reported twice is revealed by a comment to a loop that follows the problematic comparison: src/share/vm/prims/jvmtiCodeBlobEvents.cpp: 124 // exclude VtableStubs, which are processed separately 125 if (cb->is_buffer_blob() && strcmp(cb->name(), "vtable chunks") == 0) { 126 return; 127 } 128 129 // check if this starting address has been seen already - the 130 // assumption is that stubs are inserted into the list before the 131 // enclosing BufferBlobs. 132 address addr = cb->code_begin(); 133 for (int i=0; i<_global_code_blobs->length(); i++) { 134 JvmtiCodeBlobDesc* scb = _global_code_blobs->at(i); 135 if (addr == scb->code_begin()) { 136 return; 137 } 138 } I believe that now that the vtable stub problem is fixed the need for that check is gone and both the strcmp() call and the following loop could be removed altogether, thus stopping further processing for *any* BufferBlob and avoiding a O(n^2) overhead they were causing. The scope of that change is much larger than the original problem entailed and would require not just additional ad hoc testing on the JMTI consumer side but also thorough statical analysis for all BufferBlob uses in the VM code. In fact, I was going to file a linked JIRA issue on that further improvement and if my idea for it holds true there would be no need for a new BufferBlob subtype. -- Oleg On 2/7/2014 1:06 PM, Dean Long wrote: > What's the cost for adding a new BufferBlob subtype? We already have > AdapterBlob and MethodHandlesAdapterBlob. > > dl > > On 2/6/2014 3:52 PM, Oleg Mazurov wrote: >> My understanding was that a buffer blob was just that - a buffer. >> Could potentially contain code fragments of different kinds. >> Thus, is_buffer_blob() was the closest type available. Agree that a >> dependency on its name is not reliable, though testing >> will reveal if the condition turns false for "vtable chunks" due to a >> name change (I had to deal with that particular test, Serguei >> should be able to identify it). Adding a comment to where the name is >> defined (vtableStubs.cpp) that such a dependency exists >> is a good idea. >> Thanks, >> >> -- Oleg >> >> On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote: >> >>> Hi, I clicked on this a couple times. It seems okay but isn't there >>> a safer way to identify code blobs that are vtable stubs, without >>> looking at the name (which can change in while creating it). A >>> comment at least when you create "vtable chunks" would be good. It >>> seems that someone might want to rename it "vtable or itable >>> buffers", or something like that. >>> >>> thanks, >>> Coleen >>> >>> On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: >>>> Runtime team, >>>> >>>> This fix was reviewed by Vladimir K. and me. >>>> Just wanted to make sure if you would like to review it as well. >>>> If not, then I will push it. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025841 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The fix contributed by Oleg Mazurov to improve profiling data >>>>> quality. >>>>> It moves the "vtable stub" dynamic code notification to the >>>>> right place. >>>>> I've already reviewed the fix, and it looks good to me. >>>>> >>>>> Bug report description: >>>>> >>>>> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets >>>>> scheduled when >>>>> a new chunk of memory for subsequent vtable and itable stubs >>>>> is allocated. >>>>> That chunk is uninitialized (contains zeros or garbage) >>>>> although due to the fact >>>>> that the actual event delivery is deferred, at least one >>>>> vtable comes out right. >>>>> >>>>> This event should describe an individual vtable/itable stub >>>>> (base address and size) >>>>> and only after it's been created (memory is actually >>>>> populated with code). >>>>> Where VM diagnostic messages about vtable/itable stubs are >>>>> issued upon >>>>> -XX:+PrintAdapterHandlers appears exactly the right place for >>>>> JVMTI events as well. >>>>> >>>>> Getting vtables/itables right is important in the context of >>>>> performance analysis as >>>>> that dynamically generated code may accumulate quite >>>>> noticeable CPU time >>>>> (especially itabes), sometimes larger than the actual Java >>>>> methods called." >>>>> >>>>> >>>>> Testing: >>>>> Oleg tested it in the Oracle Studio Performance Analyzer >>>>> environment. >>>>> nsk.jvmti, nsk.jdi, nsk.jdwp, >>>>> In progress: Jtreg com/sun/jdi, java/lang/instrument >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> > From dean.long at oracle.com Fri Feb 7 16:08:36 2014 From: dean.long at oracle.com (Dean Long) Date: Fri, 07 Feb 2014 16:08:36 -0800 Subject: Review Request (S) 8025841: JVMTI: "vtable stub" dynamic code notification is misplaced In-Reply-To: <52F57289.3080201@oracle.com> References: <52F01569.3070201@oracle.com> <52F41821.10403@oracle.com> <52F41B7D.6090206@oracle.com> <52F54AC6.8020804@oracle.com> <52F57289.3080201@oracle.com> Message-ID: <52F57584.70007@oracle.com> OK. Your further improvement idea sounds promising. dl On 2/7/2014 3:55 PM, Oleg Mazurov wrote: > The cost might be minimal but that would be a move in the wrong > direction in my opinion. > A larger problem is that BufferBlobs being just placeholders for > dynamic code should not be > reported via JVMTI at all: when they are created they usually contain > no executable code and > actual objects placed into such blobs are reported separately (that > wasn't true for vtable/itable > stubs before this fix). That the same address, that of a BufferBlob > and its first object, could be > reported twice is revealed by a comment to a loop that follows the > problematic comparison: > > src/share/vm/prims/jvmtiCodeBlobEvents.cpp: > > 124 // exclude VtableStubs, which are processed separately > 125 if (cb->is_buffer_blob() && strcmp(cb->name(), "vtable chunks") > == 0) { > 126 return; > 127 } > 128 > 129 // check if this starting address has been seen already - the > 130 // assumption is that stubs are inserted into the list before the > 131 // enclosing BufferBlobs. > 132 address addr = cb->code_begin(); > 133 for (int i=0; i<_global_code_blobs->length(); i++) { > 134 JvmtiCodeBlobDesc* scb = _global_code_blobs->at(i); > 135 if (addr == scb->code_begin()) { > 136 return; > 137 } > 138 } > > I believe that now that the vtable stub problem is fixed the need for > that check is gone > and both the strcmp() call and the following loop could be removed > altogether, thus stopping > further processing for *any* BufferBlob and avoiding a O(n^2) overhead > they were causing. > The scope of that change is much larger than the original problem > entailed and would require > not just additional ad hoc testing on the JMTI consumer side but also > thorough statical analysis > for all BufferBlob uses in the VM code. > In fact, I was going to file a linked JIRA issue on that further > improvement and if my idea for > it holds true there would be no need for a new BufferBlob subtype. > > -- Oleg > > On 2/7/2014 1:06 PM, Dean Long wrote: >> What's the cost for adding a new BufferBlob subtype? We already have >> AdapterBlob and MethodHandlesAdapterBlob. >> >> dl >> >> On 2/6/2014 3:52 PM, Oleg Mazurov wrote: >>> My understanding was that a buffer blob was just that - a buffer. >>> Could potentially contain code fragments of different kinds. >>> Thus, is_buffer_blob() was the closest type available. Agree that a >>> dependency on its name is not reliable, though testing >>> will reveal if the condition turns false for "vtable chunks" due to >>> a name change (I had to deal with that particular test, Serguei >>> should be able to identify it). Adding a comment to where the name >>> is defined (vtableStubs.cpp) that such a dependency exists >>> is a good idea. >>> Thanks, >>> >>> -- Oleg >>> >>> On Feb 6, 2014, at 3:32 PM, Coleen Phillimore wrote: >>> >>>> Hi, I clicked on this a couple times. It seems okay but isn't there >>>> a safer way to identify code blobs that are vtable stubs, without >>>> looking at the name (which can change in while creating it). A >>>> comment at least when you create "vtable chunks" would be good. >>>> It seems that someone might want to rename it "vtable or itable >>>> buffers", or something like that. >>>> >>>> thanks, >>>> Coleen >>>> >>>> On 2/6/14 6:17 PM, serguei.spitsyn at oracle.com wrote: >>>>> Runtime team, >>>>> >>>>> This fix was reviewed by Vladimir K. and me. >>>>> Just wanted to make sure if you would like to review it as well. >>>>> If not, then I will push it. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 2/3/14 2:17 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025841 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/omazurov/8025841-JVMTI-vtbl.1 >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The fix contributed by Oleg Mazurov to improve profiling data >>>>>> quality. >>>>>> It moves the "vtable stub" dynamic code notification to the >>>>>> right place. >>>>>> I've already reviewed the fix, and it looks good to me. >>>>>> >>>>>> Bug report description: >>>>>> >>>>>> "JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets >>>>>> scheduled when >>>>>> a new chunk of memory for subsequent vtable and itable stubs >>>>>> is allocated. >>>>>> That chunk is uninitialized (contains zeros or garbage) >>>>>> although due to the fact >>>>>> that the actual event delivery is deferred, at least one >>>>>> vtable comes out right. >>>>>> >>>>>> This event should describe an individual vtable/itable stub >>>>>> (base address and size) >>>>>> and only after it's been created (memory is actually >>>>>> populated with code). >>>>>> Where VM diagnostic messages about vtable/itable stubs are >>>>>> issued upon >>>>>> -XX:+PrintAdapterHandlers appears exactly the right place >>>>>> for JVMTI events as well. >>>>>> >>>>>> Getting vtables/itables right is important in the context of >>>>>> performance analysis as >>>>>> that dynamically generated code may accumulate quite >>>>>> noticeable CPU time >>>>>> (especially itabes), sometimes larger than the actual Java >>>>>> methods called." >>>>>> >>>>>> >>>>>> Testing: >>>>>> Oleg tested it in the Oracle Studio Performance Analyzer >>>>>> environment. >>>>>> nsk.jvmti, nsk.jdi, nsk.jdwp, >>>>>> In progress: Jtreg com/sun/jdi, java/lang/instrument >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >> > From alejandro.murillo at oracle.com Fri Feb 7 16:55:31 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 08 Feb 2014 00:55:31 +0000 Subject: hg: hsx/jdk7u/hotspot: 8033970: new hotspot build - hs24.80-b02 Message-ID: <20140208005536.4D9CE62AE5@hg.openjdk.java.net> Changeset: c78417e5c8aa Author: amurillo Date: 2014-02-07 12:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c78417e5c8aa 8033970: new hotspot build - hs24.80-b02 Reviewed-by: jcoomes ! make/hotspot_version From serguei.spitsyn at oracle.com Fri Feb 7 18:26:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 08 Feb 2014 02:26:37 +0000 Subject: hg: hsx/jdk7u/hotspot: 7 new changesets Message-ID: <20140208022652.84F9D62AEB@hg.openjdk.java.net> Changeset: 23c2ba8dc6b6 Author: sspitsyn Date: 2014-02-07 16:06 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/23c2ba8dc6b6 8008511: JSR 292: MemberName vmtarget refs to methods must be updated at class redefinition Summary: Lazily create and maintain the MemberNameTable to be able to update MemberName's Reviewed-by: coleenp, jrose, dholmes, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: 9423ca47562b Author: sspitsyn Date: 2014-02-07 16:08 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/9423ca47562b 8007037: JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands Summary: References from operands to CP entries and back must be correct after CP merge Reviewed-by: coleenp, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 347c7e0686dd Author: sspitsyn Date: 2014-02-07 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/347c7e0686dd 8014288: perf regression in nashorn JDK-8008448.js test after 8008511 changes Summary: The fix of perf regression is to use method_idnum() for direct indexing into NMT Reviewed-by: twisti, kvn, coleenp, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 1eeac0ff163c Author: sspitsyn Date: 2014-02-07 16:11 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1eeac0ff163c 8013945: CMS fatal error: must own lock MemberNameTable_lock Summary: The "delete mnt" needs to grab MemberNameTable_lock if !SafepointSynchronize::is_at_safepoint() Reviewed-by: sla, mgerdin, dholmes, jmasa, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/oops/instanceKlass.cpp Changeset: 079356ec5392 Author: sspitsyn Date: 2014-02-07 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/079356ec5392 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending Summary: A call to the finalize_operands_merge() must be unconditional Reviewed-by: kvn, twisti Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 8acfd52da1cf Author: sspitsyn Date: 2014-02-07 16:14 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/8acfd52da1cf Merge Changeset: bdb3798edd11 Author: sspitsyn Date: 2014-02-07 16:58 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/bdb3798edd11 Merge From rednaxelafx at gmail.com Fri Feb 7 18:34:49 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 7 Feb 2014 18:34:49 -0800 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52F56404.4070206@oracle.com> References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> Message-ID: Hi Coleen, Comments inline: On Fri, Feb 7, 2014 at 2:53 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > On 1/31/14 9:19 AM, Dmitry Samersoff wrote: > >> >> 1. How often do you use SA? >> > > I tried once, but I think it was broken. > > Was that CLHSDB you tried? There could be cases where you've used SA under the hood of some j-* tools, e.g. jstack -F/-m or on core dump, jmap -heap/-F or on core dump, etc. And yeah, SA can be broken from time to time...for the exact reason you mentioned below. > I've said before that I believe the SA should be discontinued unless the > problem of duplicated hotspot code in it can be resolved. We are in the > process of changing many things in the code and the tax of a duplicate > implementation in Java is too high. Find a way to use the libjvm.so or a > libjvm_sa.so to retrieve hotspot internals. > > Without a way to mechanically generate all the mirroring data structures, I'd concur on this point. But do please come up with a viable alternative before discontinuing SA. - Kris > Coleen > >> >> -Dmitry >> >> > From christian.thalinger at oracle.com Sat Feb 8 08:49:02 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 8 Feb 2014 08:49:02 -0800 Subject: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message In-Reply-To: <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> References: <01ed01cf22ea$430d4af0$c927e0d0$@oracle.com> <2FD9E106-8627-48F2-8849-C892B0B6733E@oracle.com> <02a601cf2381$2a2e3b60$7e8ab220$@oracle.com> <48645969-EC27-44A9-8BB4-96F4D84F2BA9@oracle.com> <001101cf23fa$72f838e0$58e8aaa0$@oracle.com> Message-ID: On Feb 7, 2014, at 3:47 AM, Christian Tornqvist wrote: > Expanding this to hotspot-dev since I?m making changes to test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java as part of this change. Thanks for doing that change. > > Updated the exception message and modified the test to allow options sent via ?vmoption/-vmoptions in jtreg to be passed to the spawned Java process. > > New webrev at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.01/ > > Thanks, > Christian > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Thursday, February 6, 2014 4:46 PM > To: Christian Tornqvist > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message > > I respectfully disagree. If I want to e.g. run all tests in interpreted mode for whatever reason (maybe there is a bug in the compiler and I want to see if it happens in interpreted mode too) then I want ALL tests to run with the flags I specify. No matter what they do. > > On Feb 6, 2014, at 1:19 PM, Christian Tornqvist wrote: > > > Hi Chris, > > This is one of those tests that doesn?t need any of the extra options, we?re simply verifying the error message. There are several cases where we shouldn?t pass the flags and I think this might be one of them. > > Thanks, > Christian > > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, February 5, 2014 11:03 PM > To: Christian Tornqvist > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): JDK-8016644 - Improve UnsupportedClassVersionError message > > Not so much about this particular change but the way testing is done. I don?t really like how we are spawning other Java processes: > 41 ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-cp", ".", "ClassFile"); > As far as I can see there is no code that passes on the flags which are defined with either -vmoption or JAVA_VM_ARGS. If I tell the testing framework to use a particular flag then I expect all Java processes to use them. > > Can we please change that? > > On Feb 5, 2014, at 7:19 PM, Christian Tornqvist wrote: > > > > Hi everyone, > > This change is about making the UnsupportedClassVersionError message a bit more user friendly. > > Webrev can be found at: > http://cr.openjdk.java.net/~ctornqvi/webrev/8016644/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8016644 > > Thanks, > Christian From christian.thalinger at oracle.com Sat Feb 8 09:13:14 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 8 Feb 2014 09:13:14 -0800 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52F56404.4070206@oracle.com> References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> Message-ID: On Feb 7, 2014, at 2:53 PM, Coleen Phillimore wrote: > > On 1/31/14 9:19 AM, Dmitry Samersoff wrote: >> Hi Everyone, >> >> I would like to start a discussion about future of hotspot debugger, >> known as serviceability agent or SA. >> >> How you typically use it? What do you expect from it? What is missed? >> >> Please, share your stories and wishes. >> >> And please, fill the small quiz: >> >> 1. How often do you use SA? > > I tried once, but I think it was broken. >> >> 2. On what platform do you use SA? >> >> 3. Do you use it to analyze life processes or coredumps? > > I would use it to analyze core files, not live processes. I would only use the command line version not the web interface. >> >> 5. What other debuggers do you use to debug hotspot issues > > With permgen removal, native debuggers like gdb and dbx are very effective for looking at hotspot code, since Metadata are represented as C++ objects. Getting the name of methods and classes is still a bit tricky in a core file because there are a few levels of indirection. Also with FDS we can have native debug information from product builds which will help greatly for customer issues. > > I've said before that I believe the SA should be discontinued unless the problem of duplicated hotspot code in it can be resolved. We are in the process of changing many things in the code and the tax of a duplicate implementation in Java is too high. Find a way to use the libjvm.so or a libjvm_sa.so to retrieve hotspot internals. The main problem, as I see it, is the lack of testing and self-verification. If the SA would do that as part of compilation we wouldn?t have a broken SA every other build. > > Coleen >> >> -Dmitry >> > From staffan.larsen at oracle.com Mon Feb 10 01:07:54 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Feb 2014 10:07:54 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> Message-ID: On 8 feb 2014, at 18:13, Christian Thalinger wrote: > > On Feb 7, 2014, at 2:53 PM, Coleen Phillimore wrote: > >> >> On 1/31/14 9:19 AM, Dmitry Samersoff wrote: >>> Hi Everyone, >>> >>> I would like to start a discussion about future of hotspot debugger, >>> known as serviceability agent or SA. >>> >>> How you typically use it? What do you expect from it? What is missed? >>> >>> Please, share your stories and wishes. >>> >>> And please, fill the small quiz: >>> >>> 1. How often do you use SA? >> >> I tried once, but I think it was broken. >>> >>> 2. On what platform do you use SA? >>> >>> 3. Do you use it to analyze life processes or coredumps? >> >> I would use it to analyze core files, not live processes. I would only use the command line version not the web interface. >>> >>> 5. What other debuggers do you use to debug hotspot issues >> >> With permgen removal, native debuggers like gdb and dbx are very effective for looking at hotspot code, since Metadata are represented as C++ objects. Getting the name of methods and classes is still a bit tricky in a core file because there are a few levels of indirection. Also with FDS we can have native debug information from product builds which will help greatly for customer issues. >> >> I've said before that I believe the SA should be discontinued unless the problem of duplicated hotspot code in it can be resolved. We are in the process of changing many things in the code and the tax of a duplicate implementation in Java is too high. Find a way to use the libjvm.so or a libjvm_sa.so to retrieve hotspot internals. > > The main problem, as I see it, is the lack of testing and self-verification. If the SA would do that as part of compilation we wouldn?t have a broken SA every other build. Word! /Staffan > >> >> Coleen >>> >>> -Dmitry From volker.simonis at gmail.com Mon Feb 10 01:47:41 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 10 Feb 2014 10:47:41 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52EBB103.5090907@oracle.com> References: <52EBB103.5090907@oracle.com> Message-ID: Hi, maybe slightly off-topic, but I want to ask if the SA agent needs the vtable symbols of all HS classes which are exported by partially generated mapfiles (make/linux/makefiles/build_vm_def.sh) during the linking of the VM. I recently found out (see this thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012426.html) that compiling the HS with gcc 4.3 and later deasn't export this symbols any more, even if they are listed in the map file. So the simple question is - does the SA agent relies on the vtable symbols beeing exported or not? If yes, we should think about a fix. If not, we should remove the magic which generates the vtable symbols in the map files (i.e. build_vm_def.sh) from the build. Regards, Volker PS: I didn't use SA agent until now although I think it is an intersecting tool. I mostly use the internal tools from utilities/debug.cpp. Another possibility used by some colleagues is to use the Python scripting capabilities offered by GDB to achieve a similar functionality. The downside of that approach is of course that is is platform-dependent (i.e. gdb-only). On Fri, Jan 31, 2014 at 3:19 PM, Dmitry Samersoff wrote: > Hi Everyone, > > I would like to start a discussion about future of hotspot debugger, > known as serviceability agent or SA. > > How you typically use it? What do you expect from it? What is missed? > > Please, share your stories and wishes. > > And please, fill the small quiz: > > 1. How often do you use SA? > > 2. On what platform do you use SA? > > 3. Do you use it to analyze life processes or coredumps? > > 5. What other debuggers do you use to debug hotspot issues > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sergei.kovalev at oracle.com Mon Feb 10 01:45:45 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 10 Feb 2014 13:45:45 +0400 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: References: <52F4B110.1020206@oracle.com> Message-ID: <52F89FC9.9090206@oracle.com> Staffan, Thank you for pointing this. You are right. Instead of the first argument we can slightly modify second one, and invocation commands will look like: hprof = new DemoRun("hprof", "cpu=old,depth=0,file=options.txt"); hprof = new DemoRun("hprof", "depth=0,file=options1.txt"); Does it work for you? -- With best regards, Sergei 07.02.2014 23:16, Staffan Larsen wrote: > Yes, using different output files for the different runs sounds like a good approach. I don?t think the argument to DemoRun() specifies the output file name, though. > > /Staffan > > On 7 feb 2014, at 11:10, Sergei Kovalev wrote: > >> Hello everyone, >> >> I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. >> >> The issue reproducible only on the host where it was initially discovered. >> >> For testing I chose demo/jvmti/hprof/OptionsTest.java test. I identified that failure occurs only with below sequence: >> >> hprof = new DemoRun("hprof", "cpu=times,depth=0"); >> hprof = new DemoRun("hprof", "cpu=old,depth=0"); >> >> here second line leads to fail with probability 1/10000. Using process monitor "ProcMon" by Sysinternals I discovered that issue caused by slippage in delete operation. According event log: >> >> Normal file system operations looks like: >> "3:21:16.7185415 AM","java.exe","3532","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created" >> >> Operation that leads to fail: >> "3:52:30.6024647 AM","java.exe","3924","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","*DELETE PENDING*","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0" >> >> So this is not the test issue. >> To avoid IO operation failures I propose to use unique file name for each iteration. In this case test would not overwrite file and would not depend on filesystem performance. >> For example above code will looks like: >> >> hprof = new DemoRun("options", "cpu=old,depth=0"); >> hprof = new DemoRun("optins1", "depth=0"); >> >> Please let me know if you have any comments or suggestion. >> >> -- >> With best regards, >> Sergei From dmitry.samersoff at oracle.com Mon Feb 10 01:52:20 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 10 Feb 2014 13:52:20 +0400 Subject: SA.NEXT - SA feedback needed In-Reply-To: References: <52EBB103.5090907@oracle.com> Message-ID: <52F8A154.8090102@oracle.com> Volker, For brief look SA doesn't need vtable symbols. But It's better to re-check it. Could you file a bug and assign it to me? -Dmitry On 2014-02-10 13:47, Volker Simonis wrote: > Hi, > > maybe slightly off-topic, but I want to ask if the SA agent needs the > vtable symbols of all HS classes which are exported by partially > generated mapfiles (make/linux/makefiles/build_vm_def.sh) during the > linking of the VM. > > I recently found out (see this thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012426.html) > that compiling the HS with gcc 4.3 and later deasn't export this > symbols any more, even if they are listed in the map file. > > So the simple question is - does the SA agent relies on the vtable > symbols beeing exported or not? If yes, we should think about a fix. > If not, we should remove the magic which generates the vtable symbols > in the map files (i.e. build_vm_def.sh) from the build. > > Regards, > Volker > > PS: I didn't use SA agent until now although I think it is an > intersecting tool. I mostly use the internal tools from > utilities/debug.cpp. Another possibility used by some colleagues is to > use the Python scripting capabilities offered by GDB to achieve a > similar functionality. The downside of that approach is of course that > is is platform-dependent (i.e. gdb-only). > > On Fri, Jan 31, 2014 at 3:19 PM, Dmitry Samersoff > wrote: >> Hi Everyone, >> >> I would like to start a discussion about future of hotspot debugger, >> known as serviceability agent or SA. >> >> How you typically use it? What do you expect from it? What is missed? >> >> Please, share your stories and wishes. >> >> And please, fill the small quiz: >> >> 1. How often do you use SA? >> >> 2. On what platform do you use SA? >> >> 3. Do you use it to analyze life processes or coredumps? >> >> 5. What other debuggers do you use to debug hotspot issues >> >> -Dmitry >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Feb 10 02:05:55 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Feb 2014 11:05:55 +0100 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: <52F89FC9.9090206@oracle.com> References: <52F4B110.1020206@oracle.com> <52F89FC9.9090206@oracle.com> Message-ID: <9BA31F9F-0B1B-434E-9095-D1FE7F87BA12@oracle.com> That looks like the right approach. /Staffan On 10 feb 2014, at 10:45, Sergei Kovalev wrote: > Staffan, > > Thank you for pointing this. You are right. Instead of the first argument we can slightly modify second one, and invocation commands will look like: > > hprof = new DemoRun("hprof", "cpu=old,depth=0,file=options.txt"); > hprof = new DemoRun("hprof", "depth=0,file=options1.txt"); > > Does it work for you? > > -- > With best regards, > Sergei > > > 07.02.2014 23:16, Staffan Larsen wrote: >> Yes, using different output files for the different runs sounds like a good approach. I don?t think the argument to DemoRun() specifies the output file name, though. >> >> /Staffan >> >> On 7 feb 2014, at 11:10, Sergei Kovalev wrote: >> >>> Hello everyone, >>> >>> I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. >>> >>> The issue reproducible only on the host where it was initially discovered. >>> >>> For testing I chose demo/jvmti/hprof/OptionsTest.java test. I identified that failure occurs only with below sequence: >>> >>> hprof = new DemoRun("hprof", "cpu=times,depth=0"); >>> hprof = new DemoRun("hprof", "cpu=old,depth=0"); >>> >>> here second line leads to fail with probability 1/10000. Using process monitor "ProcMon" by Sysinternals I discovered that issue caused by slippage in delete operation. According event log: >>> >>> Normal file system operations looks like: >>> "3:21:16.7185415 AM","java.exe","3532","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","SUCCESS","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created" >>> >>> Operation that leads to fail: >>> "3:52:30.6024647 AM","java.exe","3924","CreateFile","C:\Users\aurora\jdk\sk_jdk\JTwork\scratch\java.hprof.txt","*DELETE PENDING*","Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0" >>> >>> So this is not the test issue. >>> To avoid IO operation failures I propose to use unique file name for each iteration. In this case test would not overwrite file and would not depend on filesystem performance. >>> For example above code will looks like: >>> >>> hprof = new DemoRun("options", "cpu=old,depth=0"); >>> hprof = new DemoRun("optins1", "depth=0"); >>> >>> Please let me know if you have any comments or suggestion. >>> >>> -- >>> With best regards, >>> Sergei From volker.simonis at gmail.com Mon Feb 10 02:10:00 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 10 Feb 2014 11:10:00 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52F8A154.8090102@oracle.com> References: <52EBB103.5090907@oracle.com> <52F8A154.8090102@oracle.com> Message-ID: Hi Dmitry, I've created "8034065: GCC 4.3 and later doesn't export vtable symbols any more which seem to be needed by SA" (https://bugs.openjdk.java.net/browse/JDK-8034065) and assigned it to you. Thank you and best regards, Volker On Mon, Feb 10, 2014 at 10:52 AM, Dmitry Samersoff wrote: > Volker, > > For brief look SA doesn't need vtable symbols. > > But It's better to re-check it. > > Could you file a bug and assign it to me? > > -Dmitry > > On 2014-02-10 13:47, Volker Simonis wrote: >> Hi, >> >> maybe slightly off-topic, but I want to ask if the SA agent needs the >> vtable symbols of all HS classes which are exported by partially >> generated mapfiles (make/linux/makefiles/build_vm_def.sh) during the >> linking of the VM. >> >> I recently found out (see this thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012426.html) >> that compiling the HS with gcc 4.3 and later deasn't export this >> symbols any more, even if they are listed in the map file. >> >> So the simple question is - does the SA agent relies on the vtable >> symbols beeing exported or not? If yes, we should think about a fix. >> If not, we should remove the magic which generates the vtable symbols >> in the map files (i.e. build_vm_def.sh) from the build. >> >> Regards, >> Volker >> >> PS: I didn't use SA agent until now although I think it is an >> intersecting tool. I mostly use the internal tools from >> utilities/debug.cpp. Another possibility used by some colleagues is to >> use the Python scripting capabilities offered by GDB to achieve a >> similar functionality. The downside of that approach is of course that >> is is platform-dependent (i.e. gdb-only). >> >> On Fri, Jan 31, 2014 at 3:19 PM, Dmitry Samersoff >> wrote: >>> Hi Everyone, >>> >>> I would like to start a discussion about future of hotspot debugger, >>> known as serviceability agent or SA. >>> >>> How you typically use it? What do you expect from it? What is missed? >>> >>> Please, share your stories and wishes. >>> >>> And please, fill the small quiz: >>> >>> 1. How often do you use SA? >>> >>> 2. On what platform do you use SA? >>> >>> 3. Do you use it to analyze life processes or coredumps? >>> >>> 5. What other debuggers do you use to debug hotspot issues >>> >>> -Dmitry >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Mon Feb 10 05:32:47 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Feb 2014 08:32:47 -0500 Subject: SA.NEXT - SA feedback needed In-Reply-To: References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> Message-ID: <52F8D4FF.7040106@oracle.com> On 2/10/2014 4:07 AM, Staffan Larsen wrote: >>> I've said before that I believe the SA should be discontinued unless >>> the problem of duplicated hotspot code in it can be resolved. We >>> are in the process of changing many things in the code and the tax >>> of a duplicate implementation in Java is too high. Find a way to >>> use the libjvm.so or a libjvm_sa.so to retrieve hotspot internals. >> >> The main problem, as I see it, is the lack of testing and >> self-verification. If the SA would do that as part of compilation we >> wouldn?t have a broken SA every other build. No, it's not just that it needs to be tested automatically. It needs to not make you write your change twice, once in the JVM and another time in Java. The duplicated code needs to be removed. There should be exactly one copy of the symbol table code, for example. Coleen > > Word! > > /Staffan From staffan.larsen at oracle.com Mon Feb 10 05:40:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 10 Feb 2014 14:40:28 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52F8D4FF.7040106@oracle.com> References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> <52F8D4FF.7040106@oracle.com> Message-ID: On 10 feb 2014, at 14:32, Coleen Phillimore wrote: > On 2/10/2014 4:07 AM, Staffan Larsen wrote: >>>> I've said before that I believe the SA should be discontinued unless the problem of duplicated hotspot code in it can be resolved. We are in the process of changing many things in the code and the tax of a duplicate implementation in Java is too high. Find a way to use the libjvm.so or a libjvm_sa.so to retrieve hotspot internals. >>> >>> The main problem, as I see it, is the lack of testing and self-verification. If the SA would do that as part of compilation we wouldn?t have a broken SA every other build. > > No, it's not just that it needs to be tested automatically. It needs to not make you write your change twice, once in the JVM and another time in Java. The duplicated code needs to be removed. There should be exactly one copy of the symbol table code, for example. That would be ideal, yes. So far I haven?t seen a viable proposal for how to implement this for core file debugging. I?m not saying that it can?t be done, just that we haven?t solved the ?how? yet. /Staffan From erik.helin at oracle.com Mon Feb 10 07:08:42 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 10 Feb 2014 16:08:42 +0100 Subject: RFR: Message-ID: <52F8EB7A.4080305@oracle.com> Hi all, this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and jni_md.h. The bug manifests itself when using an IMPORT_JDK which include/linux/jni_md.h has a timestamp that is older than hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will copy hotspot/src/cpu/x86/jni_x86.h to hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from jdk/include/jni.h, since it is used for all operating systems: #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) ... // common stuff #else ... // windows stuff #endif We compile the SA agent, see make/linux/makefiles/saproc.make, without defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). In my opinion, there are two ways to solve this: 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding defines for Solaris and BSD). 2. Rewrite the #if check in jni_x86.h to use platform specific "native" defines. I've created a patch for each alternative: 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ For the second patch, note that I've inverted the #if check so that it checks for _WIN32 is defined and treat all others operating systems as "#else". Bug: https://bugs.openjdk.java.net/browse/JDK-8034094 Testing: - Compiled both version locally and made sure it worked - JPRT Thanks, Erik From erik.helin at oracle.com Mon Feb 10 07:21:45 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 10 Feb 2014 16:21:45 +0100 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <52F8EB7A.4080305@oracle.com> References: <52F8EB7A.4080305@oracle.com> Message-ID: <52F8EE89.6040808@oracle.com> Sigh, I forgot the subject... "RFR: 8034094: SA agent can't compile when jni_x86.h is used" Thanks, Erik On 2014-02-10 16:08, Erik Helin wrote: > Hi all, > > this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and > jni_md.h. > > The bug manifests itself when using an IMPORT_JDK which > include/linux/jni_md.h has a timestamp that is older than > hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will > copy hotspot/src/cpu/x86/jni_x86.h to > hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. > > The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from > jdk/include/jni.h, since it is used for all operating systems: > > #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > ... // common stuff > #else > ... // windows stuff > #endif > > We compile the SA agent, see make/linux/makefiles/saproc.make, without > defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). > > In my opinion, there are two ways to solve this: > 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding > defines for Solaris and BSD). > 2. Rewrite the #if check in jni_x86.h to use platform specific "native" > defines. > > I've created a patch for each alternative: > 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ > 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ > > For the second patch, note that I've inverted the #if check so that it > checks for _WIN32 is defined and treat all others operating systems as > "#else". > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8034094 > > Testing: > - Compiled both version locally and made sure it worked > - JPRT > > Thanks, > Erik From coleen.phillimore at oracle.com Mon Feb 10 08:24:03 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 10 Feb 2014 11:24:03 -0500 Subject: SA.NEXT - SA feedback needed In-Reply-To: References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> <52F8D4FF.7040106@oracle.com> Message-ID: <52F8FD23.7060006@oracle.com> On 2/10/14 8:40 AM, Staffan Larsen wrote: > > On 10 feb 2014, at 14:32, Coleen Phillimore > > > wrote: > >> On 2/10/2014 4:07 AM, Staffan Larsen wrote: >>>>> I've said before that I believe the SA should be discontinued >>>>> unless the problem of duplicated hotspot code in it can be >>>>> resolved. We are in the process of changing many things in the >>>>> code and the tax of a duplicate implementation in Java is too >>>>> high. Find a way to use the libjvm.so or a libjvm_sa.so to >>>>> retrieve hotspot internals. >>>> >>>> The main problem, as I see it, is the lack of testing and >>>> self-verification. If the SA would do that as part of compilation >>>> we wouldn?t have a broken SA every other build. >> >> No, it's not just that it needs to be tested automatically. It >> needs to not make you write your change twice, once in the JVM and >> another time in Java. The duplicated code needs to be removed. >> There should be exactly one copy of the symbol table code, for example. > > That would be ideal, yes. So far I haven?t seen a viable proposal for > how to implement this for core file debugging. I?m not saying that it > can?t be done, just that we haven?t solved the ?how? yet. I think Dmitry's email is on the right track. If we find we have this duplicated code for functionality that we don't need, we can definitely remove it. We should first start with the requirements. Then we can choose an implementation that has a better design. Coleen > > /Staffan From marcus.lagergren at oracle.com Mon Feb 10 08:44:24 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 10 Feb 2014 17:44:24 +0100 Subject: SA.NEXT - SA feedback needed In-Reply-To: References: <52EBB103.5090907@oracle.com> <52F56404.4070206@oracle.com> Message-ID: <37B863C6-BDED-48C4-949D-9FABE057C25E@oracle.com> > > The main problem, as I see it, is the lack of testing and self-verification. If the SA would do that as part of > compilation we wouldn?t have a broken SA every other build. +1000 /M From jan.siersch at uni-ulm.de Mon Feb 10 09:21:28 2014 From: jan.siersch at uni-ulm.de (Jan Siersch) Date: Mon, 10 Feb 2014 18:21:28 +0100 Subject: RFE: 4508774: Implementation for GetOperandStack Message-ID: <52F90A98.4050808@uni-ulm.de> Hi all, this post is about a feature request for JVMTI to allow access to the operand stack: https://bugs.openjdk.java.net/browse/JDK-4508774 As part of a project I'm working on, I have implemented a set of functions, namely GetOperand, which provide the requested functionality, and I would like to provide this implementation to the OpenJDK project. As I am not a regular contributor to the OpenJDK project, I do not have an account for the bug tracker and cannot post my code there. I have attached a diff with the modified hotspot source code to this e-mail. This implementation adds a new function category "Operand Stack" to JVMTI that contains 5 functions (GetOperandObject, GetOperandInt, GetOperandLong, GetOperandFloat, GetOperandDouble) which can be used the same way as the corresponding GetLocal functions. All changes to the source files are purely additive. No existing functions are modified. One new VM Operation "GetOperand" is added and implemented. The changes are based on the "JDK 7 Updates Master" branch. I have compiled OpenJDK locally with these changes and had no problems with them. However this implementation still has one drawback: the functions are not type-safe, as I was unable to find the necessary information within hotspot to do proper type-checking of operands. For me this is not a problem, because in my project I have a way of inferring operand types externally, but for proper production code type-checking should be added (there is a FIXME in the added source for this purpose). I hope someone reading this list has the time to look at this code and if they find it suitable, to integrate it into the OpenJDK project. About licensing: you may use this code in whatever way, shape or form you see fit. Regards, Jan From jan.siersch at uni-ulm.de Mon Feb 10 09:39:55 2014 From: jan.siersch at uni-ulm.de (Jan Siersch) Date: Mon, 10 Feb 2014 18:39:55 +0100 Subject: RFE: 4508774: Implementation for GetOperandStack In-Reply-To: <52F90A98.4050808@uni-ulm.de> References: <52F90A98.4050808@uni-ulm.de> Message-ID: <52F90EEB.1040204@uni-ulm.de> In case the attachment was removed from the mailing list. Here is an external link to the diff: http://pastebin.com/fbDd7mU3 From stefan.johansson at oracle.com Mon Feb 10 09:51:21 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 10 Feb 2014 18:51:21 +0100 Subject: RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline In-Reply-To: <52E90809.3000900@oracle.com> References: <52E90809.3000900@oracle.com> Message-ID: <52F91199.6030308@oracle.com> Hi again, After a couple of offline discussions with different people I've come to the conclusion to split out the sizing of the young generation from the fix for this issue. I've created a new bug (JDK-8033426) for that, which is currently out for review. The discussions also lead to a different approach for fixing this issue. The new proposal is to use the GC locker to prevent GCs until we are ready to handle them and otherwise fail the VM initialization. The gc locker has two different mechanisms for locking out the GC, one which is used during initialization and one used to stall GCs when doing critical JNI work. The part of the initialization that currently is locked by the GC locker is to narrow and there is no guarantee that a GC can be handled after the GC locker is unlocked. This fix will extend the part that is locked and also add a check that if a GC is initiated while locked during startup the VM exits. New webrev: http://cr.openjdk.java.net/~sjohanss/8028498/webrev.01/ Thanks, Stefan On 2014-01-29 14:54, Stefan Johansson wrote: > Hi, > > Please review this fix for: > https://bugs.openjdk.java.net/browse/JDK-8028498 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/ > > Summary: > The initial young generation size has been fairly small by default > (1.5M) and if setting ObjectAlignmentInBytes to something larger than > the default it can causes CDS to trigger a GC when dumping the > archive. At this point the VM is not ready to handle a GC and we will > hit an assertion. Making sure we can handle a GC at this point is not > trivial and the proposed solution is to alter the default sizing of > the young generation as well as adding a safety check when dumping the > archive to exit the VM if the young generation is too small. > > Testing: > * JPRT build and test passes > * Failing test now passes on all platforms (tested throught JPRT) > * Verified that the GC and Runtime jtreg tests still passes > > Cheers, > Stefan From ioi.lam at oracle.com Mon Feb 10 14:00:17 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 10 Feb 2014 14:00:17 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive Message-ID: <52F94BF1.30304@oracle.com> Please review a very small fix (JDK9): http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ Bug: The original "OutOfMemorError" message could be misleading when the actual cause is the OS limit on number of processes/threads. https://bugs.openjdk.java.net/browse/JDK-7182040 Summary of fix: I changed all occurrence of the literal string "unable to create new native thread" in the C code to call a common function os::native_thread_creation_failed_msg(). Individual OS ports may define an alternative message by defining the OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp Here's a snap shot of the new message: java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:713) at spin.main(spin.java:15) Tests: JPRT Thanks - Ioi From serguei.spitsyn at oracle.com Mon Feb 10 15:36:58 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 10 Feb 2014 15:36:58 -0800 Subject: RFE: 4508774: Implementation for GetOperandStack In-Reply-To: <52F90A98.4050808@uni-ulm.de> References: <52F90A98.4050808@uni-ulm.de> Message-ID: <52F9629A.9080300@oracle.com> Hi Jan, Thank you for contributing a suggested fix for this enhancement! I've attached your diff into the bug report file getOpStack.patch. Of course, we will take care and make sure the final fix is type safe. In case the attachment was removed from the mailing list. Here is an external link to the diff: http://pastebin.com/fbDd7mU3 The above link is helpful as your original diff was removed from the email. Thanks, Serguei On 2/10/14 9:21 AM, Jan Siersch wrote: > Hi all, > > this post is about a feature request for JVMTI to allow access to the > operand stack: > https://bugs.openjdk.java.net/browse/JDK-4508774 > > As part of a project I'm working on, I have implemented a set of > functions, namely GetOperand, which provide the requested > functionality, and I would like to provide this implementation to the > OpenJDK project. As I am not a regular contributor to the OpenJDK > project, I do not have an account for the bug tracker and cannot post > my code there. > > I have attached a diff with the modified hotspot source code to this > e-mail. This implementation adds a new function category "Operand > Stack" to JVMTI that contains 5 functions (GetOperandObject, > GetOperandInt, GetOperandLong, GetOperandFloat, GetOperandDouble) > which can be used the same way as the corresponding GetLocal > functions. > > All changes to the source files are purely additive. No existing > functions are modified. One new VM Operation "GetOperand" is added and > implemented. The changes are based on the "JDK 7 Updates Master" > branch. I have compiled OpenJDK locally with these changes and had no > problems with them. > > However this implementation still has one drawback: the functions are > not type-safe, as I was unable to find the necessary information > within hotspot to do proper type-checking of operands. For me this is > not a problem, because in my project I have a way of inferring operand > types externally, but for proper production code type-checking should > be added (there is a FIXME in the added source for this purpose). > > I hope someone reading this list has the time to look at this code and > if they find it suitable, to integrate it into the OpenJDK project. > About licensing: you may use this code in whatever way, shape or form > you see fit. > > Regards, > Jan From alejandro.murillo at oracle.com Mon Feb 10 21:51:45 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 11 Feb 2014 05:51:45 +0000 Subject: hg: hsx/jdk7u/corba: 2 new changesets Message-ID: <20140211055154.8E62E62B4F@hg.openjdk.java.net> Changeset: 3de961371888 Author: coffeys Date: 2013-10-23 16:45 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/3de961371888 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java Changeset: 394f83504abb Author: lana Date: 2014-02-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/corba/rev/394f83504abb Merge From david.holmes at oracle.com Mon Feb 10 23:09:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Feb 2014 17:09:51 +1000 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52F94BF1.30304@oracle.com> References: <52F94BF1.30304@oracle.com> Message-ID: <52F9CCBF.5080206@oracle.com> Okay I guess. :) David On 11/02/2014 8:00 AM, Ioi Lam wrote: > Please review a very small fix (JDK9): > > http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ > > Bug: The original "OutOfMemorError" message could be misleading when the > actual cause is the OS limit on number of processes/threads. > > https://bugs.openjdk.java.net/browse/JDK-7182040 > > Summary of fix: > > I changed all occurrence of the literal string "unable to create > new native thread" > in the C code to call a common function > os::native_thread_creation_failed_msg(). > > Individual OS ports may define an alternative message by defining the > OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp > > Here's a snap shot of the new message: > > java.lang.OutOfMemoryError: unable to create native thread: > possibly out of memory > or process/resource limits reached > at java.lang.Thread.start0(Native Method) > at java.lang.Thread.start(Thread.java:713) > at spin.main(spin.java:15) > > Tests: > > JPRT > > Thanks > - Ioi From alejandro.murillo at oracle.com Mon Feb 10 21:52:49 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 11 Feb 2014 05:52:49 +0000 Subject: hg: hsx/jdk7u/jdk: 23 new changesets Message-ID: <20140211055826.AF96662B50@hg.openjdk.java.net> Changeset: 9e5c6b2fe171 Author: mbankal Date: 2014-01-21 07:53 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9e5c6b2fe171 8012244: java/net/Socket/asyncClose/Race.java fails intermittently on Windows Reviewed-by: chegar ! src/windows/classes/java/net/DualStackPlainSocketImpl.java ! src/windows/native/java/net/SocketInputStream.c ! test/java/net/Socket/asyncClose/Race.java Changeset: 2b52567922b6 Author: lana Date: 2014-01-21 12:39 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/2b52567922b6 Merge Changeset: 6a3fd236165c Author: dfuchs Date: 2014-01-22 14:11 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/6a3fd236165c 8029281: Synchronization issues in Logger and LogManager Summary: Fixes several race conditions in logging which have been at the root cause of intermittent test failures. Reviewed-by: mchung, plevart ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/TestLogConfigurationDeadLock.java + test/java/util/logging/TestLoggerBundleSync.java Changeset: 7d4a292dda4f Author: dfuchs Date: 2014-01-21 14:28 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/7d4a292dda4f 8031980: Add new j.u.l deadlock test for JDK-8027670 and JDK-8029281 Summary: adds a new test for the deadlock found in JDK-8027670 and fixed in JDK-8029281. Reviewed-by: mchung ! test/java/util/logging/TestLogConfigurationDeadLock.java + test/java/util/logging/TestLogConfigurationDeadLockWithConf.java + test/java/util/logging/deadlockconf.properties Changeset: ce2dea6653e7 Author: alanb Date: 2012-11-11 10:05 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ce2dea6653e7 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: ed39d094c281 Author: alanb Date: 2012-11-14 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/ed39d094c281 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 80bc975ee4df Author: alanb Date: 2014-01-09 11:45 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/80bc975ee4df 8003895: java/nio/channels/AsynchronousChannelGroup/Unbounded.java failing again [win64] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: c03c270734ae Author: coffeys Date: 2014-01-10 15:10 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/c03c270734ae 8017779: java/net/Authenticator/B4769350.java fails Reviewed-by: chegar Contributed-by: Tristan Yan , Kurchi Subhra Hazra ! test/java/net/Authenticator/B4769350.java Changeset: 82f3d3f4e5df Author: coffeys Date: 2014-01-23 19:23 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/82f3d3f4e5df Merge Changeset: 3d3f975635eb Author: dmarkov Date: 2014-01-24 01:22 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/3d3f975635eb 8028616: Htmleditorkit parser doesn't handle leading slash (/) Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/8028616/bug8028616.java Changeset: 87a483ec5610 Author: uta Date: 2014-01-22 18:13 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/87a483ec5610 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Reviewed-by: alanb, khazra, chegar ! src/windows/native/java/lang/java_props_md.c ! src/windows/resource/java.manifest Changeset: 890440bae193 Author: tyan Date: 2014-01-24 12:25 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/890440bae193 8030712: TEST_BUG : java/lang/ProcessBuilder/BasicLauncher.java fails if java output contains VM warning Reviewed-by: alanb, martin ! test/java/lang/ProcessBuilder/Basic.java Changeset: b537340c8299 Author: igerasim Date: 2014-01-23 03:22 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b537340c8299 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Reviewed-by: michaelm ! src/share/classes/java/net/IDN.java + test/java/net/IDN/UseSTD3ASCIIRules.java Changeset: 29641d5506eb Author: igerasim Date: 2014-01-25 00:49 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/29641d5506eb 8030698: Several GUI labels in jconsole need correction Reviewed-by: sla ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: d6fb53a01abc Author: igerasim Date: 2014-01-24 21:46 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d6fb53a01abc 8030878: JConsole issues meaningless message if SSL connection fails Reviewed-by: mchung, sla ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 57ac2bbc3075 Author: coffeys Date: 2013-10-23 16:53 +0100 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/57ac2bbc3075 5036554: unmarshal error on CORBA alias type in CORBA any Reviewed-by: chegar, smarks + test/com/sun/corba/5036554/JavaBug.java + test/com/sun/corba/5036554/README + test/com/sun/corba/5036554/TestCorbaBug.sh + test/com/sun/corba/5036554/bug.idl Changeset: 47834fe119cb Author: bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/47834fe119cb 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: d385f8557e94 Author: bchristi Date: 2014-01-28 11:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/d385f8557e94 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] Summary: On MacOS X set user.home to value of NSHomeDirectory() Reviewed-by: alanb, ddehaven, mduigou ! make/common/Defs-macosx.gmk ! make/java/java/Makefile ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c Changeset: 5d4ddcee9b06 Author: weijun Date: 2014-01-21 12:08 +0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/5d4ddcee9b06 8031572: jarsigner -verify exits with 0 when a jar file is not properly signed Reviewed-by: mullan ! src/share/classes/java/util/jar/JarFile.java + test/sun/security/tools/jarsigner/EntriesOrder.java Changeset: 9f5d6c8c6f4c Author: miroslawzn Date: 2014-01-30 13:28 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/9f5d6c8c6f4c 8011944: Sort fails with ArrayIndexOutOfBoundsException Reviewed-by: alanb ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/TimSort.java + test/java/util/Arrays/TimSortStackSize.java Changeset: cbbd96e17b06 Author: aefimov Date: 2014-02-04 17:37 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/cbbd96e17b06 8030822: (tz) Support tzdata2013i Reviewed-by: coffeys, mfang, okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/northamerica ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: b562ed3c0bd2 Author: aefimov Date: 2014-01-31 18:10 +0400 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/b562ed3c0bd2 8027973: javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win) Reviewed-by: alanb, dfuchs, joehw + test/javax/xml/jaxp/transform/8004476/SecureProcessingTest.xml + test/javax/xml/jaxp/transform/8004476/TestBase.java + test/javax/xml/jaxp/transform/8004476/XPathExFuncTest.java + test/javax/xml/jaxp/transform/8004476/XSLTExFuncTest.java + test/javax/xml/jaxp/transform/8004476/tokenize.xml + test/javax/xml/jaxp/transform/8004476/tokenize.xsl - test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml - test/javax/xml/jaxp/transform/jdk8004476/TestBase.java - test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl Changeset: 25524158eb9f Author: lana Date: 2014-02-05 13:57 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/jdk/rev/25524158eb9f Merge - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/javax/xml/jaxp/transform/jdk8004476/SecureProcessingTest.xml - test/javax/xml/jaxp/transform/jdk8004476/TestBase.java - test/javax/xml/jaxp/transform/jdk8004476/XPathExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xml - test/javax/xml/jaxp/transform/jdk8004476/tokenize.xsl From serguei.spitsyn at oracle.com Tue Feb 11 00:27:42 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Feb 2014 00:27:42 -0800 Subject: RFE: 4508774: Implementation for GetOperandStack In-Reply-To: <52F9629A.9080300@oracle.com> References: <52F90A98.4050808@uni-ulm.de> <52F9629A.9080300@oracle.com> Message-ID: <52F9DEFE.7080100@oracle.com> Hi Jan, I was told that you are not allowed to contribute until you sign an OSA. This is a link to follow: http://openjdk.java.net/contribute/ I'm deleting the attachment from the bug report at the moment. Sorry. :( Thanks, Serguei On 2/10/14 3:36 PM, serguei.spitsyn at oracle.com wrote: > Hi Jan, > > Thank you for contributing a suggested fix for this enhancement! > I've attached your diff into the bug report file getOpStack.patch. > Of course, we will take care and make sure the final fix is type safe. > > In case the attachment was removed from the mailing list. > Here is an external link to the diff: > http://pastebin.com/fbDd7mU3 > > The above link is helpful as your original diff was removed from the > email. > > Thanks, > Serguei > > > On 2/10/14 9:21 AM, Jan Siersch wrote: >> Hi all, >> >> this post is about a feature request for JVMTI to allow access to the >> operand stack: >> https://bugs.openjdk.java.net/browse/JDK-4508774 >> >> As part of a project I'm working on, I have implemented a set of >> functions, namely GetOperand, which provide the requested >> functionality, and I would like to provide this implementation to the >> OpenJDK project. As I am not a regular contributor to the OpenJDK >> project, I do not have an account for the bug tracker and cannot post >> my code there. >> >> I have attached a diff with the modified hotspot source code to this >> e-mail. This implementation adds a new function category "Operand >> Stack" to JVMTI that contains 5 functions (GetOperandObject, >> GetOperandInt, GetOperandLong, GetOperandFloat, GetOperandDouble) >> which can be used the same way as the corresponding GetLocal >> functions. >> >> All changes to the source files are purely additive. No existing >> functions are modified. One new VM Operation "GetOperand" is added >> and implemented. The changes are based on the "JDK 7 Updates Master" >> branch. I have compiled OpenJDK locally with these changes and had no >> problems with them. >> >> However this implementation still has one drawback: the functions are >> not type-safe, as I was unable to find the necessary information >> within hotspot to do proper type-checking of operands. For me this is >> not a problem, because in my project I have a way of inferring >> operand types externally, but for proper production code >> type-checking should be added (there is a FIXME in the added source >> for this purpose). >> >> I hope someone reading this list has the time to look at this code >> and if they find it suitable, to integrate it into the OpenJDK >> project. About licensing: you may use this code in whatever way, >> shape or form you see fit. >> >> Regards, >> Jan > From bourges.laurent at gmail.com Tue Feb 11 00:51:09 2014 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Tue, 11 Feb 2014 09:51:09 +0100 Subject: Fwd: Improve large array allocation / gc & intrinsics In-Reply-To: References: Message-ID: Please, could you give me your opinions on the following ideas for a JDK9 RFE ? Is it worth? Interesting or totally stupid with current hotspot / gc ? How hard / long would it be to study and make a prototype ? Any other ideas to improve array performance like improving again the array bound check elimination or fill / clear intrinsics ... Who would be interested by this topics ? Laurent ---------- Message transf?r? ---------- De : "Laurent Bourg?s" Date : 10 f?vr. 2014 10:24 Objet : Improve large array allocation / gc & intrinsics ? : "core-libs-dev" , "discuss" < discuss at openjdk.java.net> Cc : > Dear all, > > I would like to propose a JDK9 RFE to improve JVM efficiency when > dealing with large arrays (allocation + gc). > > In several scientific applications (and my patched java2d pisces), > many large arrays are needed, created on the fly and it becomes very > painful to recycle them using an efficient array cache (concurrency, > cache size tuning, clear + cache eviction issues). > > In this case, the GC overhead leads to a big performance penalty > (several hundred megabytes per seconds). > > As such array cache are very efficient in an application context, I am > wondering if that approach could be promoted at the JDK level itself: > > - provide a new array allocator for large arrays that can return > larger arrays than expected (size = 4 or 8 multiples) using array > caches (per thread ?) stored in a dedicated JVM large memory area (GC > aware) and providing efficient cache eviction policies > > - may support for both clean arrays (zero filled) or dirty arrays > because some algorithms does not need zero-filled arrays. > > - improve JVM intrinsics (array clear, fill) to achieve maximum > performance ie take into account the data alignment (4 or 8 multiples) > > - upgrade GC to recycle such 'cached' arrays (clean), update usage > statistics and manage cache eviction policy (avoid wasting memory) > > Please give me your feedback & opinion and evaluate if this feature > seems possible to implement into the JDK (hotspot, gc, core-libs) ... > > What is the procedure to create such JDK9 RFE ? > > Best regards, > > Laurent Bourg?s ---------- Message transf?r? ---------- De : "Laurent Bourg?s" Date : 10 f?vr. 2014 10:24 Objet : Improve large array allocation / gc & intrinsics ? : "core-libs-dev" , "discuss" < discuss at openjdk.java.net> Cc : Dear all, > > I would like to propose a JDK9 RFE to improve JVM efficiency when > dealing with large arrays (allocation + gc). > > In several scientific applications (and my patched java2d pisces), > many large arrays are needed, created on the fly and it becomes very > painful to recycle them using an efficient array cache (concurrency, > cache size tuning, clear + cache eviction issues). > > In this case, the GC overhead leads to a big performance penalty > (several hundred megabytes per seconds). > > As such array cache are very efficient in an application context, I am > wondering if that approach could be promoted at the JDK level itself: > > - provide a new array allocator for large arrays that can return > larger arrays than expected (size = 4 or 8 multiples) using array > caches (per thread ?) stored in a dedicated JVM large memory area (GC > aware) and providing efficient cache eviction policies > > - may support for both clean arrays (zero filled) or dirty arrays > because some algorithms does not need zero-filled arrays. > > - improve JVM intrinsics (array clear, fill) to achieve maximum > performance ie take into account the data alignment (4 or 8 multiples) > > - upgrade GC to recycle such 'cached' arrays (clean), update usage > statistics and manage cache eviction policy (avoid wasting memory) > > Please give me your feedback & opinion and evaluate if this feature > seems possible to implement into the JDK (hotspot, gc, core-libs) ... > > What is the procedure to create such JDK9 RFE ? > > Best regards, > > Laurent Bourg?s > From goetz.lindenmaier at sap.com Tue Feb 11 01:02:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 11 Feb 2014 09:02:36 +0000 Subject: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> Hi, The template template parameters in the binaryTreeDictionary are not needed to express its functionality. This change replaces them by simple class templates and explicit instantiation. This simplifies consumption of the openJDK in scenarios requiring older C++ compilers. This change also removes dead get_chunk() from binaryTreeDictionary.cpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8034171 webrev: http://cr.openjdk.java.net/~goetz/webrevs/8034171-1-templ/ Please review and test this change. Unfortunately I don't have access to JPRT, so I need a sponsor. I compiled this change on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with SS12u1, on windows amd64 and on sparc. I tested dbg, fdbg and opt builds. The change ran with all our tests on the ppc port, including jbb2013, jvm2008 and parts of a well-known, publicly not available test suite without problems. I would like to downport this change to jdk8u targeting u20 later on. Could you please also check whether I filed the bug correctly? What should I put into "affected versions"? Thanks and best regards, Goetz. From staffan.larsen at oracle.com Tue Feb 11 01:53:27 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 11 Feb 2014 10:53:27 +0100 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52F94BF1.30304@oracle.com> References: <52F94BF1.30304@oracle.com> Message-ID: Ok. /Staffan On 10 feb 2014, at 23:00, Ioi Lam wrote: > Please review a very small fix (JDK9): > > http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ > > Bug: The original "OutOfMemorError" message could be misleading when the > actual cause is the OS limit on number of processes/threads. > > https://bugs.openjdk.java.net/browse/JDK-7182040 > > Summary of fix: > > I changed all occurrence of the literal string "unable to create new native thread" > in the C code to call a common function os::native_thread_creation_failed_msg(). > > Individual OS ports may define an alternative message by defining the > OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp > > Here's a snap shot of the new message: > > java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory > or process/resource limits reached > at java.lang.Thread.start0(Native Method) > at java.lang.Thread.start(Thread.java:713) > at spin.main(spin.java:15) > > Tests: > > JPRT > > Thanks > - Ioi From staffan.larsen at oracle.com Tue Feb 11 02:12:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 11 Feb 2014 11:12:12 +0100 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot Message-ID: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) implementations have moved to USDT2, we can finally remove the USDT1 code from hotspot. There are quite a lot of changes in this review, and webrev barfed on the number of change in jni.cpp so that file can only be reviewed from the patch file. The good news is that the changes are mostly trivial removal of #ifdef:ed code. bug: https://bugs.openjdk.java.net/browse/JDK-8034080 webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ Testing: I have run jck-runtime, vm.quick.testlist and vm.dtrace.testlist on Solaris and OS X. /Staffan From thomas.schatzl at oracle.com Tue Feb 11 02:28:30 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 11 Feb 2014 11:28:30 +0100 Subject: Fwd: Improve large array allocation / gc & intrinsics In-Reply-To: References: Message-ID: <1392114510.2707.33.camel@cirrus> Hi, just a few comments... > De : "Laurent Bourg?s" > Date : 10 f?vr. 2014 10:24 > Objet : Improve large array allocation / gc & intrinsics > ? : "core-libs-dev" , "discuss" < > discuss at openjdk.java.net> > Cc : > > > Dear all, > > > > I would like to propose a JDK9 RFE to improve JVM efficiency when > > dealing with large arrays (allocation + gc). > > > > In several scientific applications (and my patched java2d pisces), > > many large arrays are needed, created on the fly and it becomes very > > painful to recycle them using an efficient array cache (concurrency, > > cache size tuning, clear + cache eviction issues). Why do you think that a one-size fits all approach that any library in the JDK will not have the same issues to deal with? How do you know that a generic library in the JDK (as in your proposal) or hacking things into the VM can deal with this problem better than you who knows the application allocation patterns? Do you have a prototype (library) for that? > > In this case, the GC overhead leads to a big performance penalty > > (several hundred megabytes per seconds). I do not understand what the problem is. Typically I would not specify performance (throughput?) penalty in megabytes per seconds. Do the GCs take too long, or do you feel there too much memory wastage somewhere? > > As such array cache are very efficient in an application context, I am > > wondering if that approach could be promoted at the JDK level itself: > > > > - provide a new array allocator for large arrays that can return > > larger arrays than expected (size = 4 or 8 multiples) using array > > caches (per thread ?) stored in a dedicated JVM large memory area The behavior you propose seems very particular to your application. Others may have completely different requirements. The mentioned per-thread caches do not seem to be problematic to do in a library either. > > (GC aware) and providing efficient cache eviction policies Did you every try one of the other available garbage collectors with your application? Both CMS and G1 never move large objects around, i.e. there is almost no direct GC overhead associated with them. Reclaiming them is almost zero cost in these collectors. Keeping them alive seems to be best handled by logic in a library. Can you give examples where the VM has significant advantages over a dedicated library, or a particular use case with measurements that show this could be the case? > > - may support for both clean arrays (zero filled) or dirty arrays > > because some algorithms does not need zero-filled arrays. > > > > - improve JVM intrinsics (array clear, fill) to achieve maximum > > performance ie take into account the data alignment (4 or 8 multiples) I think the compiler already uses specialized methods for that, using the "best" instructions that are available. It should also already be able to detect "fill" loops, and vectorize them. Objects are always 8 byte aligned - I think you can force higher alignments by setting ObjectAlignmentInBytes or so. Otherwise these changes could be simply added, i.e. seems to not need any RFE. > > - upgrade GC to recycle such 'cached' arrays (clean), update usage > > statistics and manage cache eviction policy (avoid wasting memory) The GCs already automatically recycle the freed space. Everything else seems to be more complicated to implement at VM level than at library level, with the added drawback that you add a VM dependency. > > Please give me your feedback & opinion and evaluate if this feature > > seems possible to implement into the JDK (hotspot, gc, core-libs)... Thanks, Thomas From mikael.gerdin at oracle.com Tue Feb 11 04:06:23 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 11 Feb 2014 13:06:23 +0100 Subject: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> Message-ID: <3980493.Ll3x5zLtB2@mgerdin03> Hi Goetz, On Tuesday 11 February 2014 09.02.36 Lindenmaier, Goetz wrote: > Hi, > > The template template parameters in the binaryTreeDictionary are not > needed to express its functionality. This change replaces them by simple > class templates and explicit instantiation. This simplifies consumption of > the openJDK in scenarios requiring older C++ compilers. > > This change also removes dead get_chunk() from binaryTreeDictionary.cpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8034171 > webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8034171-1-templ/ > > Please review and test this change. Unfortunately I don't have access > to JPRT, so I need a sponsor. > I've looked through the changes and they look good. I've also ran them through JPRT to verify that it compiles and runs on all Oracle platforms with our default compiler versions. I can sponsor this change once it's reviewed. > > I compiled this change on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 > with SS12u1, > > on windows amd64 and on sparc. I tested dbg, fdbg and opt builds. The change > ran with all our tests > > on the ppc port, including jbb2013, jvm2008 and parts of a well-known, > publicly > > not available test suite without problems. > > > > I would like to downport this change to jdk8u targeting u20 later on. > I don't think that would be a problem. > > > Could you please also check whether I filed the bug correctly? What should > > I put into "affected versions"? I'd just put "9" there. /Mikael > > > > Thanks and best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Feb 11 05:38:48 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 11 Feb 2014 13:38:48 +0000 Subject: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. In-Reply-To: <3980493.Ll3x5zLtB2@mgerdin03> References: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> <3980493.Ll3x5zLtB2@mgerdin03> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA16D0@DEWDFEMB12A.global.corp.sap> Hi Mikael, thanks a lot! The bug system does not accept '9', so I guess I'll leave it open for now. Best regards, Goetz. -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Tuesday, February 11, 2014 1:06 PM To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'hotspot-runtime-dev at openjdk.java.net'; Baesken, Matthias Subject: Re: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. Hi Goetz, On Tuesday 11 February 2014 09.02.36 Lindenmaier, Goetz wrote: > Hi, > > The template template parameters in the binaryTreeDictionary are not > needed to express its functionality. This change replaces them by simple > class templates and explicit instantiation. This simplifies consumption of > the openJDK in scenarios requiring older C++ compilers. > > This change also removes dead get_chunk() from binaryTreeDictionary.cpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8034171 > webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8034171-1-templ/ > > Please review and test this change. Unfortunately I don't have access > to JPRT, so I need a sponsor. > I've looked through the changes and they look good. I've also ran them through JPRT to verify that it compiles and runs on all Oracle platforms with our default compiler versions. I can sponsor this change once it's reviewed. > > I compiled this change on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 > with SS12u1, > > on windows amd64 and on sparc. I tested dbg, fdbg and opt builds. The change > ran with all our tests > > on the ppc port, including jbb2013, jvm2008 and parts of a well-known, > publicly > > not available test suite without problems. > > > > I would like to downport this change to jdk8u targeting u20 later on. > I don't think that would be a problem. > > > Could you please also check whether I filed the bug correctly? What should > > I put into "affected versions"? I'd just put "9" there. /Mikael > > > > Thanks and best regards, > > Goetz. From staffan.larsen at oracle.com Tue Feb 11 07:04:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 11 Feb 2014 16:04:46 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FA301A.2040301@oracle.com> References: <52FA301A.2040301@oracle.com> Message-ID: Hi Shanliang, I can?t quite see how the test can fail in this way. When the ClassPrepareEvent happens, the debuggee will be suspended. So when addFieldWatch() is called, the debuggee should not have moved. One problem I do see with the test is that it does not wait for a VMStartEvent before setting up requests. I?m not sure if that could cause the failure in the bug report, though. /Staffan On 11 feb 2014, at 15:13, shanliang wrote: > Hi , > > The problem could be that FieldMonitor did not have enough time to "addFieldWatch" but the vm to monitor (TestPostFieldModification) was already ended. > > So we should make sure that TestPostFieldModification exits after FieldMonitor has done necessary. The solution proposed here is that FieldMonitor creates a file after adding field watching, and TestPostFieldModification quits only after finding the file. > > web: > http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8007710 > > Thanks, > Shanliang From stefan.johansson at oracle.com Tue Feb 11 07:12:25 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 11 Feb 2014 16:12:25 +0100 Subject: RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline In-Reply-To: <52F91199.6030308@oracle.com> References: <52E90809.3000900@oracle.com> <52F91199.6030308@oracle.com> Message-ID: <52FA3DD9.20004@oracle.com> Hi again =) Don't spend time on the current webrev (02). I've gotten some more comments on the proposed fix and will look at a solution that allow us to remove the GC locker usage during initialization. Cheers, Stefan On 2014-02-10 18:51, Stefan Johansson wrote: > Hi again, > > After a couple of offline discussions with different people I've come > to the conclusion to split out the sizing of the young generation from > the fix for this issue. I've created a new bug (JDK-8033426) for that, > which is currently out for review. > > The discussions also lead to a different approach for fixing this > issue. The new proposal is to use the GC locker to prevent GCs until > we are ready to handle them and otherwise fail the VM initialization. > The gc locker has two different mechanisms for locking out the GC, one > which is used during initialization and one used to stall GCs when > doing critical JNI work. The part of the initialization that currently > is locked by the GC locker is to narrow and there is no guarantee that > a GC can be handled after the GC locker is unlocked. This fix will > extend the part that is locked and also add a check that if a GC is > initiated while locked during startup the VM exits. > > New webrev: > http://cr.openjdk.java.net/~sjohanss/8028498/webrev.01/ > > Thanks, > Stefan > > On 2014-01-29 14:54, Stefan Johansson wrote: >> Hi, >> >> Please review this fix for: >> https://bugs.openjdk.java.net/browse/JDK-8028498 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/ >> >> Summary: >> The initial young generation size has been fairly small by default >> (1.5M) and if setting ObjectAlignmentInBytes to something larger than >> the default it can causes CDS to trigger a GC when dumping the >> archive. At this point the VM is not ready to handle a GC and we will >> hit an assertion. Making sure we can handle a GC at this point is not >> trivial and the proposed solution is to alter the default sizing of >> the young generation as well as adding a safety check when dumping >> the archive to exit the VM if the young generation is too small. >> >> Testing: >> * JPRT build and test passes >> * Failing test now passes on all platforms (tested throught JPRT) >> * Verified that the GC and Runtime jtreg tests still passes >> >> Cheers, >> Stefan > From jan.siersch at uni-ulm.de Tue Feb 11 08:07:11 2014 From: jan.siersch at uni-ulm.de (Jan Siersch) Date: Tue, 11 Feb 2014 17:07:11 +0100 Subject: RFE: 4508774: Implementation for GetOperandStack In-Reply-To: <52F9DEFE.7080100@oracle.com> References: <52F90A98.4050808@uni-ulm.de> <52F9629A.9080300@oracle.com> <52F9DEFE.7080100@oracle.com> Message-ID: <52FA4AAF.40503@uni-ulm.de> Hi Serguei, I have just signed the OCA and mailed it to oracle. Hope you can use the code once they have processed my request. Regards, Jan On 02/11/2014 09:27 AM, serguei.spitsyn at oracle.com wrote: > Hi Jan, > > I was told that you are not allowed to contribute until you sign an OSA. > This is a link to follow: > http://openjdk.java.net/contribute/ > > I'm deleting the attachment from the bug report at the moment. Sorry. :( > > Thanks, > Serguei > > On 2/10/14 3:36 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jan, >> >> Thank you for contributing a suggested fix for this enhancement! >> I've attached your diff into the bug report file getOpStack.patch. >> Of course, we will take care and make sure the final fix is type safe. >> >> In case the attachment was removed from the mailing list. >> Here is an external link to the diff: >> http://pastebin.com/fbDd7mU3 >> >> The above link is helpful as your original diff was removed from the >> email. >> >> Thanks, >> Serguei >> >> >> On 2/10/14 9:21 AM, Jan Siersch wrote: >>> Hi all, >>> >>> this post is about a feature request for JVMTI to allow access to >>> the operand stack: >>> https://bugs.openjdk.java.net/browse/JDK-4508774 >>> >>> As part of a project I'm working on, I have implemented a set of >>> functions, namely GetOperand, which provide the requested >>> functionality, and I would like to provide this implementation to >>> the OpenJDK project. As I am not a regular contributor to the >>> OpenJDK project, I do not have an account for the bug tracker and >>> cannot post my code there. >>> >>> I have attached a diff with the modified hotspot source code to this >>> e-mail. This implementation adds a new function category "Operand >>> Stack" to JVMTI that contains 5 functions (GetOperandObject, >>> GetOperandInt, GetOperandLong, GetOperandFloat, GetOperandDouble) >>> which can be used the same way as the corresponding GetLocal >>> functions. >>> >>> All changes to the source files are purely additive. No existing >>> functions are modified. One new VM Operation "GetOperand" is added >>> and implemented. The changes are based on the "JDK 7 Updates Master" >>> branch. I have compiled OpenJDK locally with these changes and had >>> no problems with them. >>> >>> However this implementation still has one drawback: the functions >>> are not type-safe, as I was unable to find the necessary information >>> within hotspot to do proper type-checking of operands. For me this >>> is not a problem, because in my project I have a way of inferring >>> operand types externally, but for proper production code >>> type-checking should be added (there is a FIXME in the added source >>> for this purpose). >>> >>> I hope someone reading this list has the time to look at this code >>> and if they find it suitable, to integrate it into the OpenJDK >>> project. About licensing: you may use this code in whatever way, >>> shape or form you see fit. >>> >>> Regards, >>> Jan >> > From serguei.spitsyn at oracle.com Tue Feb 11 11:01:51 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Feb 2014 11:01:51 -0800 Subject: RFE: 4508774: Implementation for GetOperandStack In-Reply-To: <52FA4AAF.40503@uni-ulm.de> References: <52F90A98.4050808@uni-ulm.de> <52F9629A.9080300@oracle.com> <52F9DEFE.7080100@oracle.com> <52FA4AAF.40503@uni-ulm.de> Message-ID: <52FA739F.9070204@oracle.com> Hi Jan, Great. Please, let me know when it is completed. Thanks, Serguei On 2/11/14 8:07 AM, Jan Siersch wrote: > Hi Serguei, > > I have just signed the OCA and mailed it to oracle. Hope you can use > the code once they have processed my request. > > Regards, > Jan > > On 02/11/2014 09:27 AM, serguei.spitsyn at oracle.com wrote: >> Hi Jan, >> >> I was told that you are not allowed to contribute until you sign an OSA. >> This is a link to follow: >> http://openjdk.java.net/contribute/ >> >> I'm deleting the attachment from the bug report at the moment. Sorry. :( >> >> Thanks, >> Serguei >> >> On 2/10/14 3:36 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jan, >>> >>> Thank you for contributing a suggested fix for this enhancement! >>> I've attached your diff into the bug report file getOpStack.patch. >>> Of course, we will take care and make sure the final fix is type safe. >>> >>> In case the attachment was removed from the mailing list. >>> Here is an external link to the diff: >>> http://pastebin.com/fbDd7mU3 >>> >>> The above link is helpful as your original diff was removed from the >>> email. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/10/14 9:21 AM, Jan Siersch wrote: >>>> Hi all, >>>> >>>> this post is about a feature request for JVMTI to allow access to >>>> the operand stack: >>>> https://bugs.openjdk.java.net/browse/JDK-4508774 >>>> >>>> As part of a project I'm working on, I have implemented a set of >>>> functions, namely GetOperand, which provide the requested >>>> functionality, and I would like to provide this implementation to >>>> the OpenJDK project. As I am not a regular contributor to the >>>> OpenJDK project, I do not have an account for the bug tracker and >>>> cannot post my code there. >>>> >>>> I have attached a diff with the modified hotspot source code to >>>> this e-mail. This implementation adds a new function category >>>> "Operand Stack" to JVMTI that contains 5 functions >>>> (GetOperandObject, GetOperandInt, GetOperandLong, GetOperandFloat, >>>> GetOperandDouble) which can be used the same way as the >>>> corresponding GetLocal functions. >>>> >>>> All changes to the source files are purely additive. No existing >>>> functions are modified. One new VM Operation "GetOperand" is added >>>> and implemented. The changes are based on the "JDK 7 Updates >>>> Master" branch. I have compiled OpenJDK locally with these changes >>>> and had no problems with them. >>>> >>>> However this implementation still has one drawback: the functions >>>> are not type-safe, as I was unable to find the necessary >>>> information within hotspot to do proper type-checking of operands. >>>> For me this is not a problem, because in my project I have a way of >>>> inferring operand types externally, but for proper production code >>>> type-checking should be added (there is a FIXME in the added source >>>> for this purpose). >>>> >>>> I hope someone reading this list has the time to look at this code >>>> and if they find it suitable, to integrate it into the OpenJDK >>>> project. About licensing: you may use this code in whatever way, >>>> shape or form you see fit. >>>> >>>> Regards, >>>> Jan >>> >> From mike.duigou at oracle.com Tue Feb 11 11:42:45 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Feb 2014 11:42:45 -0800 Subject: RFR: JDK-8030350 : (s) Enable additional compiler warnings for GCC Message-ID: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> Hello all; This is a final update to the previously reviewed changeset. I had to make one slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to accommodate a problem which appeared since this process began. http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/ This change will be integrated through the jdk9/hs-rt repos. From the original review request: > This is a change which enables additional compiler warnings for native compilation when using GCC. The (-Wformat -Wformat-security) options are supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) and later so we shouldn't see issues with incompatibility.- Wextra appears to have been added in GCC 3.4.X line (c. 2004) so it should also be reasonably well adopted and replaces -W. > > The core of the change is to add : > > -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 > > for general C and CC++ compilations. For HotSpot C++ compiles a slightly less aggressive set is used: > > -Wformat=2 -Wno-error=format-nonliteral > > is used. > > This change is targeted at the JDK 9 repos but could be backported to JDK 8 fairly easily/safely. Mike From serguei.spitsyn at oracle.com Tue Feb 11 18:57:06 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 11 Feb 2014 18:57:06 -0800 Subject: 2-nd round RFR (S) 8032223: nsk/regression/b4663146 gets assert(SafepointSynchronize::is_at_safepoint() || JvmtiEnv::is_thread_fully_suspended(get_thread(), false, &debug_bits)) In-Reply-To: <52F1514C.1050405@oracle.com> References: <52F0CB50.3040703@oracle.com> <52F10BBA.8060504@oracle.com> <52F1514C.1050405@oracle.com> Message-ID: <52FAE302.1040305@oracle.com> On 2/4/14 12:45 PM, serguei.spitsyn at oracle.com wrote: > Thanks, Dan! > Some comments below. > > On 2/4/14 7:48 AM, Daniel D. Daugherty wrote: >> On 2/4/14 4:13 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8032223 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8032223-JVMTI-FRAME.1/ >>> >> >> src/share/vm/prims/jvmtiEnvBase.hpp >> No comments. >> >> src/share/vm/prims/jvmtiEnv.cpp >> No comments beyond David's tweak to the comment. > > Will fix it before push. > >> For future work... >> >> Looks like these VM ops also need the liveness check on the >> target JavaThread: >> >> VM_GetOwnedMonitorInfo >> VM_GetStackTrace >> >> JvmtiEnv::GetStackTrace() looks like it has the same >> is_thread_fully_suspended() flaw... > > I know about this. > There are even more issues: > GetCurrentContendedMonitor > GetOwnedMonitorStackDepthInfo > NotifyFramePop > > I'll check if we can use an existing bug to add this extra request. > Otherwise, will file new one. Filed this one: https://bugs.openjdk.java.net/browse/JDK-8034249 Thanks, Serguei > > Thanks, > Serguei > >> >> Dan >> >> >> >>> >>> Summary: >>> >>> This is the second round of review for this issue. >>> But it was decided that the JDK-8032223 must be used to cover it >>> instead of the JDK-6471769. >>> The 8032223 was initially closed as a dup of 6471769 but it has >>> been re-open now. >>> >>> There is a general issue in the suspend equivalent condition >>> mechanism: >>> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >>> may return different results: >>> - 1-st: true >>> - 2-nd: false >>> >>> This suspend equivalent issue is covered by another bug: >>> https://bugs.openjdk.java.net/browse/JDK-6280037 >>> >>> The bug to fix in this review is a specific manifestation of the >>> 6280037 >>> in the JVMTI GetFrameCount() that has a major impact on the SQE >>> nightly. >>> It is on the Test Stabilization radar as well as the 6280037. >>> There are many tests intermittently failing because of this. >>> I've also decided to fix the same issue in the JVMTI >>> GetFrameLocation() as well. >>> >>> The JVMTI GetFrameCount() spec tells: >>> "If this function is called for a thread actively executing >>> bytecodes (for example, >>> not the current thread and not suspended), the information >>> returned is transient." >>> >>> So, it is Ok to call the GetFrameCount() for the non-suspended >>> target thread. >>> To achieve safety, the frame count for non-suspended threads is >>> calculated at a safepoint. >>> It should be Ok and more safe to do the same for suspended threads >>> as well. >>> There should be no big performance impact because it is already on >>> a slow path. >>> It is still important to avoid safepointing when the target thread >>> is current. >>> >>> The bug 6280037 should go out of the Test Stabilization radar >>> (remove the svc-nightly label) >>> as the most of the impacted tests must be covered by the 8032223. >>> >>> >>> Testing: >>> In progress: >>> - nsk.jvmti, nsk.jdi, nsk.jdwp >>> - JTreg com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From yunda.mly at taobao.com Tue Feb 11 19:10:24 2014 From: yunda.mly at taobao.com (=?GB2312?B?1Ma07w==?= (Yunda)) Date: Wed, 12 Feb 2014 11:10:24 +0800 Subject: SA.NEXT - SA feedback needed In-Reply-To: <52EBB103.5090907@oracle.com> Message-ID: ?? 14-1-31 ????10:19?? "Dmitry Samersoff" ????: >Hi Everyone, > >I would like to start a discussion about future of hotspot debugger, >known as serviceability agent or SA. > >How you typically use it? What do you expect from it? What is missed? I use CLHSDB for knowing the internal structure of HotSpot since I work on it and I need to understand how it works. I also use jstack(-F,-m), jmap(dump heap) and CLHSDB(attach core file) to solve problems. I hope SA could be more stable and there could be more documents. Most material about SA I can get is from the blog of Kris(http://rednaxelafx.iteye.com/), which is written is Chinese. > >Please, share your stories and wishes. > >And please, fill the small quiz: > >1. How often do you use SA? I use it a lot. > >2. On what platform do you use SA? Mainly Linux/x64. > >3. Do you use it to analyze life processes or coredumps? Both. > >5. What other debuggers do you use to debug hotspot issues Gdb. > >-Dmitry > >-- >Dmitry Samersoff >Oracle Java development team, Saint Petersburg, Russia >* I would love to change the world, but they won't give me the sources. From henry.jen at oracle.com Tue Feb 11 21:18:04 2014 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 11 Feb 2014 21:18:04 -0800 Subject: RFR: 8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out In-Reply-To: <52EADC29.60209@oracle.com> References: <52EADC29.60209@oracle.com> Message-ID: <52FB040C.70205@oracle.com> Hi, The bug is reviewed by Vladimir Kozlov(kvn) and Christian Thalinger(twisti). I assume I can push this one(via JPRT to hs-rt) base on comment from Vladimir? Cheers, Henry https://bugs.openjdk.java.net/browse/JDK-8033215 On 01/30/2014 03:11 PM, Henry Jen wrote: > Hi, > > Please review a fix to disable uninitialized warning when build with > clang 3.4, > > http://cr.openjdk.java.net/~henryjen/jdk9/8033215/webrev/ > > This fix only disable the warning so that we can build with clang. > > Cheers, > Henry From vladimir.kozlov at oracle.com Tue Feb 11 22:09:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 11 Feb 2014 22:09:40 -0800 Subject: RFR: 8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out In-Reply-To: <52FB040C.70205@oracle.com> References: <52EADC29.60209@oracle.com> <52FB040C.70205@oracle.com> Message-ID: <52FB1024.9090403@oracle.com> On 2/11/14 9:18 PM, Henry Jen wrote: > Hi, > > The bug is reviewed by Vladimir Kozlov(kvn) and Christian Thalinger(twisti). > > I assume I can push this one(via JPRT to hs-rt) base on comment from Vladimir? Yes, it is reviewed. Please, push it into http://hg.openjdk.java.net/jdk9/hs-rt/hotspot Note for others, hs-comp is still closed - we are testing ppc64 port. Thanks, Vladimir > > Cheers, > Henry > > https://bugs.openjdk.java.net/browse/JDK-8033215 > > On 01/30/2014 03:11 PM, Henry Jen wrote: >> Hi, >> >> Please review a fix to disable uninitialized warning when build with >> clang 3.4, >> >> http://cr.openjdk.java.net/~henryjen/jdk9/8033215/webrev/ >> >> This fix only disable the warning so that we can build with clang. >> >> Cheers, >> Henry From magnus.ihse.bursie at oracle.com Tue Feb 11 23:17:29 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Feb 2014 08:17:29 +0100 Subject: RFR: JDK-8030350 : (s) Enable additional compiler warnings for GCC In-Reply-To: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> References: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> Message-ID: <52FB2009.1080309@oracle.com> On 2014-02-11 20:42, Mike Duigou wrote: > Hello all; > > This is a final update to the previously reviewed changeset. I had to make one slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to accommodate a problem which appeared since this process began. > > http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/ Looks good to me. /Magnus From erik.joelsson at oracle.com Wed Feb 12 00:42:19 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Feb 2014 09:42:19 +0100 Subject: RFR: JDK-8030350 : (s) Enable additional compiler warnings for GCC In-Reply-To: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> References: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> Message-ID: <52FB33EB.9050905@oracle.com> Hello Mike, Looks good to me. /Erik On 2014-02-11 20:42, Mike Duigou wrote: > Hello all; > > This is a final update to the previously reviewed changeset. I had to make one slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to accommodate a problem which appeared since this process began. > > http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/ > > This change will be integrated through the jdk9/hs-rt repos. > > From the original review request: > >> This is a change which enables additional compiler warnings for native compilation when using GCC. The (-Wformat -Wformat-security) options are supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) and later so we shouldn't see issues with incompatibility.- Wextra appears to have been added in GCC 3.4.X line (c. 2004) so it should also be reasonably well adopted and replaces -W. >> >> The core of the change is to add : >> >> -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 >> >> for general C and CC++ compilations. For HotSpot C++ compiles a slightly less aggressive set is used: >> >> -Wformat=2 -Wno-error=format-nonliteral >> >> is used. >> >> This change is targeted at the JDK 9 repos but could be backported to JDK 8 fairly easily/safely. > > Mike From serguei.spitsyn at oracle.com Wed Feb 12 02:41:08 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 12 Feb 2014 10:41:08 +0000 Subject: hg: hsx/jdk7u/hotspot: 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Message-ID: <20140212104113.72F8862BC3@hg.openjdk.java.net> Changeset: 4055c4ee8044 Author: sspitsyn Date: 2014-02-12 03:57 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/4055c4ee8044 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose Contributed-by: vladimir.ivanov at oracle.com, serguei.spitsyn at oracle.com ! src/share/vm/prims/methodHandles.cpp From markus.gronlund at oracle.com Wed Feb 12 05:28:38 2014 From: markus.gronlund at oracle.com (markus.gronlund at oracle.com) Date: Wed, 12 Feb 2014 13:28:38 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20140212132857.20E5962BCA@hg.openjdk.java.net> Changeset: ad22a9c14cd5 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ad22a9c14cd5 8033487: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: eec4f2185a7d Author: mgronlun Date: 2014-02-12 10:42 +0000 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/eec4f2185a7d Merge From erik.helin at oracle.com Wed Feb 12 07:03:39 2014 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 12 Feb 2014 16:03:39 +0100 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed Message-ID: <52FB8D4B.7080807@oracle.com> Hi all, this patch changes how old debug information copied from IMPORT_JDK is treated. When running the copy_*_jdk target, HotSpot's makefiles copies the entire IMPORT_JDK folder, including additional files (such as unzipped debug information). The export_*_jdk targets will then, via the generic_export target, copy the build artifacts via implicit rules to the correct destination in hotspot/build/JDK_IMAGE_DIR. The bug arises when IMPORT_JDK contains unzipped debug info (libjvm.debuginfo) and the make target produces zipped debug info (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then contain both libjvm.debuginfo and libjvm.diz, but only one of them will match libjvm.so. Finally, the JPRT make targets jprt_build_* just zips hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up having different zipped and unzipped debug info, since the IMPORT_JDK in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. This patch removes the debug info that we did *not* build. If we build libjvm.diz, then libjvm.debuginfo will be removed (if it exists). Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be removed (if it exists). Patch: http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8033580 Testing: - Building in JPRT - Building Linux 32-bit locally on a Linux 64-bit machine - Building Linux 64-bit locally on a Linux 64-bit machine For all of the above, verify that only the correct debug info is present in the output. Thanks, Erik From matthias.baesken at sap.com Wed Feb 12 07:48:03 2014 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 12 Feb 2014 15:48:03 +0000 Subject: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines Message-ID: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on Solaris Sparc, the VM crashes early when executed on T4 based machines (both T4 based Solaris Sparc10 and 11 machines); I cannot see the issue on older Sparc processors or Fujitsu SPARC64. The Crashes look like this : /results/SS12/images/j2sdk-image/bin/java -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/net/usr.work/d040975/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278), pid=27252, tid=2 # guarantee(klass_hash_ok(k, id)) failed: Bug in native code: jfieldID class must match object # # JRE version: (8.0) (build ) # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode solaris-sparc compressed oops) # Core dump written. Default location: //core or core.27252 # # An error report file with more information is saved as: # //hs_err_pid27252.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 2 Dumping core ... Abort (core dumped) With Stack in the hs_err file : --------------- T H R E A D --------------- Current thread (0x0000000100111800): JavaThread "main" [_thread_in_vm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] Stack: [0xffffffff7e200000,0xffffffff7e300000], sp=0xffffffff7e2fdd50, free space=1015k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xfc8824] void VMError::report_and_die()+0x504 V [libjvm.so+0x66ee70] void report_vm_error(const char*,int,const char*,const char*)+0x78 V [libjvm.so+0x925798] void jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8 V [libjvm.so+0x8f07a8] _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60 V [libjvm.so+0x953b8c] jni_GetFieldID+0x52c C [libjava.so+0xe46c] Java_java_io_FileInputStream_initIDs+0x44 j java.io.FileInputStream.initIDs()V+-373565320 j java.io.FileInputStream.initIDs()V+0 j java.io.FileInputStream.()V+0 v ~StubRoutines::call_stub V [libjvm.so+0x8fe0bc] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x82daac] void InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224 V [libjvm.so+0x82d7f8] void InstanceKlass::call_class_initializer(Thread*)+0x24 V [libjvm.so+0x82c260] void InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb08 V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c V [libjvm.so+0x8dad34] void InterpreterRuntime::_new(JavaThread*,ConstantPool*,int)+0x254 j java.lang.System.initializeSystemClass()V+37 v ~StubRoutines::call_stub V [libjvm.so+0x8fe0bc] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 V [libjvm.so+0x8fd31c] void JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 V [libjvm.so+0x8fd8bc] void JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80 V [libjvm.so+0xf3317c] int Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c V [libjvm.so+0x9772ec] JNI_CreateJavaVM+0xe4 C [libjli.so+0x7d9c] InitializeJVM+0x104 C [libjli.so+0x6220] JavaMain+0x68 When building with Sun Studio 12u1 (instead of 12) the crash does not occur, see : /results/SS12u1/images/j2sdk-image/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-b00) OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) Is this a known issue with SunStudio12 build results on T4 Processors ? I changed the used optimization flags in the fast-debug build from -xO4 to -xO2 and the problem disappeared. Could this be done in the configuration when SunStudio 12 is detected ? Thanks, Matthias From shanliang.jiang at oracle.com Tue Feb 11 06:13:46 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 11 Feb 2014 15:13:46 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed Message-ID: <52FA301A.2040301@oracle.com> Hi , The problem could be that FieldMonitor did not have enough time to "addFieldWatch" but the vm to monitor (TestPostFieldModification) was already ended. So we should make sure that TestPostFieldModification exits after FieldMonitor has done necessary. The solution proposed here is that FieldMonitor creates a file after adding field watching, and TestPostFieldModification quits only after finding the file. web: http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ bug: https://bugs.openjdk.java.net/browse/JDK-8007710 Thanks, Shanliang From shanliang.jiang at oracle.com Tue Feb 11 07:21:30 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 11 Feb 2014 16:21:30 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FA301A.2040301@oracle.com> References: <52FA301A.2040301@oracle.com> Message-ID: <52FA3FFA.70502@oracle.com> public web: http://cr.openjdk.java.net/~sjiang/JDK-8007710/00/ Shanliang shanliang wrote: > Hi , > > The problem could be that FieldMonitor did not have enough time to > "addFieldWatch" but the vm to monitor (TestPostFieldModification) was > already ended. > > So we should make sure that TestPostFieldModification exits after > FieldMonitor has done necessary. The solution proposed here is that > FieldMonitor creates a file after adding field watching, and > TestPostFieldModification quits only after finding the file. > > web: > http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8007710 > > Thanks, > Shanliang From shanliang.jiang at oracle.com Tue Feb 11 07:31:26 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 11 Feb 2014 16:31:26 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: References: <52FA301A.2040301@oracle.com> Message-ID: <52FA424E.2050202@oracle.com> Staffan Larsen wrote: > Hi Shanliang, > > I can?t quite see how the test can fail in this way. When the ClassPrepareEvent happens, the debuggee will be suspended. So when addFieldWatch() is called, the debuggee should not have moved. > I am not expert of jdi so I may miss something here. I checked the failure trace and saw the report exception happen when FieldMonitor received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did call "vm.resume()" before treating events. I reproduced the bug by add sleep(1000) after vm.resume() but before calling eventQueue.remove(); Thanks, Shanliang > One problem I do see with the test is that it does not wait for a VMStartEvent before setting up requests. I?m not sure if that could cause the failure in the bug report, though. > > /Staffan > > On 11 feb 2014, at 15:13, shanliang wrote: > > >> Hi , >> >> The problem could be that FieldMonitor did not have enough time to "addFieldWatch" but the vm to monitor (TestPostFieldModification) was already ended. >> >> So we should make sure that TestPostFieldModification exits after FieldMonitor has done necessary. The solution proposed here is that FieldMonitor creates a file after adding field watching, and TestPostFieldModification quits only after finding the file. >> >> web: >> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8007710 >> >> Thanks, >> Shanliang >> > > From tim.bell at oracle.com Wed Feb 12 08:21:26 2014 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 12 Feb 2014 08:21:26 -0800 Subject: RFR: JDK-8030350 : (s) Enable additional compiler warnings for GCC In-Reply-To: <52FB33EB.9050905@oracle.com> References: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> <52FB33EB.9050905@oracle.com> Message-ID: <52FB9F86.6020208@oracle.com> Mike- Looks good to me as well. Tim On 02/12/14 12:42 AM, Erik Joelsson wrote: > Hello Mike, > > Looks good to me. > > /Erik > > On 2014-02-11 20:42, Mike Duigou wrote: >> Hello all; >> >> This is a final update to the previously reviewed changeset. I had to >> make one slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to >> accommodate a problem which appeared since this process began. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/ >> >> This change will be integrated through the jdk9/hs-rt repos. >> >> From the original review request: >> >>> This is a change which enables additional compiler warnings for >>> native compilation when using GCC. The (-Wformat -Wformat-security) >>> options are supported by GCC 3.0.4 (the earliest version I checked, >>> c. February 2002) and later so we shouldn't see issues with >>> incompatibility.- Wextra appears to have been added in GCC 3.4.X >>> line (c. 2004) so it should also be reasonably well adopted and >>> replaces -W. >>> >>> The core of the change is to add : >>> >>> -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 >>> >>> for general C and CC++ compilations. For HotSpot C++ compiles a >>> slightly less aggressive set is used: >>> >>> -Wformat=2 -Wno-error=format-nonliteral >>> >>> is used. >>> >>> This change is targeted at the JDK 9 repos but could be backported >>> to JDK 8 fairly easily/safely. >> >> Mike > From volker.simonis at gmail.com Wed Feb 12 08:41:32 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 12 Feb 2014 17:41:32 +0100 Subject: RFR(S): 8034797 : AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280 Message-ID: Hi, could you please review this small change which imlements os::naked_short_sleep(jlong ms) on AIX after this was introduced by change "8028280: ParkEvent leak when running modified runThese which only loads classes" (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5944dba4badc) in the hs-rt repository: http://cr.openjdk.java.net/~simonis/webrevs/8034797/ https://bugs.openjdk.java.net/browse/JDK-8034797 Special care should be taken when pushing this change. I.e. the change is intended for hs-comp, but it shouldn't be pushed to hs-comp before hs-comp has synced change 8028280 from hs-rt. Thank you and best regards, Volker From stefan.johansson at oracle.com Wed Feb 12 09:12:48 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 12 Feb 2014 18:12:48 +0100 Subject: RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline In-Reply-To: <52FA3DD9.20004@oracle.com> References: <52E90809.3000900@oracle.com> <52F91199.6030308@oracle.com> <52FA3DD9.20004@oracle.com> Message-ID: <52FBAB90.1020608@oracle.com> Hi, Stefan K pointed out to me that in the Metaspace code we use is_init_completed() to verify that the VM is fully initialized. I started looking at where we do set_init_completed() and realized that it is right where we are ready to handle a GC. It makes sense to try to minimize the different ways we check if the VM is fully initialized. Using is_init_completed() instead of the GC locker to prevent GCs during startup has another nice effect too; we can remove one of the two different lock mechanisms in the GC locker. The new proposal removes the use of GC_locker::lock()/unlock() which is only used to prevent GCs during startup. Instead there is a check in the GC operations prologue, to ensure that the VM is initialized when the GC starts. Please review the new the change: http://cr.openjdk.java.net/~sjohanss/8028498/webrev.02/ Testing: * JPRT * GC locker test through UTE Thanks, Stefan On 2014-02-11 16:12, Stefan Johansson wrote: > Hi again =) > > Don't spend time on the current webrev (02). I've gotten some more > comments on the proposed fix and will look at a solution that allow us > to remove the GC locker usage during initialization. > > Cheers, > Stefan > > On 2014-02-10 18:51, Stefan Johansson wrote: >> Hi again, >> >> After a couple of offline discussions with different people I've come >> to the conclusion to split out the sizing of the young generation >> from the fix for this issue. I've created a new bug (JDK-8033426) for >> that, which is currently out for review. >> >> The discussions also lead to a different approach for fixing this >> issue. The new proposal is to use the GC locker to prevent GCs until >> we are ready to handle them and otherwise fail the VM initialization. >> The gc locker has two different mechanisms for locking out the GC, >> one which is used during initialization and one used to stall GCs >> when doing critical JNI work. The part of the initialization that >> currently is locked by the GC locker is to narrow and there is no >> guarantee that a GC can be handled after the GC locker is unlocked. >> This fix will extend the part that is locked and also add a check >> that if a GC is initiated while locked during startup the VM exits. >> >> New webrev: >> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.01/ >> >> Thanks, >> Stefan >> >> On 2014-01-29 14:54, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8028498 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/ >>> >>> Summary: >>> The initial young generation size has been fairly small by default >>> (1.5M) and if setting ObjectAlignmentInBytes to something larger >>> than the default it can causes CDS to trigger a GC when dumping the >>> archive. At this point the VM is not ready to handle a GC and we >>> will hit an assertion. Making sure we can handle a GC at this point >>> is not trivial and the proposed solution is to alter the default >>> sizing of the young generation as well as adding a safety check when >>> dumping the archive to exit the VM if the young generation is too >>> small. >>> >>> Testing: >>> * JPRT build and test passes >>> * Failing test now passes on all platforms (tested throught JPRT) >>> * Verified that the GC and Runtime jtreg tests still passes >>> >>> Cheers, >>> Stefan >> > From philip.race at oracle.com Wed Feb 12 10:32:44 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 12 Feb 2014 10:32:44 -0800 Subject: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines In-Reply-To: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> Message-ID: <52FBBE4C.6080600@oracle.com> The README-builds.html file specifies SS12 Update 1 + a bunch of patches There's probably a good reason for all of that and new architectures often need compiler fixes, so does the same occur if you upgrade and patch ? -phil. On 2/12/2014 7:48 AM, Baesken, Matthias wrote: > I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on Solaris Sparc, > the VM crashes early when executed on T4 based machines (both T4 based Solaris Sparc10 and 11 machines); > I cannot see the issue on older Sparc processors or Fujitsu SPARC64. > The Crashes look like this : > > > /results/SS12/images/j2sdk-image/bin/java -version > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/net/usr.work/d040975/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278), pid=27252, tid=2 > # guarantee(klass_hash_ok(k, id)) failed: Bug in native code: jfieldID class must match object > # > # JRE version: (8.0) (build ) > # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode solaris-sparc compressed oops) > # Core dump written. Default location: //core or core.27252 > # > # An error report file with more information is saved as: > # //hs_err_pid27252.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Current thread is 2 > Dumping core ... > Abort (core dumped) > > With Stack in the hs_err file : > > --------------- T H R E A D --------------- > > Current thread (0x0000000100111800): JavaThread "main" [_thread_in_vm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] > > Stack: [0xffffffff7e200000,0xffffffff7e300000], sp=0xffffffff7e2fdd50, free space=1015k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xfc8824] void VMError::report_and_die()+0x504 > V [libjvm.so+0x66ee70] void report_vm_error(const char*,int,const char*,const char*)+0x78 > V [libjvm.so+0x925798] void jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8 > V [libjvm.so+0x8f07a8] _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60 > V [libjvm.so+0x953b8c] jni_GetFieldID+0x52c > C [libjava.so+0xe46c] Java_java_io_FileInputStream_initIDs+0x44 > j java.io.FileInputStream.initIDs()V+-373565320 > j java.io.FileInputStream.initIDs()V+0 > j java.io.FileInputStream.()V+0 > v ~StubRoutines::call_stub > V [libjvm.so+0x8fe0bc] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 > V [libjvm.so+0x82daac] void InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224 > V [libjvm.so+0x82d7f8] void InstanceKlass::call_class_initializer(Thread*)+0x24 > V [libjvm.so+0x82c260] void InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb08 > V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c > V [libjvm.so+0x8dad34] void InterpreterRuntime::_new(JavaThread*,ConstantPool*,int)+0x254 > j java.lang.System.initializeSystemClass()V+37 > v ~StubRoutines::call_stub > V [libjvm.so+0x8fe0bc] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 > V [libjvm.so+0x8fd31c] void JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 > V [libjvm.so+0x8fd8bc] void JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 > V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80 > V [libjvm.so+0xf3317c] int Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c > V [libjvm.so+0x9772ec] JNI_CreateJavaVM+0xe4 > C [libjli.so+0x7d9c] InitializeJVM+0x104 > C [libjli.so+0x6220] JavaMain+0x68 > > > > When building with Sun Studio 12u1 (instead of 12) the crash does not occur, see : > > /results/SS12u1/images/j2sdk-image/bin/java -version > openjdk version "1.8.0-internal-fastdebug" > OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-b00) > OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) > > > Is this a known issue with SunStudio12 build results on T4 Processors ? > > I changed the used optimization flags in the fast-debug build from -xO4 to -xO2 and the problem disappeared. > Could this be done in the configuration when SunStudio 12 is detected ? > > Thanks, Matthias From john.r.rose at oracle.com Wed Feb 12 11:15:07 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 12 Feb 2014 11:15:07 -0800 Subject: Project to improve hs_err files In-Reply-To: References: Message-ID: <88AE7720-7874-4021-9671-63D1DDDF6D71@oracle.com> The hs_err file has grown to include lots of handy information. I agree that it would be reasonable to add more, and I'm really glad that you are thinking about it in this level of detail. This is especially good as you are an experienced consumer of these files. The typical size of such a file is currently about 40kb. As long as the most useful information is kept near the top, there is (IMO) room for this file to grow 2x or more in typical size. Some of the configuration information you mention may be present at the top of the hotspot.log file, before the big element. It might be fruitful to ensure that such preamble information is always captured at startup, and dumped into the log file. I don't think dump-time disassembly is practical, since we don't have an engine bundled in the JVM, but we should make it possible with post-processing to get a good disassembly from hex dumps in the error dump file. This has been done before; perhaps it needs reviving or refinement. Here's another thought, along the lines of symbolic disassembly, but for data rather than code: One thing I would like to see more of is memory contents, along with a way to interpret their meaning. The memory blocks around current PC and SP is supplied. It might be worth while dumping additional memory blocks one or two indirections away from the (apparent) pointers in those initial memory blocks. I often wonder, "is that the object I care about?" when looking at those memory dumps. I am guessing that there is a cheap, robust way to put more clues into the dump, without getting entangled in object parsing (which as David points out could cause further crashing). Perhaps there is a way to classify data words in a post-processing tool, like we can pull out disassembled code. At least, we can observe whether an apparent point refers into a live part of the heap (assuming we have the right few words of heap boundary info). We could also (maybe) identify Klass pointers in the headers of objects and output a little bit of data in the crash log to make it possible to identify the (apparent) classes of (apparent) object pointers in the regions dumped. At least the values of well-known classes (in SystemDictionary::_something), if they occur as the (apparent) classes of hex dump addresses, could be supplied as an extra hint. Clearly this could scale beyond the reasonable size of a crash dump, so some sort of size limit would need to be applied. (The size limit could be set to zero, or the log file section removed, if customers are nervous about memory dumps.) I think there is scope for tasteful engineering here, especially if we push fancy formatting work into a post-pass tool. Perhaps there is a way to join hands with the SA (serviceability agent) infrastructure, and run a tiny SA instance out of a relatively limited supply of hex dump from the crash file, instead of out of the full picture supplied by the core file or a live process. It's at least an interesting thought experiment. Please keep up this good work! ? John On Sep 9, 2013, at 10:38 AM, Mattis Castegren wrote: > Hi. I sent this email to serviceability and runtime, but I got a request to forward the mail to all of hotspot dev as hs_err files affects all areas. Please let me know if you have any feedback. Don't worry about if the suggestions are feasible or not, that will come in a second step. From christian.thalinger at oracle.com Wed Feb 12 12:06:51 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Feb 2014 12:06:51 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52F94BF1.30304@oracle.com> References: <52F94BF1.30304@oracle.com> Message-ID: Can we not use a macro for the message? OS_NATIVE_THREAD_CREATION_FAILED_MSG If you want to be able to override the message override the method. On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: > Please review a very small fix (JDK9): > > http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ > > Bug: The original "OutOfMemorError" message could be misleading when the > actual cause is the OS limit on number of processes/threads. > > https://bugs.openjdk.java.net/browse/JDK-7182040 > > Summary of fix: > > I changed all occurrence of the literal string "unable to create new native thread" > in the C code to call a common function os::native_thread_creation_failed_msg(). > > Individual OS ports may define an alternative message by defining the > OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp > > Here's a snap shot of the new message: > > java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory > or process/resource limits reached > at java.lang.Thread.start0(Native Method) > at java.lang.Thread.start(Thread.java:713) > at spin.main(spin.java:15) > > Tests: > > JPRT > > Thanks > - Ioi From christian.thalinger at oracle.com Wed Feb 12 12:16:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Feb 2014 12:16:28 -0800 Subject: RFR: 8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out In-Reply-To: <52FB1024.9090403@oracle.com> References: <52EADC29.60209@oracle.com> <52FB040C.70205@oracle.com> <52FB1024.9090403@oracle.com> Message-ID: <9F8F377E-FF42-4423-A351-EB8AB0E81D17@oracle.com> As discussed I filed: [#JDK-8034812] remove IDX_INIT macro hack in Node class - Java Bug System On Feb 11, 2014, at 10:09 PM, Vladimir Kozlov wrote: > On 2/11/14 9:18 PM, Henry Jen wrote: >> Hi, >> >> The bug is reviewed by Vladimir Kozlov(kvn) and Christian Thalinger(twisti). >> >> I assume I can push this one(via JPRT to hs-rt) base on comment from Vladimir? > > Yes, it is reviewed. Please, push it into http://hg.openjdk.java.net/jdk9/hs-rt/hotspot > Note for others, hs-comp is still closed - we are testing ppc64 port. > > Thanks, > Vladimir > >> >> Cheers, >> Henry >> >> https://bugs.openjdk.java.net/browse/JDK-8033215 >> >> On 01/30/2014 03:11 PM, Henry Jen wrote: >>> Hi, >>> >>> Please review a fix to disable uninitialized warning when build with >>> clang 3.4, >>> >>> http://cr.openjdk.java.net/~henryjen/jdk9/8033215/webrev/ >>> >>> This fix only disable the warning so that we can build with clang. >>> >>> Cheers, >>> Henry From vladimir.kozlov at oracle.com Wed Feb 12 12:37:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Feb 2014 12:37:58 -0800 Subject: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines In-Reply-To: <52FBBE4C.6080600@oracle.com> References: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> <52FBBE4C.6080600@oracle.com> Message-ID: <52FBDBA6.9070309@oracle.com> Matthias, You have to use the official version 12u1+patches to build jdk8 Hotspot for solaris. Thank you Phil for pointer to README-builds.html. When we updated to 12u1 we found few problems, that is why patches are also required. The compiler version string we use is: $ CC -V CC: Sun C++ 5.10 SunOS_sparc 128228-09 2010/06/24 Regards, Vladimir On 2/12/14 10:32 AM, Phil Race wrote: > The README-builds.html file specifies SS12 Update 1 + a bunch of patches > There's probably a good reason for all of that and new architectures often > need compiler fixes, so does the same occur if you upgrade and patch ? > > -phil. > > On 2/12/2014 7:48 AM, Baesken, Matthias wrote: >> I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on >> Solaris Sparc, >> the VM crashes early when executed on T4 based machines (both T4 based >> Solaris Sparc10 and 11 machines); >> I cannot see the issue on older Sparc processors or Fujitsu SPARC64. >> The Crashes look like this : >> >> >> /results/SS12/images/j2sdk-image/bin/java -version >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/net/usr.work/d040975/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278), >> pid=27252, tid=2 >> # guarantee(klass_hash_ok(k, id)) failed: Bug in native code: >> jfieldID class must match object >> # >> # JRE version: (8.0) (build ) >> # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode >> solaris-sparc compressed oops) >> # Core dump written. Default location: //core or core.27252 >> # >> # An error report file with more information is saved as: >> # //hs_err_pid27252.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> Current thread is 2 >> Dumping core ... >> Abort (core dumped) >> >> With Stack in the hs_err file : >> >> --------------- T H R E A D --------------- >> >> Current thread (0x0000000100111800): JavaThread "main" >> [_thread_in_vm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] >> >> Stack: [0xffffffff7e200000,0xffffffff7e300000], >> sp=0xffffffff7e2fdd50, free space=1015k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0xfc8824] void VMError::report_and_die()+0x504 >> V [libjvm.so+0x66ee70] void report_vm_error(const char*,int,const >> char*,const char*)+0x78 >> V [libjvm.so+0x925798] void >> jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8 >> V [libjvm.so+0x8f07a8] >> _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60 >> V [libjvm.so+0x953b8c] jni_GetFieldID+0x52c >> C [libjava.so+0xe46c] Java_java_io_FileInputStream_initIDs+0x44 >> j java.io.FileInputStream.initIDs()V+-373565320 >> j java.io.FileInputStream.initIDs()V+0 >> j java.io.FileInputStream.()V+0 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x8fe0bc] void >> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >> >> V [libjvm.so+0x82daac] void >> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224 >> >> V [libjvm.so+0x82d7f8] void >> InstanceKlass::call_class_initializer(Thread*)+0x24 >> V [libjvm.so+0x82c260] void >> InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb08 >> V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c >> V [libjvm.so+0x8dad34] void >> InterpreterRuntime::_new(JavaThread*,ConstantPool*,int)+0x254 >> j java.lang.System.initializeSystemClass()V+37 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x8fe0bc] void >> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >> >> V [libjvm.so+0x8fd31c] void >> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 >> >> V [libjvm.so+0x8fd8bc] void >> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 >> >> V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80 >> V [libjvm.so+0xf3317c] int >> Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c >> V [libjvm.so+0x9772ec] JNI_CreateJavaVM+0xe4 >> C [libjli.so+0x7d9c] InitializeJVM+0x104 >> C [libjli.so+0x6220] JavaMain+0x68 >> >> >> >> When building with Sun Studio 12u1 (instead of 12) the crash does not >> occur, see : >> >> /results/SS12u1/images/j2sdk-image/bin/java -version >> openjdk version "1.8.0-internal-fastdebug" >> OpenJDK Runtime Environment (build >> 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-b00) >> OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) >> >> >> Is this a known issue with SunStudio12 build results on T4 Processors ? >> >> I changed the used optimization flags in the fast-debug build from >> -xO4 to -xO2 and the problem disappeared. >> Could this be done in the configuration when SunStudio 12 is detected ? >> >> Thanks, Matthias > From ioi.lam at oracle.com Wed Feb 12 13:03:25 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 12 Feb 2014 13:03:25 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: References: <52F94BF1.30304@oracle.com> Message-ID: <52FBE19D.50708@oracle.com> Christian, It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. Thanks - Ioi On 2/12/14, 12:06 PM, Christian Thalinger wrote: > Can we not use a macro for the message? > > OS_NATIVE_THREAD_CREATION_FAILED_MSG > > If you want to be able to override the message override the method. > > On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: > >> Please review a very small fix (JDK9): >> >> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >> >> Bug: The original "OutOfMemorError" message could be misleading when the >> actual cause is the OS limit on number of processes/threads. >> >> https://bugs.openjdk.java.net/browse/JDK-7182040 >> >> Summary of fix: >> >> I changed all occurrence of the literal string "unable to create new native thread" >> in the C code to call a common function os::native_thread_creation_failed_msg(). >> >> Individual OS ports may define an alternative message by defining the >> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >> >> Here's a snap shot of the new message: >> >> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >> or process/resource limits reached >> at java.lang.Thread.start0(Native Method) >> at java.lang.Thread.start(Thread.java:713) >> at spin.main(spin.java:15) >> >> Tests: >> >> JPRT >> >> Thanks >> - Ioi From vladimir.kozlov at oracle.com Wed Feb 12 13:50:46 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Feb 2014 13:50:46 -0800 Subject: RFR(S): 8034797 : AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280 In-Reply-To: References: Message-ID: <52FBECB6.1060409@oracle.com> Looks fine to me. Please, remind me again about this fix when we open hs-comp and merge with main repo. We have a lot fixes to push after that and I may forget. Note, hs-comp testing should be finished this week. After that we will do merge. Thanks, Vladimir On 2/12/14 8:41 AM, Volker Simonis wrote: > Hi, > > could you please review this small change which imlements > os::naked_short_sleep(jlong ms) on AIX after this was introduced by > change "8028280: ParkEvent leak when running modified runThese which > only loads classes" > (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5944dba4badc) in > the hs-rt repository: > > http://cr.openjdk.java.net/~simonis/webrevs/8034797/ > https://bugs.openjdk.java.net/browse/JDK-8034797 > > Special care should be taken when pushing this change. I.e. the change > is intended for hs-comp, but it shouldn't be pushed to hs-comp before > hs-comp has synced change 8028280 from hs-rt. > > Thank you and best regards, > Volker > From christian.thalinger at oracle.com Wed Feb 12 14:35:01 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Feb 2014 14:35:01 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52FBE19D.50708@oracle.com> References: <52F94BF1.30304@oracle.com> <52FBE19D.50708@oracle.com> Message-ID: On Feb 12, 2014, at 1:03 PM, Ioi Lam wrote: > Christian, > > It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. Sigh. We have to stop including stuff into the middle of class declarations. This is such bad design. Is actually a port using a different message right now? > > Thanks > - Ioi > > On 2/12/14, 12:06 PM, Christian Thalinger wrote: >> Can we not use a macro for the message? >> >> OS_NATIVE_THREAD_CREATION_FAILED_MSG >> >> If you want to be able to override the message override the method. >> >> On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: >> >>> Please review a very small fix (JDK9): >>> >>> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >>> >>> Bug: The original "OutOfMemorError" message could be misleading when the >>> actual cause is the OS limit on number of processes/threads. >>> >>> https://bugs.openjdk.java.net/browse/JDK-7182040 >>> >>> Summary of fix: >>> >>> I changed all occurrence of the literal string "unable to create new native thread" >>> in the C code to call a common function os::native_thread_creation_failed_msg(). >>> >>> Individual OS ports may define an alternative message by defining the >>> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >>> >>> Here's a snap shot of the new message: >>> >>> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >>> or process/resource limits reached >>> at java.lang.Thread.start0(Native Method) >>> at java.lang.Thread.start(Thread.java:713) >>> at spin.main(spin.java:15) >>> >>> Tests: >>> >>> JPRT >>> >>> Thanks >>> - Ioi > From ioi.lam at oracle.com Wed Feb 12 15:17:53 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 12 Feb 2014 15:17:53 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: References: <52F94BF1.30304@oracle.com> <52FBE19D.50708@oracle.com> Message-ID: <52FC0121.5050401@oracle.com> On 2/12/14, 2:35 PM, Christian Thalinger wrote: > On Feb 12, 2014, at 1:03 PM, Ioi Lam wrote: > >> Christian, >> >> It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. > Sigh. We have to stop including stuff into the middle of class declarations. This is such bad design. > > Is actually a port using a different message right now? No, all ports are using the same message right now. - Ioi >> Thanks >> - Ioi >> >> On 2/12/14, 12:06 PM, Christian Thalinger wrote: >>> Can we not use a macro for the message? >>> >>> OS_NATIVE_THREAD_CREATION_FAILED_MSG >>> >>> If you want to be able to override the message override the method. >>> >>> On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: >>> >>>> Please review a very small fix (JDK9): >>>> >>>> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >>>> >>>> Bug: The original "OutOfMemorError" message could be misleading when the >>>> actual cause is the OS limit on number of processes/threads. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-7182040 >>>> >>>> Summary of fix: >>>> >>>> I changed all occurrence of the literal string "unable to create new native thread" >>>> in the C code to call a common function os::native_thread_creation_failed_msg(). >>>> >>>> Individual OS ports may define an alternative message by defining the >>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >>>> >>>> Here's a snap shot of the new message: >>>> >>>> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >>>> or process/resource limits reached >>>> at java.lang.Thread.start0(Native Method) >>>> at java.lang.Thread.start(Thread.java:713) >>>> at spin.main(spin.java:15) >>>> >>>> Tests: >>>> >>>> JPRT >>>> >>>> Thanks >>>> - Ioi From christian.thalinger at oracle.com Wed Feb 12 15:28:58 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Feb 2014 15:28:58 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52FC0121.5050401@oracle.com> References: <52F94BF1.30304@oracle.com> <52FBE19D.50708@oracle.com> <52FC0121.5050401@oracle.com> Message-ID: <98C1594B-C312-4784-882A-336DDD3B9896@oracle.com> On Feb 12, 2014, at 3:17 PM, Ioi Lam wrote: > > On 2/12/14, 2:35 PM, Christian Thalinger wrote: >> On Feb 12, 2014, at 1:03 PM, Ioi Lam wrote: >> >>> Christian, >>> >>> It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. >> Sigh. We have to stop including stuff into the middle of class declarations. This is such bad design. >> >> Is actually a port using a different message right now? > No, all ports are using the same message right now. Then let?s remove the macro and deal with a solution when we have to. > > - Ioi > >>> Thanks >>> - Ioi >>> >>> On 2/12/14, 12:06 PM, Christian Thalinger wrote: >>>> Can we not use a macro for the message? >>>> >>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG >>>> >>>> If you want to be able to override the message override the method. >>>> >>>> On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: >>>> >>>>> Please review a very small fix (JDK9): >>>>> >>>>> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >>>>> >>>>> Bug: The original "OutOfMemorError" message could be misleading when the >>>>> actual cause is the OS limit on number of processes/threads. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-7182040 >>>>> >>>>> Summary of fix: >>>>> >>>>> I changed all occurrence of the literal string "unable to create new native thread" >>>>> in the C code to call a common function os::native_thread_creation_failed_msg(). >>>>> >>>>> Individual OS ports may define an alternative message by defining the >>>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >>>>> >>>>> Here's a snap shot of the new message: >>>>> >>>>> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >>>>> or process/resource limits reached >>>>> at java.lang.Thread.start0(Native Method) >>>>> at java.lang.Thread.start(Thread.java:713) >>>>> at spin.main(spin.java:15) >>>>> >>>>> Tests: >>>>> >>>>> JPRT >>>>> >>>>> Thanks >>>>> - Ioi > From daniel.daugherty at oracle.com Wed Feb 12 15:40:51 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 12 Feb 2014 16:40:51 -0700 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FB8D4B.7080807@oracle.com> References: <52FB8D4B.7080807@oracle.com> Message-ID: <52FC0683.2010301@oracle.com> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ make/Makefile 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) 278 ifeq ($(OSNAME), windows) 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map $(EXPORT_SERVER_DIR)/jvm.pdb 280 else 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo 282 endif On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so you'll need a MacOS X specific rule. You don't need an update for the JVM_VARIANT_CLIENT version because MacOS X doesn't support the Client VM, but if it did... So the above change handles libjvm, but what about the other libraries exported by HotSpot? libjsig, libjvm_db, and libjvm_dtrace come to mind... Dan On 2/12/14 8:03 AM, Erik Helin wrote: > Hi all, > > this patch changes how old debug information copied from IMPORT_JDK is > treated. > > When running the copy_*_jdk target, HotSpot's makefiles copies the > entire IMPORT_JDK folder, including additional files (such as unzipped > debug information). The export_*_jdk targets will then, via the > generic_export target, copy the build artifacts via implicit rules to > the correct destination in hotspot/build/JDK_IMAGE_DIR. > > The bug arises when IMPORT_JDK contains unzipped debug info > (libjvm.debuginfo) and the make target produces zipped debug info > (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then > contain both libjvm.debuginfo and libjvm.diz, but only one of them > will match libjvm.so. > > Finally, the JPRT make targets jprt_build_* just zips > hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up > having different zipped and unzipped debug info, since the IMPORT_JDK > in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. > > This patch removes the debug info that we did *not* build. If we build > libjvm.diz, then libjvm.debuginfo will be removed (if it exists). > Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be > removed (if it exists). > > Patch: > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8033580 > > Testing: > - Building in JPRT > - Building Linux 32-bit locally on a Linux 64-bit machine > - Building Linux 64-bit locally on a Linux 64-bit machine > > For all of the above, verify that only the correct debug info is > present in the output. > > Thanks, > Erik From ioi.lam at oracle.com Wed Feb 12 15:49:55 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 12 Feb 2014 15:49:55 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <98C1594B-C312-4784-882A-336DDD3B9896@oracle.com> References: <52F94BF1.30304@oracle.com> <52FBE19D.50708@oracle.com> <52FC0121.5050401@oracle.com> <98C1594B-C312-4784-882A-336DDD3B9896@oracle.com> Message-ID: <52FC08A3.5060505@oracle.com> On 2/12/14, 3:28 PM, Christian Thalinger wrote: > On Feb 12, 2014, at 3:17 PM, Ioi Lam wrote: > >> On 2/12/14, 2:35 PM, Christian Thalinger wrote: >>> On Feb 12, 2014, at 1:03 PM, Ioi Lam wrote: >>> >>>> Christian, >>>> >>>> It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. >>> Sigh. We have to stop including stuff into the middle of class declarations. This is such bad design. >>> >>> Is actually a port using a different message right now? >> No, all ports are using the same message right now. > Then let?s remove the macro and deal with a solution when we have to. I think that's a good idea, except I already pushed the change :-( I think it's not a big issue so maybe we can clean that up next time this area is touched? - Ioi >> - Ioi >> >>>> Thanks >>>> - Ioi >>>> >>>> On 2/12/14, 12:06 PM, Christian Thalinger wrote: >>>>> Can we not use a macro for the message? >>>>> >>>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG >>>>> >>>>> If you want to be able to override the message override the method. >>>>> >>>>> On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: >>>>> >>>>>> Please review a very small fix (JDK9): >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >>>>>> >>>>>> Bug: The original "OutOfMemorError" message could be misleading when the >>>>>> actual cause is the OS limit on number of processes/threads. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-7182040 >>>>>> >>>>>> Summary of fix: >>>>>> >>>>>> I changed all occurrence of the literal string "unable to create new native thread" >>>>>> in the C code to call a common function os::native_thread_creation_failed_msg(). >>>>>> >>>>>> Individual OS ports may define an alternative message by defining the >>>>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >>>>>> >>>>>> Here's a snap shot of the new message: >>>>>> >>>>>> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >>>>>> or process/resource limits reached >>>>>> at java.lang.Thread.start0(Native Method) >>>>>> at java.lang.Thread.start(Thread.java:713) >>>>>> at spin.main(spin.java:15) >>>>>> >>>>>> Tests: >>>>>> >>>>>> JPRT >>>>>> >>>>>> Thanks >>>>>> - Ioi From alejandro.murillo at oracle.com Wed Feb 12 19:24:29 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 12 Feb 2014 20:24:29 -0700 Subject: Important reminders about adding info to CRs and backports Message-ID: <52FC3AED.6080902@oracle.com> In a nutshell: *refrain from creating backports or adding info to them unless is strictly necessary.** **always use the main bug number when creating changesets or adding keywords to** **request approval from the SQE or release team.* This has been discussed before, but a few people are still adding unnecessary bug info that is already done by the hgupdater. The hgupdater has basically automated the bug updating process, developers just need to make sure to create the changeset with the appropriate main bug number, the backport creation and subsequent bug updates will happen automatically when the changeset travels from the group repo to the appropriate master repo. When fixing a bug, please: (1) Always use the main bug number when creating the changeset. Do not create a backport or use a backport bug number (if one exists) in changesets. (2) Do not update "Fix version" and "Fixed in build" number fields. Only modify the bugs to add comments, and required keywords. (3) When requesting approval from the release and SQE teams, do that in the main bug, not in the backport. We are requesting the release team to enforce this as well. Once the changeset is pushed to a given group repo, that group repo is associated with a given JDK release, so the hgupdater will create, if it hasn't been created yet, a backport for that bug in the JDK release the repo is associated with and mark it as "Fixed in build" team. *NOTE: If the changeset is created using a backport bug number instead of the main bug number** **then the hgupdater will ignore the push and the developer is responsible for updating the** **bugs appropriately* Once the change is pushed to the master repo, the "Fixed in build" field of that backport will be marked as "master", the appropriate build number will be set next time that repo content is promoted by release engineering. please do not hesitate to contact me before pushing if you have any question Thanks -- Alejandro From david.holmes at oracle.com Wed Feb 12 19:54:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Feb 2014 13:54:39 +1000 Subject: RFR(S): 8034797 : AIX: Fix os::naked_short_sleep() in os_aix.cpp after 8028280 In-Reply-To: References: Message-ID: <52FC41FF.9070506@oracle.com> Looks fine to me. David On 13/02/2014 2:41 AM, Volker Simonis wrote: > Hi, > > could you please review this small change which imlements > os::naked_short_sleep(jlong ms) on AIX after this was introduced by > change "8028280: ParkEvent leak when running modified runThese which > only loads classes" > (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/5944dba4badc) in > the hs-rt repository: > > http://cr.openjdk.java.net/~simonis/webrevs/8034797/ > https://bugs.openjdk.java.net/browse/JDK-8034797 > > Special care should be taken when pushing this change. I.e. the change > is intended for hs-comp, but it shouldn't be pushed to hs-comp before > hs-comp has synced change 8028280 from hs-rt. > > Thank you and best regards, > Volker > From christian.thalinger at oracle.com Wed Feb 12 22:50:47 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 12 Feb 2014 22:50:47 -0800 Subject: RFR (XS) 7182040 - make native thread creation failure message more descriptive In-Reply-To: <52FC08A3.5060505@oracle.com> References: <52F94BF1.30304@oracle.com> <52FBE19D.50708@oracle.com> <52FC0121.5050401@oracle.com> <98C1594B-C312-4784-882A-336DDD3B9896@oracle.com> <52FC08A3.5060505@oracle.com> Message-ID: On Feb 12, 2014, at 3:49 PM, Ioi Lam wrote: > > On 2/12/14, 3:28 PM, Christian Thalinger wrote: >> On Feb 12, 2014, at 3:17 PM, Ioi Lam wrote: >> >>> On 2/12/14, 2:35 PM, Christian Thalinger wrote: >>>> On Feb 12, 2014, at 1:03 PM, Ioi Lam wrote: >>>> >>>>> Christian, >>>>> >>>>> It's not clear to me how to define a "generic" version of a method and override it in a port. In the "os" class, there aren't virtual methods. Also, the various os_.hpp files are included into the middle of the declaration of the "os" class. So it seems to me one way or another you have to use #ifdef. >>>> Sigh. We have to stop including stuff into the middle of class declarations. This is such bad design. >>>> >>>> Is actually a port using a different message right now? >>> No, all ports are using the same message right now. >> Then let?s remove the macro and deal with a solution when we have to. > I think that's a good idea, except I already pushed the change :-( I think it's not a big issue so maybe we can clean that up next time this area is touched? Sure. > > - Ioi > >>> - Ioi >>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> On 2/12/14, 12:06 PM, Christian Thalinger wrote: >>>>>> Can we not use a macro for the message? >>>>>> >>>>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG >>>>>> >>>>>> If you want to be able to override the message override the method. >>>>>> >>>>>> On Feb 10, 2014, at 2:00 PM, Ioi Lam wrote: >>>>>> >>>>>>> Please review a very small fix (JDK9): >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/7182040/thread_create_failed_msg_001/ >>>>>>> >>>>>>> Bug: The original "OutOfMemorError" message could be misleading when the >>>>>>> actual cause is the OS limit on number of processes/threads. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-7182040 >>>>>>> >>>>>>> Summary of fix: >>>>>>> >>>>>>> I changed all occurrence of the literal string "unable to create new native thread" >>>>>>> in the C code to call a common function os::native_thread_creation_failed_msg(). >>>>>>> >>>>>>> Individual OS ports may define an alternative message by defining the >>>>>>> OS_NATIVE_THREAD_CREATION_FAILED_MSG macro in os_.hpp >>>>>>> >>>>>>> Here's a snap shot of the new message: >>>>>>> >>>>>>> java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory >>>>>>> or process/resource limits reached >>>>>>> at java.lang.Thread.start0(Native Method) >>>>>>> at java.lang.Thread.start(Thread.java:713) >>>>>>> at spin.main(spin.java:15) >>>>>>> >>>>>>> Tests: >>>>>>> >>>>>>> JPRT >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi From magnus.ihse.bursie at oracle.com Wed Feb 12 23:26:46 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Feb 2014 08:26:46 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> Message-ID: <52FC73B6.7070701@oracle.com> On 2014-02-05 19:09, Volker Simonis wrote: > If there are any more/other comments on this topic I'll be highly interested. You can count on me having lots of opinion on build issues. ;-) I'd like to get rid of the hard-coded map files completely, both in hotspot and jdk. This can be done without loss of functionality. How? Because we can generate them on the fly at build time, using information provided by the source code. Note that the exported functions are prefixed by the macro JNIEXPORT. We can locate all functions that have this prefix and write them to a map file. This can be done, and was indeed the way we solved things back in the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" and check for a symbol name (as provided by nm). We had rules requiring that JNIEXPORT was to be written on the same line as the function name, or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" and then cross-reference for names extracted by nm. Not exactly a formal semantic parsing, but it was efficient and worked very well. I believe we can do something very similar for hotspot and jdk. Then again, if we could get rid of maps completely, by using visibility and not linking statically with the standard libs, that would be even better. :-) /Magnus From bourges.laurent at gmail.com Thu Feb 13 00:07:11 2014 From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=) Date: Thu, 13 Feb 2014 09:07:11 +0100 Subject: Fwd: Re: Fwd: Improve large array allocation / gc & intrinsics In-Reply-To: References: <1392114510.2707.33.camel@cirrus> Message-ID: Transfer to hotspot-dev list. Anybody else has an opinion related to array wastage / improvements ? Ps: using misc.Unsafe, it seems possible to allocate memory chunks and reallocate ie expand block without losing data. It may be possible to use such feature to provide more efficient growable arrays but it becomes unsafe and no [index] operator ! Using unsafe, it seems also possible to do "pointer arithmetics" ie accessing a matrix either as a 1d array or 2d or n dimensions. I could try making a prototype or maybe someone already evaluated such design and performed benchmarks ? Laurent ---------- Message transf?r? ---------- De : "Laurent Bourg?s" Date : 11 f?vr. 2014 17:41 Objet : Re: Fwd: Improve large array allocation / gc & intrinsics ? : "Thomas Schatzl" Cc : > Thomas, > Thanks a lot for your point of view and comments. > > Few more explanations: > > Two use cases: > - growable arrays like stringbuilder or int arrays in java2d pisces: the final site can not be estimated because it depends on application data, use cases or api missing features. In such cases arrays are created with an initial size. When it is not enough, a new larger array is created (zero filled) and data copied into (system.arraycopy). As you know, it leads to both memory waste depending on initial size and the growing factor and cpu due to array copies. There are many such use cases in jdk (collections, java2d...) > - image processing or science applications: arrays are created when needed like temporary objects so a lot of waste is created. For example, an image processing pipeline may create 1 image per stage instead of using an image pool .... or in java2d many arrays are created for each shape to render so it produces hundred megabytes that gc have to prune... > > It is also quite common to transform array dimensions: n dims <=> 1d. To do it, new arrays are created and data copied. A transformation api could help... but dealing directly on memory (memcpy) or direct access to the memory chunk like unsafe can. > > > > > I would like to propose a JDK9 RFE to improve JVM efficiency when > > > > dealing with large arrays (allocation + gc). > > > > > > > > In several scientific applications (and my patched java2d pisces), > > > > many large arrays are needed, created on the fly and it becomes very > > > > painful to recycle them using an efficient array cache (concurrency, > > > > cache size tuning, clear + cache eviction issues). > > > > Why do you think that a one-size fits all approach that any library in > > the JDK will not have the same issues to deal with? How do you know that > > a generic library in the JDK (as in your proposal) or hacking things > > into the VM can deal with this problem better than you who knows the > > application allocation patterns? > > As java developpers often do not care about memory allocation/gc, I think it is more efficient to handle efficiently arrays at the jdk level that will benefit to all applications. > > Alternatively a new API could be enough: GrowableArray and array transformer (dimension converter)... > > > > > Do you have a prototype (library) for that? > > Not really but I patched pisces to be more memory efficient: threadlocal context + array cache: https://github.com/bourgesl/marlin-renderer > > FYI I will try using off heap arrays to be even more efficient > > > > > > > In this case, the GC overhead leads to a big performance penalty > > > > (several hundred megabytes per seconds). > > > > I do not understand what the problem is. Typically I would not specify > > performance (throughput?) penalty in megabytes per seconds. > > I can give you numbers but I encountered very big slowdown due to growable arrays... > > > > > Do the GCs take too long, or do you feel there too much memory wastage > > somewhere? > > Too many waste and array copies. > > > > > > > As such array cache are very efficient in an application context, I am > > > > wondering if that approach could be promoted at the JDK level itself: > > > > > > > > - provide a new array allocator for large arrays that can return > > > > larger arrays than expected (size = 4 or 8 multiples) using array > > > > caches (per thread ?) stored in a dedicated JVM large memory area > > > > The behavior you propose seems very particular to your application. > > Others may have completely different requirements. The mentioned > > per-thread caches do not seem to be problematic to do in a library > > either. > > Of course but at jdk level it can boost any java application, not only mines ! > > > > > (GC aware) and providing efficient cache eviction policies > > > > Did you every try one of the other available garbage collectors with > > your application? Both CMS and G1 never move large objects around, i.e. > > there is almost no direct GC overhead associated with them. > > I am using CMS for my multithreaded benchmarks. However as there is too much waste, the gc overhead comes from heap traversal and scanning for live refs. > > > > > Reclaiming them is almost zero cost in these collectors. Keeping them > > alive seems to be best handled by logic in a library. > > > > Can you give examples where the VM has significant advantages over a > > dedicated library, or a particular use case with measurements that show > > this could be the case? > > To be investigated... I have the feeling that a c like realloc + copy could be efficient for growable arrays... > > > > > - may support for both clean arrays (zero filled) or dirty arrays > > > > because some algorithms does not need zero-filled arrays. > > > > > > > > - improve JVM intrinsics (array clear, fill) to achieve maximum > > > > performance ie take into account the data alignment (4 or 8 multiples) > > > > I think the compiler already uses specialized methods for that, using > > the "best" instructions that are available. It should also already be > > able to detect "fill" loops, and vectorize them. > > I think so but maybe new low level features could help. > > > Objects are always 8 byte aligned - I think you can force higher > > alignments by setting ObjectAlignmentInBytes or so. > Excellent. > > > > > Otherwise these changes could be simply added, i.e. seems to not need > > any RFE. > Great. > > > > > - upgrade GC to recycle such 'cached' arrays (clean), update usage > > > > statistics and manage cache eviction policy (avoid wasting memory) > > > > The GCs already automatically recycle the freed space. Everything else > > seems to be more complicated to implement at VM level than at library > > level, with the added drawback that you add a VM dependency. > > Ok maybe at jdk level it will be great. > > Thanks again, > Laurent From matthias.baesken at sap.com Thu Feb 13 04:02:46 2014 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 13 Feb 2014 12:02:46 +0000 Subject: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines In-Reply-To: <52FBDBA6.9070309@oracle.com> References: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> <52FBBE4C.6080600@oracle.com> <52FBDBA6.9070309@oracle.com> Message-ID: <98C2119538350A4E92B3DD08E7B4146853A12726@DEWDFEMB14B.global.corp.sap> Hi Vladimir / Phil , thank you for the answers . I'm aware of the README-builds.html. But it states also (besides of telling about using SunStudio 12u1) " The Oracle Solaris Studio Express compilers at: Oracle Solaris Studio Express Download site are also an option, although these compilers have not been extensively used yet." (and there is also still the old SunStudio 12 on the site ) So I wanted to give it a try (and configure works with it too pretty good). > > need compiler fixes, so does the same occur if you upgrade and patch ? > As stated in my original posting, with 12u1 +patches it works nicely , and I understand that you don't want to waste much time with older compilers. But Studio 12 is still interesting for us too (at least HS build part) . > When we updated to 12u1 we found few problems, that is why patches are > also required. Is there some public info about these problems and relation to the patches in the README ? Regards, Matthias -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Mittwoch, 12. Februar 2014 21:38 To: Phil Race; Baesken, Matthias; hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines Matthias, You have to use the official version 12u1+patches to build jdk8 Hotspot for solaris. Thank you Phil for pointer to README-builds.html. When we updated to 12u1 we found few problems, that is why patches are also required. The compiler version string we use is: $ CC -V CC: Sun C++ 5.10 SunOS_sparc 128228-09 2010/06/24 Regards, Vladimir On 2/12/14 10:32 AM, Phil Race wrote: > The README-builds.html file specifies SS12 Update 1 + a bunch of patches > There's probably a good reason for all of that and new architectures often > need compiler fixes, so does the same occur if you upgrade and patch ? > > -phil. > > On 2/12/2014 7:48 AM, Baesken, Matthias wrote: >> I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on >> Solaris Sparc, >> the VM crashes early when executed on T4 based machines (both T4 based >> Solaris Sparc10 and 11 machines); >> I cannot see the issue on older Sparc processors or Fujitsu SPARC64. >> The Crashes look like this : >> >> >> /results/SS12/images/j2sdk-image/bin/java -version >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> (/net/usr.work/d040975/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278), >> pid=27252, tid=2 >> # guarantee(klass_hash_ok(k, id)) failed: Bug in native code: >> jfieldID class must match object >> # >> # JRE version: (8.0) (build ) >> # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode >> solaris-sparc compressed oops) >> # Core dump written. Default location: //core or core.27252 >> # >> # An error report file with more information is saved as: >> # //hs_err_pid27252.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> Current thread is 2 >> Dumping core ... >> Abort (core dumped) >> >> With Stack in the hs_err file : >> >> --------------- T H R E A D --------------- >> >> Current thread (0x0000000100111800): JavaThread "main" >> [_thread_in_vm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] >> >> Stack: [0xffffffff7e200000,0xffffffff7e300000], >> sp=0xffffffff7e2fdd50, free space=1015k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0xfc8824] void VMError::report_and_die()+0x504 >> V [libjvm.so+0x66ee70] void report_vm_error(const char*,int,const >> char*,const char*)+0x78 >> V [libjvm.so+0x925798] void >> jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8 >> V [libjvm.so+0x8f07a8] >> _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60 >> V [libjvm.so+0x953b8c] jni_GetFieldID+0x52c >> C [libjava.so+0xe46c] Java_java_io_FileInputStream_initIDs+0x44 >> j java.io.FileInputStream.initIDs()V+-373565320 >> j java.io.FileInputStream.initIDs()V+0 >> j java.io.FileInputStream.()V+0 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x8fe0bc] void >> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >> >> V [libjvm.so+0x82daac] void >> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224 >> >> V [libjvm.so+0x82d7f8] void >> InstanceKlass::call_class_initializer(Thread*)+0x24 >> V [libjvm.so+0x82c260] void >> InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb08 >> V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c >> V [libjvm.so+0x8dad34] void >> InterpreterRuntime::_new(JavaThread*,ConstantPool*,int)+0x254 >> j java.lang.System.initializeSystemClass()V+37 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x8fe0bc] void >> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >> >> V [libjvm.so+0x8fd31c] void >> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 >> >> V [libjvm.so+0x8fd8bc] void >> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 >> >> V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80 >> V [libjvm.so+0xf3317c] int >> Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c >> V [libjvm.so+0x9772ec] JNI_CreateJavaVM+0xe4 >> C [libjli.so+0x7d9c] InitializeJVM+0x104 >> C [libjli.so+0x6220] JavaMain+0x68 >> >> >> >> When building with Sun Studio 12u1 (instead of 12) the crash does not >> occur, see : >> >> /results/SS12u1/images/j2sdk-image/bin/java -version >> openjdk version "1.8.0-internal-fastdebug" >> OpenJDK Runtime Environment (build >> 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-b00) >> OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) >> >> >> Is this a known issue with SunStudio12 build results on T4 Processors ? >> >> I changed the used optimization flags in the fast-debug build from >> -xO4 to -xO2 and the problem disappeared. >> Could this be done in the configuration when SunStudio 12 is detected ? >> >> Thanks, Matthias > From shanliang.jiang at oracle.com Thu Feb 13 09:15:38 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 13 Feb 2014 18:15:38 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> Message-ID: <52FCFDBA.5040108@oracle.com> Staffan, Very nice analysis! The fix must be very simple, just remove the line 108 vm.resume it is an error because here the test does not yet treat the events in eventSet. the line 136 eventSet.resume(); is the right place to resume the threads after event treatment. Here is the new webrev: http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ Thanks, Shanliang Staffan Larsen wrote: > I think I understand what happens now. > > The test code, simplified, looks like this (with the Thread.sleep() > added that causes the test to fail): > > launchTarget(); > addClassWatch(); > vm.resume(); > Thread.sleep(1000); > while(connected) { > eventSet = eventQueue.remove() > for(event : eventQueue) { > if (event instanceof ClassPrepareEvent) { > addFieldWatch(); > } > } > eventSet.resume(); > } > > By default all events that happen will cause the debuggee to suspend > (see EventRequest.setSuspendPolicy()). Thus when we get to > addFieldWatch(), the vm should be suspended and we should be able to > create the field watch without problem. But the VM isn?t suspended and > that is why the test fail. > > Why isn?t the VM suspended? When we get to the ?for(event : > eventQueue)? the first time there are *two* events already in the > queue: the VMStartEvent and a ClassPrepareEvent. At this point the VM > is suspended and everything is good. We look at the first eventSet > which only contains the VMStartEvent, we ignore the event, but we > resume the VM. We then loop and look at the ClassPrepareEvent, but by > now the VM is already running and has also terminated. Failure. > > Thus, we need to handle the VMStartEvent. I suggest a modification to > my previous code: > > launchTarget(); > while(connected) { > eventSet = eventQueue.remove() > for(event : eventQueue) { > if (event instanceof VMStartEvent) { > addClassWatch(); > } > if (event instanceof ClassPrepareEvent) { > addFieldWatch(); > } > } > eventSet.resume(); > } > > This will cause us to have complete control over the state of the > debuggee. The first event we see will be the VMStartEvent. The VM will > be suspended. We can add a class watch here. Then we resume the VM. > The second event we see will be the ClassPrepareEvent with the VM > suspended. We can add the field watch. Then we resume the VM and wait > for the field watch events. > > Thanks, > /Staffan > > On 13 feb 2014, at 11:36, shanliang > wrote: > >> Staffan Larsen wrote: >>> On 13 feb 2014, at 10:17, Jaroslav Bachorik wrote: >>> >>> >>>> Hi Staffan, >>>> >>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>> >>>>> I?m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can?t quite explain what goes wrong without the fix? I?d really like to understand that. I?ll try to dig deeper and see if I can understand exactly what happens. >>>>> >>>> Yes, bringing the VM to a stable state before calling other JDI functions helps to stabilize the test even without the additional synchronization via stdout/stdin. >>>> >>>> I just wonder whether this check should not be done inside com.sun.jdi.connect.LaunchingConnector#launch() implementation. Does it even make sense to hand off an unstable VM? >>>> >>> Good question, but hard to change now - all implementations depend on the current functionality. The VMStartEvent also gives you a reference to the main thread. >>> >> The test failed when it received ClassPrepareEvent and did >> addFieldWatch, that meant the test must receive already VMStartEvent, >> because VMStartEvent must be the first event, if it was true then the >> vm must be already stable when failing. >> >> Except that the test received ClassPrepareEvent before VMStartEvent >> then it was doing addFieldWatch with a possibly unstable VM. in this >> case we might have a serious bug in VirtualMachine implementation, >> and if this is true the fix proposed to check "start" may make miss >> ClassPrepareEvent, then the test would test nothing. >> >> Shanliang >>> /S >>> >>> >>>> -JB- >>>> >>>> >>>>> /Staffan >>>>> >>>>> On 12 feb 2014, at 18:04, shanliang wrote: >>>>> >>>>> >>>>>> Staffan Larsen wrote: >>>>>> >>>>>>> I think what you need to do is wait for the VMStartEvent before you add requests to the VM. Note this paragraph from the VirtualMachine doc: >>>>>>> >>>>>>> Note that a target VM launched by a launching connector is not >>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>> received. >>>>>>> >>>>>>> >>>>>> I may miss something here, I believe VMStartEvent must be the first event, when the test got ClassPrepareEvent, it must already received VMStartEvent. >>>>>> >>>>>>> I think adding code that looks something like this will make the test stable: >>>>>>> >>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>> >>>>>>> boolean started = false; >>>>>>> while(!started) { >>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>> for (Event event : eventSet) { >>>>>>> if (event instanceof VMStartEvent) { >>>>>>> started = true; >>>>>>> } >>>>>>> if (event instanceof VMDeathEvent >>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> System.out.println("Vm launched"); >>>>>>> >>>>>>> >>>>>> The code you proposed could improve the test, it made sure that TestPostFieldModification was started, but I am afraid that it did not address the issue causing the failure, the issue I believe was that TestPostFieldModification exited before or during FieldMonitor called addFieldWatch(), that was why addFieldWatch() received VMDisconnectedException. When the test was treating ClassPrepareEvent, even if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the eventQueue because it arrived after ClassPrepareEvent. >>>>>> >>>>>> My fix was to not allow TestPostFieldModification to exit before addFieldWatch() was done. >>>>>> >>>>>>> There is also no reason to call addFieldWatch() before the ClassPrepareEvent has been received. The call to vm..classesByName() will just return an empty list anyway. >>>>>>> >>>>>>> >>>>>> I do not know why the test called addFieldWatch before ClassPrepareEvent had been received, but yes the returned list was empty, so agree to remove it. >>>>>> >>>>>>> While you are in there you can also remove the unused StringBuffer near the top of main(). >>>>>>> >>>>>>> >>>>>> Yes it was already removed in version 01 >>>>>> >>>>>> Here is the new webrev: >>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>> >>>>>> Thanks, >>>>>> Shanliang >>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 11 feb 2014, at 18:30, shanliang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Here is the new fix in which FieldMonitor will write to TestPostFieldModification, to inform the latter to quit, as suggested bu Jaroslav >>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>> >>>>>>>> shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>> >>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When the >>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee death. The gc() invoking thread "d" is flagged as a deamon and as such doesn't prevent the process from exiting. The other thread is not a daemon but will finish in only few cycles. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of the method "resume": >>>>>>>>>> /** >>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>> * >>>>>>>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}. >>>>>>>>>> * >>>>>>>>>> * @see #suspend >>>>>>>>>> */ >>>>>>>>>> void resume(); >>>>>>>>>> My understanding is that the debuggee resumes to work after this call, instead to die? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> In fact the problem is here, the vm (TestPostFieldModification) should not die before FieldMonitor finishes addFieldWatch. >>>>>>>>> >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It looks like some kind of synchronization between the debugger and the debuggee is necessary. But I wonder if you should better use the process.getOuptuptStream() to write and flush a message for the debugee indicating that it can exit. And in the debugee you would just do System.in.read() as the last statement in the main() method. Seems more robust than involving files. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> It could work, but creating a file in the testing directory should have no issue, but yes maybe less performance. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> -JB- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if that could >>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>>>>> >>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>> >>>>>>>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>>>>>>> >>>>>>>>>>>>>> web: >>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>> >>>>> >>> >> >> > From vladimir.kozlov at oracle.com Thu Feb 13 10:56:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Feb 2014 10:56:40 -0800 Subject: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines In-Reply-To: <98C2119538350A4E92B3DD08E7B4146853A12726@DEWDFEMB14B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146853A12473@DEWDFEMB14B.global.corp.sap> <52FBBE4C.6080600@oracle.com> <52FBDBA6.9070309@oracle.com> <98C2119538350A4E92B3DD08E7B4146853A12726@DEWDFEMB14B.global.corp.sap> Message-ID: <52FD1568.40605@oracle.com> I don't think there is any public info about that. Back in 2010 when we switched to new compilers (Visual Studio, gcc and SunStudio) during jdk7 development we wanted to use SS12 first. But it did not work for us. Below is our internal mail which listed the problem. As result we have to use 12u1 and patches. I can't find the reasoning for patches, they could be recommended by SunStudio group. Regards, Vladimir On 6/10/10 2:59 PM, John Coomes wrote: > Hi, > > Starting a new thread on this old topic. > > We (hotspot) need to get the solaris jdk7 tools updated. We now have > a second pain point because of bug(s) in the current ss12 optimizer: > > 6950537 G1+COOPS: gcbasher crashes during evacuation failure > > This is a crash caused by incorrect optimization. The initial pain > point has so far prevented the fix for > > 6423256 GC stacks should use a better data structure > > from being integrated into jdk7. This bug was escalated and fixed in > a jdk6 update, so is required in jdk7 to prevent regressions. > > In both cases, compiling with ss12u1 + patches avoids the problem, and > so does compiling with ss11 (so jdk6 updates are not affected). > On 2/13/14 4:02 AM, Baesken, Matthias wrote: > Hi Vladimir / Phil , thank you for the answers . > I'm aware of the README-builds.html. > > But it states also (besides of telling about using SunStudio 12u1) > > " The Oracle Solaris Studio Express compilers at: Oracle Solaris Studio Express Download site are also an option, although these compilers have not been extensively used yet." > > (and there is also still the old SunStudio 12 on the site ) > So I wanted to give it a try (and configure works with it too pretty good). > > > > > need compiler fixes, so does the same occur if you upgrade and patch ? > > > > As stated in my original posting, with 12u1 +patches it works nicely , and I understand that you don't want to waste much time with older compilers. > But Studio 12 is still interesting for us too (at least HS build part) . > > > > When we updated to 12u1 we found few problems, that is why patches are > > also required. > > Is there some public info about these problems and relation to the patches in the README ? > > Regards, Matthias > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Mittwoch, 12. Februar 2014 21:38 > To: Phil Race; Baesken, Matthias; hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net > Subject: Re: Open JDK8 fast-debug : crashes on Solaris Sparc T4 machines > > Matthias, > > You have to use the official version 12u1+patches to build jdk8 Hotspot > for solaris. Thank you Phil for pointer to README-builds.html. > > When we updated to 12u1 we found few problems, that is why patches are > also required. > > The compiler version string we use is: > > $ CC -V > CC: Sun C++ 5.10 SunOS_sparc 128228-09 2010/06/24 > > Regards, > Vladimir > > On 2/12/14 10:32 AM, Phil Race wrote: >> The README-builds.html file specifies SS12 Update 1 + a bunch of patches >> There's probably a good reason for all of that and new architectures often >> need compiler fixes, so does the same occur if you upgrade and patch ? >> >> -phil. >> >> On 2/12/2014 7:48 AM, Baesken, Matthias wrote: >>> I noticed when building Open JDK 8 fast-debug with Sun Studio 12 on >>> Solaris Sparc, >>> the VM crashes early when executed on T4 based machines (both T4 based >>> Solaris Sparc10 and 11 machines); >>> I cannot see the issue on older Sparc processors or Fujitsu SPARC64. >>> The Crashes look like this : >>> >>> >>> /results/SS12/images/j2sdk-image/bin/java -version >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/jni.cpp:278 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> (/net/usr.work/d040975/open_jdk/jdk8_2/hotspot/src/share/vm/prims/jni.cpp:278), >>> pid=27252, tid=2 >>> # guarantee(klass_hash_ok(k, id)) failed: Bug in native code: >>> jfieldID class must match object >>> # >>> # JRE version: (8.0) (build ) >>> # Java VM: OpenJDK 64-Bit Server VM (25.0-b69-fastdebug mixed mode >>> solaris-sparc compressed oops) >>> # Core dump written. Default location: //core or core.27252 >>> # >>> # An error report file with more information is saved as: >>> # //hs_err_pid27252.log >>> # >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.sun.com/bugreport/crash.jsp >>> # >>> Current thread is 2 >>> Dumping core ... >>> Abort (core dumped) >>> >>> With Stack in the hs_err file : >>> >>> --------------- T H R E A D --------------- >>> >>> Current thread (0x0000000100111800): JavaThread "main" >>> [_thread_in_vm, id=2, stack(0xffffffff7e200000,0xffffffff7e300000)] >>> >>> Stack: [0xffffffff7e200000,0xffffffff7e300000], >>> sp=0xffffffff7e2fdd50, free space=1015k >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>> V [libjvm.so+0xfc8824] void VMError::report_and_die()+0x504 >>> V [libjvm.so+0x66ee70] void report_vm_error(const char*,int,const >>> char*,const char*)+0x78 >>> V [libjvm.so+0x925798] void >>> jfieldIDWorkaround::verify_instance_jfieldID(Klass*,_jfieldID*)+0xa8 >>> V [libjvm.so+0x8f07a8] >>> _jfieldID*jfieldIDWorkaround::to_instance_jfieldID(Klass*,int)+0x60 >>> V [libjvm.so+0x953b8c] jni_GetFieldID+0x52c >>> C [libjava.so+0xe46c] Java_java_io_FileInputStream_initIDs+0x44 >>> j java.io.FileInputStream.initIDs()V+-373565320 >>> j java.io.FileInputStream.initIDs()V+0 >>> j java.io.FileInputStream.()V+0 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x8fe0bc] void >>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >>> >>> V [libjvm.so+0x82daac] void >>> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,Thread*)+0x224 >>> >>> V [libjvm.so+0x82d7f8] void >>> InstanceKlass::call_class_initializer(Thread*)+0x24 >>> V [libjvm.so+0x82c260] void >>> InstanceKlass::initialize_impl(instanceKlassHandle,Thread*)+0xb08 >>> V [libjvm.so+0x82a82c] void InstanceKlass::initialize(Thread*)+0x5c >>> V [libjvm.so+0x8dad34] void >>> InterpreterRuntime::_new(JavaThread*,ConstantPool*,int)+0x254 >>> j java.lang.System.initializeSystemClass()V+37 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x8fe0bc] void >>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x4e4 >>> >>> V [libjvm.so+0x8fd31c] void >>> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x104 >>> >>> V [libjvm.so+0x8fd8bc] void >>> JavaCalls::call_static(JavaValue*,KlassHandle,Symbol*,Symbol*,Thread*)+0x64 >>> >>> V [libjvm.so+0xf27f80] void call_initializeSystemClass(Thread*)+0x80 >>> V [libjvm.so+0xf3317c] int >>> Threads::create_vm(JavaVMInitArgs*,bool*)+0x76c >>> V [libjvm.so+0x9772ec] JNI_CreateJavaVM+0xe4 >>> C [libjli.so+0x7d9c] InitializeJVM+0x104 >>> C [libjli.so+0x6220] JavaMain+0x68 >>> >>> >>> >>> When building with Sun Studio 12u1 (instead of 12) the crash does not >>> occur, see : >>> >>> /results/SS12u1/images/j2sdk-image/bin/java -version >>> openjdk version "1.8.0-internal-fastdebug" >>> OpenJDK Runtime Environment (build >>> 1.8.0-internal-fastdebug-d040975_2014_02_12_15_29-b00) >>> OpenJDK 64-Bit Server VM (build 25.0-b69-fastdebug, mixed mode) >>> >>> >>> Is this a known issue with SunStudio12 build results on T4 Processors ? >>> >>> I changed the used optimization flags in the fast-debug build from >>> -xO4 to -xO2 and the problem disappeared. >>> Could this be done in the configuration when SunStudio 12 is detected ? >>> >>> Thanks, Matthias >> From shanliang.jiang at oracle.com Thu Feb 13 12:15:20 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 13 Feb 2014 21:15:20 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FCFDBA.5040108@oracle.com> References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> <52FCFDBA.5040108@oracle.com> Message-ID: <52FD27D8.8060200@oracle.com> Hi, Here is Version 4: http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/ 1) remove the line 108 vm.resume() 2) call addClassWatch(vm) only when receiving VMStartEvent 3) make sure that the test receives ModificationWatchpointEvent 4) clean Thanks, Shanliang shanliang wrote: > Staffan, > > Very nice analysis! > > The fix must be very simple, just remove the line > 108 vm.resume > it is an error because here the test does not yet treat the events in > eventSet. > > the line > 136 eventSet.resume(); > is the right place to resume the threads after event treatment. > > Here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ > > Thanks, > Shanliang > > Staffan Larsen wrote: >> I think I understand what happens now. >> >> The test code, simplified, looks like this (with the Thread.sleep() >> added that causes the test to fail): >> >> launchTarget(); >> addClassWatch(); >> vm.resume(); >> Thread.sleep(1000); >> while(connected) { >> eventSet = eventQueue.remove() >> for(event : eventQueue) { >> if (event instanceof ClassPrepareEvent) { >> addFieldWatch(); >> } >> } >> eventSet.resume(); >> } >> >> By default all events that happen will cause the debuggee to suspend >> (see EventRequest.setSuspendPolicy()). Thus when we get to >> addFieldWatch(), the vm should be suspended and we should be able to >> create the field watch without problem. But the VM isn?t suspended >> and that is why the test fail. >> >> Why isn?t the VM suspended? When we get to the ?for(event : >> eventQueue)? the first time there are *two* events already in the >> queue: the VMStartEvent and a ClassPrepareEvent. At this point the VM >> is suspended and everything is good. We look at the first eventSet >> which only contains the VMStartEvent, we ignore the event, but we >> resume the VM. We then loop and look at the ClassPrepareEvent, but by >> now the VM is already running and has also terminated. Failure. >> >> Thus, we need to handle the VMStartEvent. I suggest a modification to >> my previous code: >> >> launchTarget(); >> while(connected) { >> eventSet = eventQueue.remove() >> for(event : eventQueue) { >> if (event instanceof VMStartEvent) { >> addClassWatch(); >> } >> if (event instanceof ClassPrepareEvent) { >> addFieldWatch(); >> } >> } >> eventSet.resume(); >> } >> >> This will cause us to have complete control over the state of the >> debuggee. The first event we see will be the VMStartEvent. The VM >> will be suspended. We can add a class watch here. Then we resume the >> VM. The second event we see will be the ClassPrepareEvent with the VM >> suspended. We can add the field watch. Then we resume the VM and wait >> for the field watch events. >> >> Thanks, >> /Staffan >> >> On 13 feb 2014, at 11:36, shanliang > > wrote: >> >>> Staffan Larsen wrote: >>>> On 13 feb 2014, at 10:17, Jaroslav Bachorik wrote: >>>> >>>> >>>>> Hi Staffan, >>>>> >>>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>>> >>>>>> I?m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can?t quite explain what goes wrong without the fix? I?d really like to understand that. I?ll try to dig deeper and see if I can understand exactly what happens. >>>>>> >>>>> Yes, bringing the VM to a stable state before calling other JDI functions helps to stabilize the test even without the additional synchronization via stdout/stdin. >>>>> >>>>> I just wonder whether this check should not be done inside com.sun.jdi.connect.LaunchingConnector#launch() implementation. Does it even make sense to hand off an unstable VM? >>>>> >>>> Good question, but hard to change now - all implementations depend on the current functionality. The VMStartEvent also gives you a reference to the main thread. >>>> >>> The test failed when it received ClassPrepareEvent and did >>> addFieldWatch, that meant the test must receive already >>> VMStartEvent, because VMStartEvent must be the first event, if it >>> was true then the vm must be already stable when failing. >>> >>> Except that the test received ClassPrepareEvent before VMStartEvent >>> then it was doing addFieldWatch with a possibly unstable VM. in this >>> case we might have a serious bug in VirtualMachine implementation, >>> and if this is true the fix proposed to check "start" may make miss >>> ClassPrepareEvent, then the test would test nothing. >>> >>> Shanliang >>>> /S >>>> >>>> >>>>> -JB- >>>>> >>>>> >>>>>> /Staffan >>>>>> >>>>>> On 12 feb 2014, at 18:04, shanliang wrote: >>>>>> >>>>>> >>>>>>> Staffan Larsen wrote: >>>>>>> >>>>>>>> I think what you need to do is wait for the VMStartEvent before you add requests to the VM. Note this paragraph from the VirtualMachine doc: >>>>>>>> >>>>>>>> Note that a target VM launched by a launching connector is not >>>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>>> received. >>>>>>>> >>>>>>>> >>>>>>> I may miss something here, I believe VMStartEvent must be the first event, when the test got ClassPrepareEvent, it must already received VMStartEvent. >>>>>>> >>>>>>>> I think adding code that looks something like this will make the test stable: >>>>>>>> >>>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>>> >>>>>>>> boolean started = false; >>>>>>>> while(!started) { >>>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>>> for (Event event : eventSet) { >>>>>>>> if (event instanceof VMStartEvent) { >>>>>>>> started = true; >>>>>>>> } >>>>>>>> if (event instanceof VMDeathEvent >>>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> System.out.println("Vm launched"); >>>>>>>> >>>>>>>> >>>>>>> The code you proposed could improve the test, it made sure that TestPostFieldModification was started, but I am afraid that it did not address the issue causing the failure, the issue I believe was that TestPostFieldModification exited before or during FieldMonitor called addFieldWatch(), that was why addFieldWatch() received VMDisconnectedException. When the test was treating ClassPrepareEvent, even if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the eventQueue because it arrived after ClassPrepareEvent. >>>>>>> >>>>>>> My fix was to not allow TestPostFieldModification to exit before addFieldWatch() was done. >>>>>>> >>>>>>>> There is also no reason to call addFieldWatch() before the ClassPrepareEvent has been received. The call to vm..classesByName() will just return an empty list anyway. >>>>>>>> >>>>>>>> >>>>>>> I do not know why the test called addFieldWatch before ClassPrepareEvent had been received, but yes the returned list was empty, so agree to remove it. >>>>>>> >>>>>>>> While you are in there you can also remove the unused StringBuffer near the top of main(). >>>>>>>> >>>>>>>> >>>>>>> Yes it was already removed in version 01 >>>>>>> >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Shanliang >>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 11 feb 2014, at 18:30, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Here is the new fix in which FieldMonitor will write to TestPostFieldModification, to inform the latter to quit, as suggested bu Jaroslav >>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>> shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When the >>>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>>>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee death. The gc() invoking thread "d" is flagged as a deamon and as such doesn't prevent the process from exiting. The other thread is not a daemon but will finish in only few cycles. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of the method "resume": >>>>>>>>>>> /** >>>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>>> * >>>>>>>>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}. >>>>>>>>>>> * >>>>>>>>>>> * @see #suspend >>>>>>>>>>> */ >>>>>>>>>>> void resume(); >>>>>>>>>>> My understanding is that the debuggee resumes to work after this call, instead to die? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> In fact the problem is here, the vm (TestPostFieldModification) should not die before FieldMonitor finishes addFieldWatch. >>>>>>>>>> >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> It looks like some kind of synchronization between the debugger and the debuggee is necessary. But I wonder if you should better use the process.getOuptuptStream() to write and flush a message for the debugee indicating that it can exit. And in the debugee you would just do System.in.read() as the last statement in the main() method. Seems more robust than involving files. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It could work, but creating a file in the testing directory should have no issue, but yes maybe less performance. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Shanliang >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if that could >>>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Staffan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> web: >>>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >> > From erik.helin at oracle.com Thu Feb 13 12:59:04 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 13 Feb 2014 21:59:04 +0100 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FC0683.2010301@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> Message-ID: <52FD3218.9010403@oracle.com> Hi Dan, thanks for reviewing! See my replies inline. On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ > > make/Makefile > 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) > 278 ifeq ($(OSNAME), windows) > 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map > $(EXPORT_SERVER_DIR)/jvm.pdb > 280 else > 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo > 282 endif > > On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so > you'll need a MacOS X specific rule. You don't need an > update for the JVM_VARIANT_CLIENT version because MacOS X > doesn't support the Client VM, but if it did... Thanks for catching this! I've uploaded a new webrev at: http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ The same testing was done as for the first patch. On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: > So the above change handles libjvm, but what about the > other libraries exported by HotSpot? libjsig, libjvm_db, > and libjvm_dtrace come to mind... As we discussed, I would like to implement this for libjvm first and then take care of the other libraries in a separate patch. Thanks, Erik > Dan > > > On 2/12/14 8:03 AM, Erik Helin wrote: >> Hi all, >> >> this patch changes how old debug information copied from IMPORT_JDK is >> treated. >> >> When running the copy_*_jdk target, HotSpot's makefiles copies the >> entire IMPORT_JDK folder, including additional files (such as unzipped >> debug information). The export_*_jdk targets will then, via the >> generic_export target, copy the build artifacts via implicit rules to >> the correct destination in hotspot/build/JDK_IMAGE_DIR. >> >> The bug arises when IMPORT_JDK contains unzipped debug info >> (libjvm.debuginfo) and the make target produces zipped debug info >> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >> contain both libjvm.debuginfo and libjvm.diz, but only one of them >> will match libjvm.so. >> >> Finally, the JPRT make targets jprt_build_* just zips >> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >> having different zipped and unzipped debug info, since the IMPORT_JDK >> in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. >> >> This patch removes the debug info that we did *not* build. If we build >> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be >> removed (if it exists). >> >> Patch: >> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8033580 >> >> Testing: >> - Building in JPRT >> - Building Linux 32-bit locally on a Linux 64-bit machine >> - Building Linux 64-bit locally on a Linux 64-bit machine >> >> For all of the above, verify that only the correct debug info is >> present in the output. >> >> Thanks, >> Erik > From jon.masamitsu at oracle.com Thu Feb 13 13:39:14 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Thu, 13 Feb 2014 13:39:14 -0800 Subject: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> Message-ID: <52FD3B82.5020806@oracle.com> This is a very nice change. Thanks. Looks good. Jon On 02/11/2014 01:02 AM, Lindenmaier, Goetz wrote: > Hi, > > The template template parameters in the binaryTreeDictionary are not > needed to express its functionality. This change replaces them by simple > class templates and explicit instantiation. This simplifies consumption of > the openJDK in scenarios requiring older C++ compilers. > > This change also removes dead get_chunk() from binaryTreeDictionary.cpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8034171 > webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8034171-1-templ/ > > Please review and test this change. Unfortunately I don't have access > to JPRT, so I need a sponsor. > > > I compiled this change on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with SS12u1, > > on windows amd64 and on sparc. I tested dbg, fdbg and opt builds. The change ran with all our tests > > on the ppc port, including jbb2013, jvm2008 and parts of a well-known, publicly > > not available test suite without problems. > > > > I would like to downport this change to jdk8u targeting u20 later on. > > > > Could you please also check whether I filed the bug correctly? What should > > I put into "affected versions"? > > > > Thanks and best regards, > > Goetz. > > > From daniel.daugherty at oracle.com Thu Feb 13 15:29:53 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 13 Feb 2014 16:29:53 -0700 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FD3218.9010403@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> Message-ID: <52FD5571.4010104@oracle.com> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ make/Makefile + ifeq ($(OSNAME), bsd) + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM The above needs to be: ifeq ($(OS_VENDOR), Darwin) $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM I don't think that BSD uses .dylib stuff; that's MacOS X specific. Dan On 2/13/14 1:59 PM, Erik Helin wrote: > Hi Dan, > > thanks for reviewing! See my replies inline. > > On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >> >> make/Makefile >> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >> 278 ifeq ($(OSNAME), windows) >> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >> $(EXPORT_SERVER_DIR)/jvm.pdb >> 280 else >> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >> 282 endif >> >> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >> you'll need a MacOS X specific rule. You don't need an >> update for the JVM_VARIANT_CLIENT version because MacOS X >> doesn't support the Client VM, but if it did... > > Thanks for catching this! I've uploaded a new webrev at: > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ > > The same testing was done as for the first patch. > > On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >> So the above change handles libjvm, but what about the >> other libraries exported by HotSpot? libjsig, libjvm_db, >> and libjvm_dtrace come to mind... > > As we discussed, I would like to implement this for libjvm first and > then take care of the other libraries in a separate patch. > > Thanks, > Erik > >> Dan >> >> >> On 2/12/14 8:03 AM, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes how old debug information copied from IMPORT_JDK is >>> treated. >>> >>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>> entire IMPORT_JDK folder, including additional files (such as unzipped >>> debug information). The export_*_jdk targets will then, via the >>> generic_export target, copy the build artifacts via implicit rules to >>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>> >>> The bug arises when IMPORT_JDK contains unzipped debug info >>> (libjvm.debuginfo) and the make target produces zipped debug info >>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>> will match libjvm.so. >>> >>> Finally, the JPRT make targets jprt_build_* just zips >>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>> having different zipped and unzipped debug info, since the IMPORT_JDK >>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. >>> >>> This patch removes the debug info that we did *not* build. If we build >>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be >>> removed (if it exists). >>> >>> Patch: >>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>> >>> Testing: >>> - Building in JPRT >>> - Building Linux 32-bit locally on a Linux 64-bit machine >>> - Building Linux 64-bit locally on a Linux 64-bit machine >>> >>> For all of the above, verify that only the correct debug info is >>> present in the output. >>> >>> Thanks, >>> Erik >> From serguei.spitsyn at oracle.com Thu Feb 13 16:01:07 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 13 Feb 2014 16:01:07 -0800 Subject: RFR (S) 8034249: need more workarounds for suspend equivalent condition issue Message-ID: <52FD5CC3.4090502@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8034249 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1 Summary: This issue was identified in the review of the 8032223 and it is similar to the 8032223 but impacts different JVMTI functions: GetCurrentContendedMonitor, GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetStackTrace There is a general issue in the suspend equivalent condition mechanism: Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may return different results: - 1-st: true - 2-nd: false This suspend equivalent issue is covered by another bug: https://bugs.openjdk.java.net/browse/JDK-6280037 This fix is to work around the 6280037. It is more safe to collect the necesary information at a safepoint instead of relying on the suspension of the target thread. Testing: In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi Thanks, Serguei From gnu.andrew at redhat.com Thu Feb 13 20:47:02 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 13 Feb 2014 23:47:02 -0500 (EST) Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52F48CEF.4000806@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> Message-ID: <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> ----- Original Message ----- > To expand on a solution for this ... > > Note that in vm.make and gcc.make the only uses of the JVM_VARIANT > variables relates to ZERO and ZEROSHARK. That is the real problem in my > view (it was natural to use them as they were very prominent). > > Looking through the build process it seems to me that in the generated > flags.make we will have: > > include zero|shark.make > include gcc.make > > And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be > used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH will > also be zero but that doesn't help with shark.) > > Aside: note that here zero or shark is the VARIANT but that isn't > exposed in the generated makefiles as the VARIANT is already implicit in > the path to which the file was generated eg > hotspot/__/product > > Similarly the generated vm.make will include flags.make before the repo > version of vm.make so it too can use TYPE to identify ZERO or SHARK. > > If I knew how to build zero/shark I'd test this out. :( > > David > ----- > This is a revised webrev using $(TYPE) in gcc.make and vm.make instead: http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ The BSD changes mirror the GNU/Linux ones, as in the 7141426 change which broke the build, but I've no means to test on that platform. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From calvin.cheung at oracle.com Thu Feb 13 22:49:31 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 13 Feb 2014 22:49:31 -0800 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing Message-ID: <52FDBC7B.9000204@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8034860 Please review this fix for fixing a regression caused by the fix for 8028785. The problem is that the env->ExpectionCheck() is being called from a vm thread and triggers the following assert in trasition_from_native(): assert(thread->thread_state() == _thread_in_native, "coming from wrong thread state"); A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION macros. Thanks to coleen.phillimore at oracle.com who suggested this fix. webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ Testing: jtreg hotspot/test/*, java/lang/invoke (on linux_x64) jtreg sun/misc (on windows_x64 and linux_x64) jprt (in progress) thanks, Calvin From alejandro.murillo at oracle.com Thu Feb 13 22:52:03 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 13 Feb 2014 23:52:03 -0700 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> Message-ID: <52FDBD13.2070307@oracle.com> On 2/13/2014 9:47 PM, Andrew Hughes wrote: > ----- Original Message ----- >> To expand on a solution for this ... >> >> Note that in vm.make and gcc.make the only uses of the JVM_VARIANT >> variables relates to ZERO and ZEROSHARK. That is the real problem in my >> view (it was natural to use them as they were very prominent). >> >> Looking through the build process it seems to me that in the generated >> flags.make we will have: >> >> include zero|shark.make >> include gcc.make >> >> And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be >> used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH will >> also be zero but that doesn't help with shark.) >> >> Aside: note that here zero or shark is the VARIANT but that isn't >> exposed in the generated makefiles as the VARIANT is already implicit in >> the path to which the file was generated eg >> hotspot/__/product >> >> Similarly the generated vm.make will include flags.make before the repo >> version of vm.make so it too can use TYPE to identify ZERO or SHARK. >> >> If I knew how to build zero/shark I'd test this out. :( >> >> David >> ----- >> > This is a revised webrev using $(TYPE) in gcc.make and vm.make instead: > > http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ > > The BSD changes mirror the GNU/Linux ones, as in the 7141426 change > which broke the build, but I've no means to test on that platform. I'll submit a couple of jprt jobs with these changes thanks -- Alejandro From david.holmes at oracle.com Thu Feb 13 23:11:23 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Feb 2014 17:11:23 +1000 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52FDBD13.2070307@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> <52FDBD13.2070307@oracle.com> Message-ID: <52FDC19B.2080004@oracle.com> On 14/02/2014 4:52 PM, Alejandro E Murillo wrote: > > On 2/13/2014 9:47 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> To expand on a solution for this ... >>> >>> Note that in vm.make and gcc.make the only uses of the JVM_VARIANT >>> variables relates to ZERO and ZEROSHARK. That is the real problem in my >>> view (it was natural to use them as they were very prominent). >>> >>> Looking through the build process it seems to me that in the generated >>> flags.make we will have: >>> >>> include zero|shark.make >>> include gcc.make >>> >>> And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be >>> used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH will >>> also be zero but that doesn't help with shark.) >>> >>> Aside: note that here zero or shark is the VARIANT but that isn't >>> exposed in the generated makefiles as the VARIANT is already implicit in >>> the path to which the file was generated eg >>> hotspot/__/product >>> >>> Similarly the generated vm.make will include flags.make before the repo >>> version of vm.make so it too can use TYPE to identify ZERO or SHARK. >>> >>> If I knew how to build zero/shark I'd test this out. :( >>> >>> David >>> ----- >>> >> This is a revised webrev using $(TYPE) in gcc.make and vm.make instead: >> >> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ >> >> The BSD changes mirror the GNU/Linux ones, as in the 7141426 change >> which broke the build, but I've no means to test on that platform. > I'll submit a couple of jprt jobs with these changes I read that as meaning Andrew couldn't do a zero BSD build. Andrew: thanks for doing this. The functional changes to the build files etc look fine to me. However I don't know about the additional copyrights that were added. I can't see anything in the OpenJDK rules/charter/legal, or the OCA, that addresses this. Thanks, David > thanks > From david.holmes at oracle.com Thu Feb 13 23:15:09 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Feb 2014 17:15:09 +1000 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FDBC7B.9000204@oracle.com> References: <52FDBC7B.9000204@oracle.com> Message-ID: <52FDC27D.10404@oracle.com> Hi Calvin, On 14/02/2014 4:49 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8034860 > > Please review this fix for fixing a regression caused by the fix for > 8028785. > > The problem is that the env->ExpectionCheck() is being called from a vm > thread > and triggers the following assert in trasition_from_native(): > > assert(thread->thread_state() == _thread_in_native, "coming from > wrong thread state"); > > A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION > macros. This seems a reasonable solution. Thanks, David > Thanks to coleen.phillimore at oracle.com who suggested this fix. > > webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ > > Testing: > jtreg hotspot/test/*, java/lang/invoke (on linux_x64) > jtreg sun/misc (on windows_x64 and linux_x64) > jprt (in progress) > > thanks, > Calvin From goetz.lindenmaier at sap.com Thu Feb 13 23:24:33 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 14 Feb 2014 07:24:33 +0000 Subject: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. In-Reply-To: <52FD3B82.5020806@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA151C@DEWDFEMB12A.global.corp.sap> <52FD3B82.5020806@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA225B@DEWDFEMB12A.global.corp.sap> Hi Jon, Thanks for your review! Best regards, Goetz. -----Original Message----- From: Jon Masamitsu [mailto:jon.masamitsu at oracle.com] Sent: Donnerstag, 13. Februar 2014 22:39 To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'hotspot-runtime-dev at openjdk.java.net'; 'Mikael Gerdin (mikael.gerdin at oracle.com)' Cc: Baesken, Matthias Subject: Re: RFR(M): 8034171: Remove use of template template parameters from binaryTreeDictionary. This is a very nice change. Thanks. Looks good. Jon On 02/11/2014 01:02 AM, Lindenmaier, Goetz wrote: > Hi, > > The template template parameters in the binaryTreeDictionary are not > needed to express its functionality. This change replaces them by simple > class templates and explicit instantiation. This simplifies consumption of > the openJDK in scenarios requiring older C++ compilers. > > This change also removes dead get_chunk() from binaryTreeDictionary.cpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8034171 > webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8034171-1-templ/ > > Please review and test this change. Unfortunately I don't have access > to JPRT, so I need a sponsor. > > > I compiled this change on linuxx86_64 with gcc 4.3.4 and 4.8, and on sparcv9 with SS12u1, > > on windows amd64 and on sparc. I tested dbg, fdbg and opt builds. The change ran with all our tests > > on the ppc port, including jbb2013, jvm2008 and parts of a well-known, publicly > > not available test suite without problems. > > > > I would like to downport this change to jdk8u targeting u20 later on. > > > > Could you please also check whether I filed the bug correctly? What should > > I put into "affected versions"? > > > > Thanks and best regards, > > Goetz. > > > From calvin.cheung at oracle.com Thu Feb 13 23:24:46 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 13 Feb 2014 23:24:46 -0800 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FDC27D.10404@oracle.com> References: <52FDBC7B.9000204@oracle.com> <52FDC27D.10404@oracle.com> Message-ID: <52FDC4BE.4020906@oracle.com> David, Thanks for your quick review. Calvin On 2/13/2014 11:15 PM, David Holmes wrote: > Hi Calvin, > > On 14/02/2014 4:49 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8034860 >> >> Please review this fix for fixing a regression caused by the fix for >> 8028785. >> >> The problem is that the env->ExpectionCheck() is being called from a vm >> thread >> and triggers the following assert in trasition_from_native(): >> >> assert(thread->thread_state() == _thread_in_native, "coming from >> wrong thread state"); >> >> A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION >> macros. > > This seems a reasonable solution. > > Thanks, > David > > >> Thanks to coleen.phillimore at oracle.com who suggested this fix. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ >> >> Testing: >> jtreg hotspot/test/*, java/lang/invoke (on linux_x64) >> jtreg sun/misc (on windows_x64 and linux_x64) >> jprt (in progress) >> >> thanks, >> Calvin From staffan.larsen at oracle.com Fri Feb 14 00:45:04 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 14 Feb 2014 09:45:04 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FD27D8.8060200@oracle.com> References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> <52FCFDBA.5040108@oracle.com> <52FD27D8.8060200@oracle.com> Message-ID: <28F9E62B-3A20-4BFB-AA40-9568C8BEDBC2@oracle.com> This version looks good! Thanks for hanging in there. The only improvement would be to count and verify the number of ModificationWatchpointEvent (there should be 10). Thanks, /Staffan On 13 feb 2014, at 21:15, shanliang wrote: > Hi, > > Here is Version 4: > http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/ > > 1) remove the line > 108 vm.resume() > 2) call addClassWatch(vm) only when receiving VMStartEvent > 3) make sure that the test receives ModificationWatchpointEvent > 4) clean > > Thanks, > Shanliang > > shanliang wrote: >> >> Staffan, >> >> Very nice analysis! >> >> The fix must be very simple, just remove the line >> 108 vm.resume >> it is an error because here the test does not yet treat the events in eventSet. >> >> the line >> 136 eventSet.resume(); >> is the right place to resume the threads after event treatment. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ >> >> Thanks, >> Shanliang >> >> Staffan Larsen wrote: >>> >>> I think I understand what happens now. >>> >>> The test code, simplified, looks like this (with the Thread.sleep() added that causes the test to fail): >>> >>> launchTarget(); >>> addClassWatch(); >>> vm.resume(); >>> Thread.sleep(1000); >>> while(connected) { >>> eventSet = eventQueue.remove() >>> for(event : eventQueue) { >>> if (event instanceof ClassPrepareEvent) { >>> addFieldWatch(); >>> } >>> } >>> eventSet.resume(); >>> } >>> >>> By default all events that happen will cause the debuggee to suspend (see EventRequest.setSuspendPolicy()). Thus when we get to addFieldWatch(), the vm should be suspended and we should be able to create the field watch without problem. But the VM isn?t suspended and that is why the test fail. >>> >>> Why isn?t the VM suspended? When we get to the ?for(event : eventQueue)? the first time there are *two* events already in the queue: the VMStartEvent and a ClassPrepareEvent. At this point the VM is suspended and everything is good. We look at the first eventSet which only contains the VMStartEvent, we ignore the event, but we resume the VM. We then loop and look at the ClassPrepareEvent, but by now the VM is already running and has also terminated. Failure. >>> >>> Thus, we need to handle the VMStartEvent. I suggest a modification to my previous code: >>> >>> launchTarget(); >>> while(connected) { >>> eventSet = eventQueue.remove() >>> for(event : eventQueue) { >>> if (event instanceof VMStartEvent) { >>> addClassWatch(); >>> } >>> if (event instanceof ClassPrepareEvent) { >>> addFieldWatch(); >>> } >>> } >>> eventSet.resume(); >>> } >>> >>> This will cause us to have complete control over the state of the debuggee. The first event we see will be the VMStartEvent. The VM will be suspended. We can add a class watch here. Then we resume the VM. The second event we see will be the ClassPrepareEvent with the VM suspended. We can add the field watch. Then we resume the VM and wait for the field watch events. >>> >>> Thanks, >>> /Staffan >>> >>> On 13 feb 2014, at 11:36, shanliang wrote: >>> >>>> Staffan Larsen wrote: >>>>> >>>>> On 13 feb 2014, at 10:17, Jaroslav Bachorik wrote: >>>>> >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>>>> >>>>>>> I?m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can?t quite explain what goes wrong without the fix? I?d really like to understand that. I?ll try to dig deeper and see if I can understand exactly what happens. >>>>>>> >>>>>> Yes, bringing the VM to a stable state before calling other JDI functions helps to stabilize the test even without the additional synchronization via stdout/stdin. >>>>>> >>>>>> I just wonder whether this check should not be done inside com.sun.jdi.connect.LaunchingConnector#launch() implementation. Does it even make sense to hand off an unstable VM? >>>>>> >>>>> Good question, but hard to change now - all implementations depend on the current functionality. The VMStartEvent also gives you a reference to the main thread. >>>>> >>>> The test failed when it received ClassPrepareEvent and did addFieldWatch, that meant the test must receive already VMStartEvent, because VMStartEvent must be the first event, if it was true then the vm must be already stable when failing. >>>> >>>> Except that the test received ClassPrepareEvent before VMStartEvent then it was doing addFieldWatch with a possibly unstable VM. in this case we might have a serious bug in VirtualMachine implementation, and if this is true the fix proposed to check "start" may make miss ClassPrepareEvent, then the test would test nothing. >>>> >>>> Shanliang >>>>> /S >>>>> >>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 12 feb 2014, at 18:04, shanliang wrote: >>>>>>> >>>>>>> >>>>>>>> Staffan Larsen wrote: >>>>>>>> >>>>>>>>> I think what you need to do is wait for the VMStartEvent before you add requests to the VM. Note this paragraph from the VirtualMachine doc: >>>>>>>>> >>>>>>>>> Note that a target VM launched by a launching connector is not >>>>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>>>> received. >>>>>>>>> >>>>>>>>> >>>>>>>> I may miss something here, I believe VMStartEvent must be the first event, when the test got ClassPrepareEvent, it must already received VMStartEvent. >>>>>>>> >>>>>>>>> I think adding code that looks something like this will make the test stable: >>>>>>>>> >>>>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>>>> >>>>>>>>> boolean started = false; >>>>>>>>> while(!started) { >>>>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>>>> for (Event event : eventSet) { >>>>>>>>> if (event instanceof VMStartEvent) { >>>>>>>>> started = true; >>>>>>>>> } >>>>>>>>> if (event instanceof VMDeathEvent >>>>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> System.out.println("Vm launched"); >>>>>>>>> >>>>>>>>> >>>>>>>> The code you proposed could improve the test, it made sure that TestPostFieldModification was started, but I am afraid that it did not address the issue causing the failure, the issue I believe was that TestPostFieldModification exited before or during FieldMonitor called addFieldWatch(), that was why addFieldWatch() received VMDisconnectedException. When the test was treating ClassPrepareEvent, even if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the eventQueue because it arrived after ClassPrepareEvent. >>>>>>>> >>>>>>>> My fix was to not allow TestPostFieldModification to exit before addFieldWatch() was done. >>>>>>>> >>>>>>>>> There is also no reason to call addFieldWatch() before the ClassPrepareEvent has been received. The call to vm..classesByName() will just return an empty list anyway. >>>>>>>>> >>>>>>>>> >>>>>>>> I do not know why the test called addFieldWatch before ClassPrepareEvent had been received, but yes the returned list was empty, so agree to remove it. >>>>>>>> >>>>>>>>> While you are in there you can also remove the unused StringBuffer near the top of main(). >>>>>>>>> >>>>>>>>> >>>>>>>> Yes it was already removed in version 01 >>>>>>>> >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 11 feb 2014, at 18:30, shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Here is the new fix in which FieldMonitor will write to TestPostFieldModification, to inform the latter to quit, as suggested bu Jaroslav >>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When the >>>>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>>>>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee death. The gc() invoking thread "d" is flagged as a deamon and as such doesn't prevent the process from exiting. The other thread is not a daemon but will finish in only few cycles. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of the method "resume": >>>>>>>>>>>> /** >>>>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>>>> * >>>>>>>>>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}. >>>>>>>>>>>> * >>>>>>>>>>>> * @see #suspend >>>>>>>>>>>> */ >>>>>>>>>>>> void resume(); >>>>>>>>>>>> My understanding is that the debuggee resumes to work after this call, instead to die? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> In fact the problem is here, the vm (TestPostFieldModification) should not die before FieldMonitor finishes addFieldWatch. >>>>>>>>>>> >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> It looks like some kind of synchronization between the debugger and the debuggee is necessary. But I wonder if you should better use the process.getOuptuptStream() to write and flush a message for the debugee indicating that it can exit. And in the debugee you would just do System.in.read() as the last statement in the main() method. Seems more robust than involving files. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> It could work, but creating a file in the testing directory should have no issue, but yes maybe less performance. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if that could >>>>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Staffan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> web: >>>>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Feb 14 00:57:10 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 09:57:10 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FD27D8.8060200@oracle.com> References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> <52FCFDBA.5040108@oracle.com> <52FD27D8.8060200@oracle.com> Message-ID: <52FDDA66.90608@oracle.com> Looks good! Thanks, -JB- On 13.2.2014 21:15, shanliang wrote: > Hi, > > Here is Version 4: > http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/ > > 1) remove the line > 108 vm.resume() > 2) call addClassWatch(vm) only when receiving VMStartEvent > 3) make sure that the test receives ModificationWatchpointEvent > 4) clean > > Thanks, > Shanliang > > shanliang wrote: >> Staffan, >> >> Very nice analysis! >> >> The fix must be very simple, just remove the line >> 108 vm.resume >> it is an error because here the test does not yet treat the events in >> eventSet. >> >> the line >> 136 eventSet.resume(); >> is the right place to resume the threads after event treatment. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ >> >> Thanks, >> Shanliang >> >> Staffan Larsen wrote: >>> I think I understand what happens now. >>> >>> The test code, simplified, looks like this (with the Thread.sleep() >>> added that causes the test to fail): >>> >>> launchTarget(); >>> addClassWatch(); >>> vm.resume(); >>> Thread.sleep(1000); >>> while(connected) { >>> eventSet = eventQueue.remove() >>> for(event : eventQueue) { >>> if (event instanceof ClassPrepareEvent) { >>> addFieldWatch(); >>> } >>> } >>> eventSet.resume(); >>> } >>> >>> By default all events that happen will cause the debuggee to suspend >>> (see EventRequest.setSuspendPolicy()). Thus when we get to >>> addFieldWatch(), the vm should be suspended and we should be able to >>> create the field watch without problem. But the VM isn?t suspended >>> and that is why the test fail. >>> Why isn?t the VM suspended? When we get to the ?for(event : >>> eventQueue)? the first time there are *two* events already in the >>> queue: the VMStartEvent and a ClassPrepareEvent. At this point the VM >>> is suspended and everything is good. We look at the first eventSet >>> which only contains the VMStartEvent, we ignore the event, but we >>> resume the VM. We then loop and look at the ClassPrepareEvent, but by >>> now the VM is already running and has also terminated. Failure. >>> >>> Thus, we need to handle the VMStartEvent. I suggest a modification to >>> my previous code: >>> >>> launchTarget(); >>> while(connected) { >>> eventSet = eventQueue.remove() >>> for(event : eventQueue) { >>> if (event instanceof VMStartEvent) { >>> addClassWatch(); >>> } >>> if (event instanceof ClassPrepareEvent) { >>> addFieldWatch(); >>> } >>> } >>> eventSet.resume(); >>> } >>> >>> This will cause us to have complete control over the state of the >>> debuggee. The first event we see will be the VMStartEvent. The VM >>> will be suspended. We can add a class watch here. Then we resume the >>> VM. The second event we see will be the ClassPrepareEvent with the VM >>> suspended. We can add the field watch. Then we resume the VM and wait >>> for the field watch events. >>> >>> Thanks, >>> /Staffan >>> >>> On 13 feb 2014, at 11:36, shanliang >> > wrote: >>> >>>> Staffan Larsen wrote: >>>>> On 13 feb 2014, at 10:17, Jaroslav Bachorik >>>>> wrote: >>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>>>>> I?m still not happy with this fix since I think the extra output >>>>>>> stream synchronization logic is not needed - the debuggee should >>>>>>> be suspended at all the interesting points. The fix I proposed is >>>>>>> cleaner and (as far as I can tell) also fixes the problem. The >>>>>>> only thing is that I can?t quite explain what goes wrong without >>>>>>> the fix? I?d really like to understand that. I?ll try to dig >>>>>>> deeper and see if I can understand exactly what happens. >>>>>> Yes, bringing the VM to a stable state before calling other JDI >>>>>> functions helps to stabilize the test even without the additional >>>>>> synchronization via stdout/stdin. >>>>>> >>>>>> I just wonder whether this check should not be done inside >>>>>> com.sun.jdi.connect.LaunchingConnector#launch() implementation. >>>>>> Does it even make sense to hand off an unstable VM? >>>>> Good question, but hard to change now - all implementations depend >>>>> on the current functionality. The VMStartEvent also gives you a >>>>> reference to the main thread. >>>> The test failed when it received ClassPrepareEvent and did >>>> addFieldWatch, that meant the test must receive already >>>> VMStartEvent, because VMStartEvent must be the first event, if it >>>> was true then the vm must be already stable when failing. >>>> >>>> Except that the test received ClassPrepareEvent before VMStartEvent >>>> then it was doing addFieldWatch with a possibly unstable VM. in this >>>> case we might have a serious bug in VirtualMachine implementation, >>>> and if this is true the fix proposed to check "start" may make miss >>>> ClassPrepareEvent, then the test would test nothing. >>>> >>>> Shanliang >>>>> /S >>>>> >>>>>> -JB- >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> On 12 feb 2014, at 18:04, shanliang >>>>>>> wrote: >>>>>>> >>>>>>>> Staffan Larsen wrote: >>>>>>>>> I think what you need to do is wait for the VMStartEvent before >>>>>>>>> you add requests to the VM. Note this paragraph from the >>>>>>>>> VirtualMachine doc: >>>>>>>>> >>>>>>>>> Note that a target VM launched by a launching connector is not >>>>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>>>> received. >>>>>>>>> >>>>>>>> I may miss something here, I believe VMStartEvent must be the >>>>>>>> first event, when the test got ClassPrepareEvent, it must >>>>>>>> already received VMStartEvent. >>>>>>>>> I think adding code that looks something like this will make >>>>>>>>> the test stable: >>>>>>>>> >>>>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>>>> >>>>>>>>> boolean started = false; >>>>>>>>> while(!started) { >>>>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>>>> for (Event event : eventSet) { >>>>>>>>> if (event instanceof VMStartEvent) { >>>>>>>>> started = true; >>>>>>>>> } >>>>>>>>> if (event instanceof VMDeathEvent >>>>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> System.out.println("Vm launched"); >>>>>>>>> >>>>>>>> The code you proposed could improve the test, it made sure that >>>>>>>> TestPostFieldModification was started, but I am afraid that it >>>>>>>> did not address the issue causing the failure, the issue I >>>>>>>> believe was that TestPostFieldModification exited before or >>>>>>>> during FieldMonitor called addFieldWatch(), that was why >>>>>>>> addFieldWatch() received VMDisconnectedException. When the test >>>>>>>> was treating ClassPrepareEvent, even if VMDeathEvent or >>>>>>>> VMDisconnectEvent arrived, it must be still waiting in the >>>>>>>> eventQueue because it arrived after ClassPrepareEvent. >>>>>>>> >>>>>>>> My fix was to not allow TestPostFieldModification to exit before >>>>>>>> addFieldWatch() was done. >>>>>>>>> There is also no reason to call addFieldWatch() before the >>>>>>>>> ClassPrepareEvent has been received. The call to >>>>>>>>> vm..classesByName() will just return an empty list anyway. >>>>>>>>> >>>>>>>> I do not know why the test called addFieldWatch before >>>>>>>> ClassPrepareEvent had been received, but yes the returned list >>>>>>>> was empty, so agree to remove it. >>>>>>>>> While you are in there you can also remove the unused >>>>>>>>> StringBuffer near the top of main(). >>>>>>>>> >>>>>>>> Yes it was already removed in version 01 >>>>>>>> >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Shanliang >>>>>>>>> Thanks, >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 11 feb 2014, at 18:30, shanliang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Here is the new fix in which FieldMonitor will write to >>>>>>>>>> TestPostFieldModification, to inform the latter to quit, as >>>>>>>>>> suggested bu Jaroslav >>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>> shanliang wrote: >>>>>>>>>> >>>>>>>>>>> shanliang wrote: >>>>>>>>>>> >>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be >>>>>>>>>>>>>>> suspended. So when >>>>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have >>>>>>>>>>>>>>> moved. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I am not expert of jdi so I may miss something here. I >>>>>>>>>>>>>> checked the >>>>>>>>>>>>>> failure trace and saw the report exception happen when >>>>>>>>>>>>>> FieldMonitor >>>>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. >>>>>>>>>>>>>> FieldMonitor did >>>>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>>>> >>>>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate >>>>>>>>>>>>> debuggee death. The gc() invoking thread "d" is flagged as >>>>>>>>>>>>> a deamon and as such doesn't prevent the process from >>>>>>>>>>>>> exiting. The other thread is not a daemon but will finish >>>>>>>>>>>>> in only few cycles. >>>>>>>>>>>>> >>>>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is >>>>>>>>>>>> the Javadoc of the method "resume": >>>>>>>>>>>> /** >>>>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>>>> * >>>>>>>>>>>> * @throws VMCannotBeModifiedException if the >>>>>>>>>>>> VirtualMachine is read-only - see {@link >>>>>>>>>>>> VirtualMachine#canBeModified()}. >>>>>>>>>>>> * >>>>>>>>>>>> * @see #suspend >>>>>>>>>>>> */ >>>>>>>>>>>> void resume(); >>>>>>>>>>>> My understanding is that the debuggee resumes to work after >>>>>>>>>>>> this call, instead to die? >>>>>>>>>>>> >>>>>>>>>>> In fact the problem is here, the vm >>>>>>>>>>> (TestPostFieldModification) should not die before >>>>>>>>>>> FieldMonitor finishes addFieldWatch. >>>>>>>>>>> >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() >>>>>>>>>>>>>> but before >>>>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>>>> >>>>>>>>>>>>> It looks like some kind of synchronization between the >>>>>>>>>>>>> debugger and the debuggee is necessary. But I wonder if you >>>>>>>>>>>>> should better use the process.getOuptuptStream() to write >>>>>>>>>>>>> and flush a message for the debugee indicating that it can >>>>>>>>>>>>> exit. And in the debugee you would just do System.in.read() >>>>>>>>>>>>> as the last statement in the main() method. Seems more >>>>>>>>>>>>> robust than involving files. >>>>>>>>>>>>> >>>>>>>>>>>> It could work, but creating a file in the testing directory >>>>>>>>>>>> should have no issue, but yes maybe less performance. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> -JB- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>> >>>>>>>>>>>>>>> One problem I do see with the test is that it does not >>>>>>>>>>>>>>> wait for a >>>>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if >>>>>>>>>>>>>>> that could >>>>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Staffan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The problem could be that FieldMonitor did not have >>>>>>>>>>>>>>>> enough time to >>>>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor >>>>>>>>>>>>>>>> (TestPostFieldModification) was >>>>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So we should make sure that TestPostFieldModification >>>>>>>>>>>>>>>> exits after >>>>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed >>>>>>>>>>>>>>>> here is that >>>>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> TestPostFieldModification quits only after finding the >>>>>>>>>>>>>>>> file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> web: >>>>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>>> >>>> >>>> >>> >> > From shanliang.jiang at oracle.com Fri Feb 14 02:00:02 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 14 Feb 2014 11:00:02 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <28F9E62B-3A20-4BFB-AA40-9568C8BEDBC2@oracle.com> References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> <52FCFDBA.5040108@oracle.com> <52FD27D8.8060200@oracle.com> <28F9E62B-3A20-4BFB-AA40-9568C8BEDBC2@oracle.com> Message-ID: <52FDE922.3040301@oracle.com> Staffan Larsen wrote: > This version looks good! Thanks for hanging in there. > > The only improvement would be to count and verify the number of > ModificationWatchpointEvent (there should be 10). Good idea, here is: http://cr.openjdk.java.net/~sjiang/JDK-8007710/05/ Thanks, Shanliang > > Thanks, > /Staffan > > On 13 feb 2014, at 21:15, shanliang > wrote: > >> Hi, >> >> Here is Version 4: >> http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/ >> >> 1) remove the line >> 108 vm.resume() >> 2) call addClassWatch(vm) only when receiving VMStartEvent >> 3) make sure that the test receives ModificationWatchpointEvent >> 4) clean >> >> Thanks, >> Shanliang >> >> shanliang wrote: >>> Staffan, >>> >>> Very nice analysis! >>> >>> The fix must be very simple, just remove the line >>> 108 vm.resume >>> it is an error because here the test does not yet treat the events >>> in eventSet. >>> >>> the line >>> 136 eventSet.resume(); >>> is the right place to resume the threads after event treatment. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ >>> >>> Thanks, >>> Shanliang >>> >>> Staffan Larsen wrote: >>>> I think I understand what happens now. >>>> >>>> The test code, simplified, looks like this (with the Thread.sleep() >>>> added that causes the test to fail): >>>> >>>> launchTarget(); >>>> addClassWatch(); >>>> vm.resume(); >>>> Thread.sleep(1000); >>>> while(connected) { >>>> eventSet = eventQueue.remove() >>>> for(event : eventQueue) { >>>> if (event instanceof ClassPrepareEvent) { >>>> addFieldWatch(); >>>> } >>>> } >>>> eventSet.resume(); >>>> } >>>> >>>> By default all events that happen will cause the debuggee to >>>> suspend (see EventRequest.setSuspendPolicy()). Thus when we get to >>>> addFieldWatch(), the vm should be suspended and we should be able >>>> to create the field watch without problem. But the VM isn?t >>>> suspended and that is why the test fail. >>>> >>>> Why isn?t the VM suspended? When we get to the ?for(event : >>>> eventQueue)? the first time there are *two* events already in the >>>> queue: the VMStartEvent and a ClassPrepareEvent. At this point the >>>> VM is suspended and everything is good. We look at the first >>>> eventSet which only contains the VMStartEvent, we ignore the event, >>>> but we resume the VM. We then loop and look at the >>>> ClassPrepareEvent, but by now the VM is already running and has >>>> also terminated. Failure. >>>> >>>> Thus, we need to handle the VMStartEvent. I suggest a modification >>>> to my previous code: >>>> >>>> launchTarget(); >>>> while(connected) { >>>> eventSet = eventQueue.remove() >>>> for(event : eventQueue) { >>>> if (event instanceof VMStartEvent) { >>>> addClassWatch(); >>>> } >>>> if (event instanceof ClassPrepareEvent) { >>>> addFieldWatch(); >>>> } >>>> } >>>> eventSet.resume(); >>>> } >>>> >>>> This will cause us to have complete control over the state of the >>>> debuggee. The first event we see will be the VMStartEvent. The VM >>>> will be suspended. We can add a class watch here. Then we resume >>>> the VM. The second event we see will be the ClassPrepareEvent with >>>> the VM suspended. We can add the field watch. Then we resume the VM >>>> and wait for the field watch events. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> On 13 feb 2014, at 11:36, shanliang >>> > wrote: >>>> >>>>> Staffan Larsen wrote: >>>>>> On 13 feb 2014, at 10:17, Jaroslav Bachorik wrote: >>>>>> >>>>>> >>>>>>> Hi Staffan, >>>>>>> >>>>>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>>>>> >>>>>>>> I?m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can?t quite explain what goes wrong without the fix? I?d really like to understand that. I?ll try to dig deeper and see if I can understand exactly what happens. >>>>>>>> >>>>>>> Yes, bringing the VM to a stable state before calling other JDI functions helps to stabilize the test even without the additional synchronization via stdout/stdin. >>>>>>> >>>>>>> I just wonder whether this check should not be done inside com.sun.jdi.connect.LaunchingConnector#launch() implementation. Does it even make sense to hand off an unstable VM? >>>>>>> >>>>>> Good question, but hard to change now - all implementations depend on the current functionality. The VMStartEvent also gives you a reference to the main thread. >>>>>> >>>>> The test failed when it received ClassPrepareEvent and did >>>>> addFieldWatch, that meant the test must receive already >>>>> VMStartEvent, because VMStartEvent must be the first event, if it >>>>> was true then the vm must be already stable when failing. >>>>> >>>>> Except that the test received ClassPrepareEvent before >>>>> VMStartEvent then it was doing addFieldWatch with a possibly >>>>> unstable VM. in this case we might have a serious bug in >>>>> VirtualMachine implementation, and if this is true the fix >>>>> proposed to check "start" may make miss ClassPrepareEvent, then >>>>> the test would test nothing. >>>>> >>>>> Shanliang >>>>>> /S >>>>>> >>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 12 feb 2014, at 18:04, shanliang wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Staffan Larsen wrote: >>>>>>>>> >>>>>>>>>> I think what you need to do is wait for the VMStartEvent before you add requests to the VM. Note this paragraph from the VirtualMachine doc: >>>>>>>>>> >>>>>>>>>> Note that a target VM launched by a launching connector is not >>>>>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>>>>> received. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I may miss something here, I believe VMStartEvent must be the first event, when the test got ClassPrepareEvent, it must already received VMStartEvent. >>>>>>>>> >>>>>>>>>> I think adding code that looks something like this will make the test stable: >>>>>>>>>> >>>>>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>>>>> >>>>>>>>>> boolean started = false; >>>>>>>>>> while(!started) { >>>>>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>>>>> for (Event event : eventSet) { >>>>>>>>>> if (event instanceof VMStartEvent) { >>>>>>>>>> started = true; >>>>>>>>>> } >>>>>>>>>> if (event instanceof VMDeathEvent >>>>>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> System.out.println("Vm launched"); >>>>>>>>>> >>>>>>>>>> >>>>>>>>> The code you proposed could improve the test, it made sure that TestPostFieldModification was started, but I am afraid that it did not address the issue causing the failure, the issue I believe was that TestPostFieldModification exited before or during FieldMonitor called addFieldWatch(), that was why addFieldWatch() received VMDisconnectedException. When the test was treating ClassPrepareEvent, even if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the eventQueue because it arrived after ClassPrepareEvent. >>>>>>>>> >>>>>>>>> My fix was to not allow TestPostFieldModification to exit before addFieldWatch() was done. >>>>>>>>> >>>>>>>>>> There is also no reason to call addFieldWatch() before the ClassPrepareEvent has been received. The call to vm..classesByName() will just return an empty list anyway. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I do not know why the test called addFieldWatch before ClassPrepareEvent had been received, but yes the returned list was empty, so agree to remove it. >>>>>>>>> >>>>>>>>>> While you are in there you can also remove the unused StringBuffer near the top of main(). >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Yes it was already removed in version 01 >>>>>>>>> >>>>>>>>> Here is the new webrev: >>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>> On 11 feb 2014, at 18:30, shanliang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Here is the new fix in which FieldMonitor will write to TestPostFieldModification, to inform the latter to quit, as suggested bu Jaroslav >>>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Shanliang >>>>>>>>>>> >>>>>>>>>>> shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> shanliang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When the >>>>>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>>>>>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee death. The gc() invoking thread "d" is flagged as a deamon and as such doesn't prevent the process from exiting. The other thread is not a daemon but will finish in only few cycles. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of the method "resume": >>>>>>>>>>>>> /** >>>>>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>>>>> * >>>>>>>>>>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}. >>>>>>>>>>>>> * >>>>>>>>>>>>> * @see #suspend >>>>>>>>>>>>> */ >>>>>>>>>>>>> void resume(); >>>>>>>>>>>>> My understanding is that the debuggee resumes to work after this call, instead to die? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> In fact the problem is here, the vm (TestPostFieldModification) should not die before FieldMonitor finishes addFieldWatch. >>>>>>>>>>>> >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> It looks like some kind of synchronization between the debugger and the debuggee is necessary. But I wonder if you should better use the process.getOuptuptStream() to write and flush a message for the debugee indicating that it can exit. And in the debugee you would just do System.in.read() as the last statement in the main() method. Seems more robust than involving files. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> It could work, but creating a file in the testing directory should have no issue, but yes maybe less performance. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Shanliang >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if that could >>>>>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Staffan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>>>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> web: >>>>>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From staffan.larsen at oracle.com Fri Feb 14 03:16:10 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 14 Feb 2014 12:16:10 +0100 Subject: Codereview request: 8007710 runtime/7158988/FieldMonitor.java fails with com.sun.jdi.VMDisconnectedException: Connection closed In-Reply-To: <52FDE922.3040301@oracle.com> References: <52FA301A.2040301@oracle.com> <52FA424E.2050202@oracle.com> <52FA4515.3050904@oracle.com> <52FA4D33.4030402@oracle.com> <52FA51BE.4070701@oracle.com> <52FA5E51.3040704@oracle.com> <3F301491-8A27-4319-A694-D1E8ACB2F249@oracle.com> <52FBA9B2.6090502@oracle.com> <52FC8DA1.9090900@oracle.com> <1353E47D-3ACB-42FD-ABD3-845CEB6EE389@oracle.com> <52FCA014.9000106@oracle.com> <52FCFDBA.5040108@oracle.com> <52FD27D8.8060200@oracle.com> <28F9E62B-3A20-4BFB-AA40-9568C8BEDBC2@oracle.com> <52FDE922.3040301@oracle.com> Message-ID: Good. Just a small spelling error ?Espected? -> ?Expected?. /Staffan On 14 feb 2014, at 11:00, shanliang wrote: > Staffan Larsen wrote: >> >> This version looks good! Thanks for hanging in there. >> >> The only improvement would be to count and verify the number of ModificationWatchpointEvent (there should be 10). > Good idea, here is: > http://cr.openjdk.java.net/~sjiang/JDK-8007710/05/ > > Thanks, > Shanliang >> >> Thanks, >> /Staffan >> >> On 13 feb 2014, at 21:15, shanliang wrote: >> >>> Hi, >>> >>> Here is Version 4: >>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/04/ >>> >>> 1) remove the line >>> 108 vm.resume() >>> 2) call addClassWatch(vm) only when receiving VMStartEvent >>> 3) make sure that the test receives ModificationWatchpointEvent >>> 4) clean >>> >>> Thanks, >>> Shanliang >>> >>> shanliang wrote: >>>> >>>> Staffan, >>>> >>>> Very nice analysis! >>>> >>>> The fix must be very simple, just remove the line >>>> 108 vm.resume >>>> it is an error because here the test does not yet treat the events in eventSet. >>>> >>>> the line >>>> 136 eventSet.resume(); >>>> is the right place to resume the threads after event treatment. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/03/ >>>> >>>> Thanks, >>>> Shanliang >>>> >>>> Staffan Larsen wrote: >>>>> >>>>> I think I understand what happens now. >>>>> >>>>> The test code, simplified, looks like this (with the Thread.sleep() added that causes the test to fail): >>>>> >>>>> launchTarget(); >>>>> addClassWatch(); >>>>> vm.resume(); >>>>> Thread.sleep(1000); >>>>> while(connected) { >>>>> eventSet = eventQueue.remove() >>>>> for(event : eventQueue) { >>>>> if (event instanceof ClassPrepareEvent) { >>>>> addFieldWatch(); >>>>> } >>>>> } >>>>> eventSet.resume(); >>>>> } >>>>> >>>>> By default all events that happen will cause the debuggee to suspend (see EventRequest.setSuspendPolicy()). Thus when we get to addFieldWatch(), the vm should be suspended and we should be able to create the field watch without problem. But the VM isn?t suspended and that is why the test fail. >>>>> >>>>> Why isn?t the VM suspended? When we get to the ?for(event : eventQueue)? the first time there are *two* events already in the queue: the VMStartEvent and a ClassPrepareEvent. At this point the VM is suspended and everything is good. We look at the first eventSet which only contains the VMStartEvent, we ignore the event, but we resume the VM. We then loop and look at the ClassPrepareEvent, but by now the VM is already running and has also terminated. Failure. >>>>> >>>>> Thus, we need to handle the VMStartEvent. I suggest a modification to my previous code: >>>>> >>>>> launchTarget(); >>>>> while(connected) { >>>>> eventSet = eventQueue.remove() >>>>> for(event : eventQueue) { >>>>> if (event instanceof VMStartEvent) { >>>>> addClassWatch(); >>>>> } >>>>> if (event instanceof ClassPrepareEvent) { >>>>> addFieldWatch(); >>>>> } >>>>> } >>>>> eventSet.resume(); >>>>> } >>>>> >>>>> This will cause us to have complete control over the state of the debuggee. The first event we see will be the VMStartEvent. The VM will be suspended. We can add a class watch here. Then we resume the VM. The second event we see will be the ClassPrepareEvent with the VM suspended. We can add the field watch. Then we resume the VM and wait for the field watch events. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> On 13 feb 2014, at 11:36, shanliang wrote: >>>>> >>>>>> Staffan Larsen wrote: >>>>>>> >>>>>>> On 13 feb 2014, at 10:17, Jaroslav Bachorik wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Staffan, >>>>>>>> >>>>>>>> On 12.2.2014 18:27, Staffan Larsen wrote: >>>>>>>> >>>>>>>>> I?m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can?t quite explain what goes wrong without the fix? I?d really like to understand that. I?ll try to dig deeper and see if I can understand exactly what happens. >>>>>>>>> >>>>>>>> Yes, bringing the VM to a stable state before calling other JDI functions helps to stabilize the test even without the additional synchronization via stdout/stdin. >>>>>>>> >>>>>>>> I just wonder whether this check should not be done inside com.sun.jdi.connect.LaunchingConnector#launch() implementation. Does it even make sense to hand off an unstable VM? >>>>>>>> >>>>>>> Good question, but hard to change now - all implementations depend on the current functionality. The VMStartEvent also gives you a reference to the main thread. >>>>>>> >>>>>> The test failed when it received ClassPrepareEvent and did addFieldWatch, that meant the test must receive already VMStartEvent, because VMStartEvent must be the first event, if it was true then the vm must be already stable when failing. >>>>>> >>>>>> Except that the test received ClassPrepareEvent before VMStartEvent then it was doing addFieldWatch with a possibly unstable VM. in this case we might have a serious bug in VirtualMachine implementation, and if this is true the fix proposed to check "start" may make miss ClassPrepareEvent, then the test would test nothing. >>>>>> >>>>>> Shanliang >>>>>>> /S >>>>>>> >>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>> On 12 feb 2014, at 18:04, shanliang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>> >>>>>>>>>>> I think what you need to do is wait for the VMStartEvent before you add requests to the VM. Note this paragraph from the VirtualMachine doc: >>>>>>>>>>> >>>>>>>>>>> Note that a target VM launched by a launching connector is not >>>>>>>>>>> guaranteed to be stable until after the VMStartEvent has been >>>>>>>>>>> received. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I may miss something here, I believe VMStartEvent must be the first event, when the test got ClassPrepareEvent, it must already received VMStartEvent. >>>>>>>>>> >>>>>>>>>>> I think adding code that looks something like this will make the test stable: >>>>>>>>>>> >>>>>>>>>>> VirtualMachine vm = launchTarget(CLASS_NAME); >>>>>>>>>>> EventQueue eventQueue = vm.eventQueue(); >>>>>>>>>>> >>>>>>>>>>> boolean started = false; >>>>>>>>>>> while(!started) { >>>>>>>>>>> EventSet eventSet = eventQueue.remove(); >>>>>>>>>>> for (Event event : eventSet) { >>>>>>>>>>> if (event instanceof VMStartEvent) { >>>>>>>>>>> started = true; >>>>>>>>>>> } >>>>>>>>>>> if (event instanceof VMDeathEvent >>>>>>>>>>> || event instanceof VMDisconnectEvent) { >>>>>>>>>>> throw new Error("VM died before it started...:"+event); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> System.out.println("Vm launched"); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> The code you proposed could improve the test, it made sure that TestPostFieldModification was started, but I am afraid that it did not address the issue causing the failure, the issue I believe was that TestPostFieldModification exited before or during FieldMonitor called addFieldWatch(), that was why addFieldWatch() received VMDisconnectedException. When the test was treating ClassPrepareEvent, even if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the eventQueue because it arrived after ClassPrepareEvent. >>>>>>>>>> >>>>>>>>>> My fix was to not allow TestPostFieldModification to exit before addFieldWatch() was done. >>>>>>>>>> >>>>>>>>>>> There is also no reason to call addFieldWatch() before the ClassPrepareEvent has been received. The call to vm..classesByName() will just return an empty list anyway. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I do not know why the test called addFieldWatch before ClassPrepareEvent had been received, but yes the returned list was empty, so agree to remove it. >>>>>>>>>> >>>>>>>>>>> While you are in there you can also remove the unused StringBuffer near the top of main(). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yes it was already removed in version 01 >>>>>>>>>> >>>>>>>>>> Here is the new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shanliang >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> /Staffan >>>>>>>>>>> >>>>>>>>>>> On 11 feb 2014, at 18:30, shanliang wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Here is the new fix in which FieldMonitor will write to TestPostFieldModification, to inform the latter to quit, as suggested bu Jaroslav >>>>>>>>>>>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Shanliang >>>>>>>>>>>> >>>>>>>>>>>> shanliang wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> shanliang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Jaroslav Bachorik wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Staffan Larsen wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Shanliang, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I can?t quite see how the test can fail in this way. When the >>>>>>>>>>>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>>>>>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>>>>>>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>>>>>>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>>>>>>>>>>> call "vm.resume()" before treating events. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee death. The gc() invoking thread "d" is flagged as a deamon and as such doesn't prevent the process from exiting. The other thread is not a daemon but will finish in only few cycles. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of the method "resume": >>>>>>>>>>>>>> /** >>>>>>>>>>>>>> * Continues the execution of the application running in this >>>>>>>>>>>>>> * virtual machine. All threads are resumed as documented in >>>>>>>>>>>>>> * {@link ThreadReference#resume}. >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is read-only - see {@link VirtualMachine#canBeModified()}. >>>>>>>>>>>>>> * >>>>>>>>>>>>>> * @see #suspend >>>>>>>>>>>>>> */ >>>>>>>>>>>>>> void resume(); >>>>>>>>>>>>>> My understanding is that the debuggee resumes to work after this call, instead to die? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> In fact the problem is here, the vm (TestPostFieldModification) should not die before FieldMonitor finishes addFieldWatch. >>>>>>>>>>>>> >>>>>>>>>>>>> Shanliang >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>>>>>>>>>>> calling eventQueue.remove(); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It looks like some kind of synchronization between the debugger and the debuggee is necessary. But I wonder if you should better use the process.getOuptuptStream() to write and flush a message for the debugee indicating that it can exit. And in the debugee you would just do System.in.read() as the last statement in the main() method. Seems more robust than involving files. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> It could work, but creating a file in the testing directory should have no issue, but yes maybe less performance. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -JB- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>>>>>>>>>>> VMStartEvent before setting up requests. I?m not sure if that could >>>>>>>>>>>>>>>>> cause the failure in the bug report, though. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Staffan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11 feb 2014, at 15:13, shanliang wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi , >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>>>>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>>>>>>>>>>> already ended. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>>>>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>>>>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>>>>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> web: >>>>>>>>>>>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Shanliang >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Fri Feb 14 04:51:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Feb 2014 12:51:54 +0000 Subject: hg: hsx/jdk7u/hotspot: 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Message-ID: <20140214125158.E85B562C6A@hg.openjdk.java.net> Changeset: b1d29549dca7 Author: sspitsyn Date: 2014-02-14 01:52 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b1d29549dca7 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Summary: Restore the appendix argument after PopFrame() call Reviewed-by: twisti, coleenp Contributed-by: serguei.spitsyn at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/oops/constantPoolOop.cpp From erik.helin at oracle.com Fri Feb 14 05:21:35 2014 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 14 Feb 2014 14:21:35 +0100 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FD5571.4010104@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> <52FD5571.4010104@oracle.com> Message-ID: <52FE185F.4070605@oracle.com> Dan, On 2014-02-14 00:29, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ > > make/Makefile > > + ifeq ($(OSNAME), bsd) > + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM > > The above needs to be: > > ifeq ($(OS_VENDOR), Darwin) > $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM > > I don't think that BSD uses .dylib stuff; that's MacOS X specific. You are right, thanks for the correction. Please see new webrev at: http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ Again, same testing as for prior patches were run. Thanks, Erik > Dan > > > On 2/13/14 1:59 PM, Erik Helin wrote: >> Hi Dan, >> >> thanks for reviewing! See my replies inline. >> >> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>> >>> make/Makefile >>> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >>> 278 ifeq ($(OSNAME), windows) >>> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >>> $(EXPORT_SERVER_DIR)/jvm.pdb >>> 280 else >>> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >>> 282 endif >>> >>> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >>> you'll need a MacOS X specific rule. You don't need an >>> update for the JVM_VARIANT_CLIENT version because MacOS X >>> doesn't support the Client VM, but if it did... >> >> Thanks for catching this! I've uploaded a new webrev at: >> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >> >> The same testing was done as for the first patch. >> >> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>> So the above change handles libjvm, but what about the >>> other libraries exported by HotSpot? libjsig, libjvm_db, >>> and libjvm_dtrace come to mind... >> >> As we discussed, I would like to implement this for libjvm first and >> then take care of the other libraries in a separate patch. >> >> Thanks, >> Erik >> >>> Dan >>> >>> >>> On 2/12/14 8:03 AM, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch changes how old debug information copied from IMPORT_JDK is >>>> treated. >>>> >>>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>>> entire IMPORT_JDK folder, including additional files (such as unzipped >>>> debug information). The export_*_jdk targets will then, via the >>>> generic_export target, copy the build artifacts via implicit rules to >>>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>>> >>>> The bug arises when IMPORT_JDK contains unzipped debug info >>>> (libjvm.debuginfo) and the make target produces zipped debug info >>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>>> will match libjvm.so. >>>> >>>> Finally, the JPRT make targets jprt_build_* just zips >>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>>> having different zipped and unzipped debug info, since the IMPORT_JDK >>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. >>>> >>>> This patch removes the debug info that we did *not* build. If we build >>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz will be >>>> removed (if it exists). >>>> >>>> Patch: >>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>>> >>>> Testing: >>>> - Building in JPRT >>>> - Building Linux 32-bit locally on a Linux 64-bit machine >>>> - Building Linux 64-bit locally on a Linux 64-bit machine >>>> >>>> For all of the above, verify that only the correct debug info is >>>> present in the output. >>>> >>>> Thanks, >>>> Erik >>> > From stefan.johansson at oracle.com Fri Feb 14 05:47:30 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 14 Feb 2014 14:47:30 +0100 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation Message-ID: <52FE1E72.3000809@oracle.com> Hi, Please review this change to fix: https://bugs.openjdk.java.net/browse/JDK-8033440 Webrev: http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ Summary: The compactibleFreeListSpace has been updated to use an AdaptiveFreeList instead of a FreeList. This change has not been done for the SA and it leads to using a too small element size when walking through the list. When fixing this I realized that FreeList and some other type declarations associated with it weren't used by the SA, so I went ahead and removed them. I (or Eclipse) also changed the Java *-imports to be specific ones. Testing: * JPRT for build and sanity. * UTE run for tests listed in bug. * Aurora run for tmtools.testlist. Thanks, Stefan From coleen.phillimore at oracle.com Fri Feb 14 06:13:21 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Feb 2014 09:13:21 -0500 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE1E72.3000809@oracle.com> References: <52FE1E72.3000809@oracle.com> Message-ID: <52FE2481.3070907@oracle.com> Why is this code in the SA in the first place? Did someone copy the CMS collector in there too? Coleen On 2/14/14 8:47 AM, Stefan Johansson wrote: > Hi, > > Please review this change to fix: > https://bugs.openjdk.java.net/browse/JDK-8033440 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ > > Summary: > The compactibleFreeListSpace has been updated to use an > AdaptiveFreeList instead of a FreeList. This change has not been done > for the SA and it leads to using a too small element size when walking > through the list. When fixing this I realized that FreeList > and some other type declarations associated with it weren't used by > the SA, so I went ahead and removed them. I (or Eclipse) also changed > the Java *-imports to be specific ones. > > Testing: > * JPRT for build and sanity. > * UTE run for tests listed in bug. > * Aurora run for tmtools.testlist. > > Thanks, > Stefan From coleen.phillimore at oracle.com Fri Feb 14 06:14:03 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Feb 2014 09:14:03 -0500 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FDC4BE.4020906@oracle.com> References: <52FDBC7B.9000204@oracle.com> <52FDC27D.10404@oracle.com> <52FDC4BE.4020906@oracle.com> Message-ID: <52FE24AB.5090708@oracle.com> This looks good. Thank you for the testing and verification. Coleen On 2/14/14 2:24 AM, Calvin Cheung wrote: > David, > > Thanks for your quick review. > > Calvin > > On 2/13/2014 11:15 PM, David Holmes wrote: >> Hi Calvin, >> >> On 14/02/2014 4:49 PM, Calvin Cheung wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034860 >>> >>> Please review this fix for fixing a regression caused by the fix for >>> 8028785. >>> >>> The problem is that the env->ExpectionCheck() is being called from a vm >>> thread >>> and triggers the following assert in trasition_from_native(): >>> >>> assert(thread->thread_state() == _thread_in_native, "coming from >>> wrong thread state"); >>> >>> A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION >>> macros. >> >> This seems a reasonable solution. >> >> Thanks, >> David >> >> >>> Thanks to coleen.phillimore at oracle.com who suggested this fix. >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ >>> >>> Testing: >>> jtreg hotspot/test/*, java/lang/invoke (on linux_x64) >>> jtreg sun/misc (on windows_x64 and linux_x64) >>> jprt (in progress) >>> >>> thanks, >>> Calvin > From mikael.gerdin at oracle.com Fri Feb 14 06:27:30 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 14 Feb 2014 15:27:30 +0100 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE2481.3070907@oracle.com> References: <52FE1E72.3000809@oracle.com> <52FE2481.3070907@oracle.com> Message-ID: <1811302.ToqfaB5PdD@mgerdin03> On Friday 14 February 2014 09.13.21 Coleen Phillimore wrote: > Why is this code in the SA in the first place? Did someone copy the CMS > collector in there too? To be able to calculate the amount of used and free memory in a CMS heap. (jmap -heap ) /Mikael > > Coleen > > On 2/14/14 8:47 AM, Stefan Johansson wrote: > > Hi, > > > > Please review this change to fix: > > https://bugs.openjdk.java.net/browse/JDK-8033440 > > > > Webrev: > > http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ > > > > Summary: > > The compactibleFreeListSpace has been updated to use an > > AdaptiveFreeList instead of a FreeList. This change has not been done > > for the SA and it leads to using a too small element size when walking > > through the list. When fixing this I realized that FreeList > > and some other type declarations associated with it weren't used by > > the SA, so I went ahead and removed them. I (or Eclipse) also changed > > the Java *-imports to be specific ones. > > > > Testing: > > * JPRT for build and sanity. > > * UTE run for tests listed in bug. > > * Aurora run for tmtools.testlist. > > > > Thanks, > > Stefan From coleen.phillimore at oracle.com Fri Feb 14 06:29:11 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 14 Feb 2014 09:29:11 -0500 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE1E72.3000809@oracle.com> References: <52FE1E72.3000809@oracle.com> Message-ID: <52FE2837.8070706@oracle.com> This cleanup looks good. To answer my own question (which you wrote earlier), it looks like jmap uses this code and I assume the work on SA.NEXT will address the duplication. Thanks, Coleen On 2/14/14 8:47 AM, Stefan Johansson wrote: > Hi, > > Please review this change to fix: > https://bugs.openjdk.java.net/browse/JDK-8033440 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ > > Summary: > The compactibleFreeListSpace has been updated to use an > AdaptiveFreeList instead of a FreeList. This change has not been done > for the SA and it leads to using a too small element size when walking > through the list. When fixing this I realized that FreeList > and some other type declarations associated with it weren't used by > the SA, so I went ahead and removed them. I (or Eclipse) also changed > the Java *-imports to be specific ones. > > Testing: > * JPRT for build and sanity. > * UTE run for tests listed in bug. > * Aurora run for tmtools.testlist. > > Thanks, > Stefan From daniel.daugherty at oracle.com Fri Feb 14 06:39:53 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Feb 2014 07:39:53 -0700 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FDBC7B.9000204@oracle.com> References: <52FDBC7B.9000204@oracle.com> Message-ID: <52FE2AB9.9020609@oracle.com> > webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ src/share/vm/prims/whitebox.hpp No comments. Thumbs up. Dan On 2/13/14 11:49 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8034860 > > Please review this fix for fixing a regression caused by the fix for > 8028785. > > The problem is that the env->ExpectionCheck() is being called from a > vm thread > and triggers the following assert in trasition_from_native(): > > assert(thread->thread_state() == _thread_in_native, "coming from > wrong thread state"); > > A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION > macros. > > Thanks to coleen.phillimore at oracle.com who suggested this fix. > > webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ > > Testing: > jtreg hotspot/test/*, java/lang/invoke (on linux_x64) > jtreg sun/misc (on windows_x64 and linux_x64) > jprt (in progress) > > thanks, > Calvin From stefan.johansson at oracle.com Fri Feb 14 06:45:34 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 14 Feb 2014 15:45:34 +0100 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE2837.8070706@oracle.com> References: <52FE1E72.3000809@oracle.com> <52FE2837.8070706@oracle.com> Message-ID: <52FE2C0E.8070404@oracle.com> Thanks Coleen! Yes, as you and Mikael said, the code is needed to calculate the used and free amount for the CMS generation and this is used by jmap. I guess the types I removed had been put there to prepare for some other SA feature that never came around. Cheers, Stefan On 2014-02-14 15:29, Coleen Phillimore wrote: > > This cleanup looks good. To answer my own question (which you wrote > earlier), it looks like jmap uses this code and I assume the work on > SA.NEXT will address the duplication. > > Thanks, > Coleen > > On 2/14/14 8:47 AM, Stefan Johansson wrote: >> Hi, >> >> Please review this change to fix: >> https://bugs.openjdk.java.net/browse/JDK-8033440 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ >> >> Summary: >> The compactibleFreeListSpace has been updated to use an >> AdaptiveFreeList instead of a FreeList. This change has not been done >> for the SA and it leads to using a too small element size when >> walking through the list. When fixing this I realized that >> FreeList and some other type declarations associated with >> it weren't used by the SA, so I went ahead and removed them. I (or >> Eclipse) also changed the Java *-imports to be specific ones. >> >> Testing: >> * JPRT for build and sanity. >> * UTE run for tests listed in bug. >> * Aurora run for tmtools.testlist. >> >> Thanks, >> Stefan > From dmitry.samersoff at oracle.com Fri Feb 14 07:12:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 14 Feb 2014 19:12:49 +0400 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE2C0E.8070404@oracle.com> References: <52FE1E72.3000809@oracle.com> <52FE2837.8070706@oracle.com> <52FE2C0E.8070404@oracle.com> Message-ID: <52FE3271.2060504@oracle.com> Stefan, Looks good for me. -Dmitry On 2014-02-14 18:45, Stefan Johansson wrote: > Thanks Coleen! > > Yes, as you and Mikael said, the code is needed to calculate the used > and free amount for the CMS generation and this is used by jmap. I guess > the types I removed had been put there to prepare for some other SA > feature that never came around. > > Cheers, > Stefan > > On 2014-02-14 15:29, Coleen Phillimore wrote: >> >> This cleanup looks good. To answer my own question (which you wrote >> earlier), it looks like jmap uses this code and I assume the work on >> SA.NEXT will address the duplication. >> >> Thanks, >> Coleen >> >> On 2/14/14 8:47 AM, Stefan Johansson wrote: >>> Hi, >>> >>> Please review this change to fix: >>> https://bugs.openjdk.java.net/browse/JDK-8033440 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ >>> >>> Summary: >>> The compactibleFreeListSpace has been updated to use an >>> AdaptiveFreeList instead of a FreeList. This change has not been done >>> for the SA and it leads to using a too small element size when >>> walking through the list. When fixing this I realized that >>> FreeList and some other type declarations associated with >>> it weren't used by the SA, so I went ahead and removed them. I (or >>> Eclipse) also changed the Java *-imports to be specific ones. >>> >>> Testing: >>> * JPRT for build and sanity. >>> * UTE run for tests listed in bug. >>> * Aurora run for tmtools.testlist. >>> >>> Thanks, >>> Stefan >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From stefan.johansson at oracle.com Fri Feb 14 07:42:52 2014 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 14 Feb 2014 16:42:52 +0100 Subject: RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation In-Reply-To: <52FE3271.2060504@oracle.com> References: <52FE1E72.3000809@oracle.com> <52FE2837.8070706@oracle.com> <52FE2C0E.8070404@oracle.com> <52FE3271.2060504@oracle.com> Message-ID: <52FE397C.9030504@oracle.com> Thanks for reviewing Dmitry! Stefan On 2014-02-14 16:12, Dmitry Samersoff wrote: > Stefan, > > Looks good for me. > > -Dmitry > > On 2014-02-14 18:45, Stefan Johansson wrote: >> Thanks Coleen! >> >> Yes, as you and Mikael said, the code is needed to calculate the used >> and free amount for the CMS generation and this is used by jmap. I guess >> the types I removed had been put there to prepare for some other SA >> feature that never came around. >> >> Cheers, >> Stefan >> >> On 2014-02-14 15:29, Coleen Phillimore wrote: >>> This cleanup looks good. To answer my own question (which you wrote >>> earlier), it looks like jmap uses this code and I assume the work on >>> SA.NEXT will address the duplication. >>> >>> Thanks, >>> Coleen >>> >>> On 2/14/14 8:47 AM, Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review this change to fix: >>>> https://bugs.openjdk.java.net/browse/JDK-8033440 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/ >>>> >>>> Summary: >>>> The compactibleFreeListSpace has been updated to use an >>>> AdaptiveFreeList instead of a FreeList. This change has not been done >>>> for the SA and it leads to using a too small element size when >>>> walking through the list. When fixing this I realized that >>>> FreeList and some other type declarations associated with >>>> it weren't used by the SA, so I went ahead and removed them. I (or >>>> Eclipse) also changed the Java *-imports to be specific ones. >>>> >>>> Testing: >>>> * JPRT for build and sanity. >>>> * UTE run for tests listed in bug. >>>> * Aurora run for tmtools.testlist. >>>> >>>> Thanks, >>>> Stefan > From daniel.daugherty at oracle.com Fri Feb 14 07:45:49 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Feb 2014 08:45:49 -0700 Subject: RFR (S) 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: <52FD5CC3.4090502@oracle.com> References: <52FD5CC3.4090502@oracle.com> Message-ID: <52FE3A2D.808@oracle.com> On 2/13/14 5:01 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8034249 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1 > src/share/vm/prims/jvmtiEnvBase.hpp line 360 and 446 are a bit long src/share/vm/prims/jvmtiEnv.cpp No comments. Thumbs up. Dan > > Summary: > > This issue was identified in the review of the 8032223 and it is > similar to the 8032223 > but impacts different JVMTI functions: > GetCurrentContendedMonitor, GetOwnedMonitorInfo, > GetOwnedMonitorStackDepthInfo, GetStackTrace > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() > may return different results: > - 1-st: true > - 2-nd: false > > This suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > This fix is to work around the 6280037. > It is more safe to collect the necesary information at a safepoint > instead of > relying on the suspension of the target thread. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei From daniel.daugherty at oracle.com Fri Feb 14 08:45:19 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 14 Feb 2014 09:45:19 -0700 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FE185F.4070605@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> <52FD5571.4010104@oracle.com> <52FE185F.4070605@oracle.com> Message-ID: <52FE481F.5080208@oracle.com> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ make/Makefile No comments. Makefile style question: Since all this ifeq(...) logic is around Makefile rules, should the rules themselves be indented by one tab or by one tab and some number of spaces. I scrolled around the Makefile and I don't really see consistent indenting of the rule lines themselves... If you change the indenting, I don't see a reason for another round of review. Dan On 2/14/14 6:21 AM, Erik Helin wrote: > Dan, > > On 2014-02-14 00:29, Daniel D. Daugherty wrote: >> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >> >> make/Makefile >> >> + ifeq ($(OSNAME), bsd) >> + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >> >> The above needs to be: >> >> ifeq ($(OS_VENDOR), Darwin) >> $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >> >> I don't think that BSD uses .dylib stuff; that's MacOS X specific. > > You are right, thanks for the correction. Please see new webrev at: > http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ > > Again, same testing as for prior patches were run. > > Thanks, > Erik > >> Dan >> >> >> On 2/13/14 1:59 PM, Erik Helin wrote: >>> Hi Dan, >>> >>> thanks for reviewing! See my replies inline. >>> >>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>> >>>> make/Makefile >>>> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>> 278 ifeq ($(OSNAME), windows) >>>> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >>>> $(EXPORT_SERVER_DIR)/jvm.pdb >>>> 280 else >>>> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >>>> 282 endif >>>> >>>> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >>>> you'll need a MacOS X specific rule. You don't need an >>>> update for the JVM_VARIANT_CLIENT version because MacOS X >>>> doesn't support the Client VM, but if it did... >>> >>> Thanks for catching this! I've uploaded a new webrev at: >>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>> >>> The same testing was done as for the first patch. >>> >>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>> So the above change handles libjvm, but what about the >>>> other libraries exported by HotSpot? libjsig, libjvm_db, >>>> and libjvm_dtrace come to mind... >>> >>> As we discussed, I would like to implement this for libjvm first and >>> then take care of the other libraries in a separate patch. >>> >>> Thanks, >>> Erik >>> >>>> Dan >>>> >>>> >>>> On 2/12/14 8:03 AM, Erik Helin wrote: >>>>> Hi all, >>>>> >>>>> this patch changes how old debug information copied from >>>>> IMPORT_JDK is >>>>> treated. >>>>> >>>>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>>>> entire IMPORT_JDK folder, including additional files (such as >>>>> unzipped >>>>> debug information). The export_*_jdk targets will then, via the >>>>> generic_export target, copy the build artifacts via implicit rules to >>>>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>>>> >>>>> The bug arises when IMPORT_JDK contains unzipped debug info >>>>> (libjvm.debuginfo) and the make target produces zipped debug info >>>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>>>> will match libjvm.so. >>>>> >>>>> Finally, the JPRT make targets jprt_build_* just zips >>>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>>>> having different zipped and unzipped debug info, since the IMPORT_JDK >>>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by default. >>>>> >>>>> This patch removes the debug info that we did *not* build. If we >>>>> build >>>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz >>>>> will be >>>>> removed (if it exists). >>>>> >>>>> Patch: >>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>>>> >>>>> Testing: >>>>> - Building in JPRT >>>>> - Building Linux 32-bit locally on a Linux 64-bit machine >>>>> - Building Linux 64-bit locally on a Linux 64-bit machine >>>>> >>>>> For all of the above, verify that only the correct debug info is >>>>> present in the output. >>>>> >>>>> Thanks, >>>>> Erik >>>> >> From alejandro.murillo at oracle.com Fri Feb 14 09:16:42 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 14 Feb 2014 10:16:42 -0700 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52FDC19B.2080004@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> <52FDBD13.2070307@oracle.com> <52FDC19B.2080004@oracle.com> Message-ID: <52FE4F7A.8000900@oracle.com> On 2/14/2014 12:11 AM, David Holmes wrote: > On 14/02/2014 4:52 PM, Alejandro E Murillo wrote: >> >> On 2/13/2014 9:47 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> To expand on a solution for this ... >>>> >>>> Note that in vm.make and gcc.make the only uses of the JVM_VARIANT >>>> variables relates to ZERO and ZEROSHARK. That is the real problem >>>> in my >>>> view (it was natural to use them as they were very prominent). >>>> >>>> Looking through the build process it seems to me that in the generated >>>> flags.make we will have: >>>> >>>> include zero|shark.make >>>> include gcc.make >>>> >>>> And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be >>>> used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH >>>> will >>>> also be zero but that doesn't help with shark.) >>>> >>>> Aside: note that here zero or shark is the VARIANT but that isn't >>>> exposed in the generated makefiles as the VARIANT is already >>>> implicit in >>>> the path to which the file was generated eg >>>> hotspot/__/product >>>> >>>> Similarly the generated vm.make will include flags.make before the >>>> repo >>>> version of vm.make so it too can use TYPE to identify ZERO or SHARK. >>>> >>>> If I knew how to build zero/shark I'd test this out. :( >>>> >>>> David >>>> ----- >>>> >>> This is a revised webrev using $(TYPE) in gcc.make and vm.make instead: >>> >>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ >>> >>> The BSD changes mirror the GNU/Linux ones, as in the 7141426 change >>> which broke the build, but I've no means to test on that platform. >> I'll submit a couple of jprt jobs with these changes > > I read that as meaning Andrew couldn't do a zero BSD build. Right. so doesn't make sense then to do further testing if that hasn't been verified, Andrew, let me know when that's verified and I can run some additional tests with jprt Thanks Alejandro > > Andrew: thanks for doing this. The functional changes to the build > files etc look fine to me. > > However I don't know about the additional copyrights that were added. > I can't see anything in the OpenJDK rules/charter/legal, or the OCA, > that addresses this. > > Thanks, > David > >> thanks >> -- Alejandro From calvin.cheung at oracle.com Fri Feb 14 09:18:55 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 14 Feb 2014 09:18:55 -0800 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FE2AB9.9020609@oracle.com> References: <52FDBC7B.9000204@oracle.com> <52FE2AB9.9020609@oracle.com> Message-ID: <52FE4FFF.5080000@oracle.com> Thanks for your review, Dan. Calvin On 2/14/2014 6:39 AM, Daniel D. Daugherty wrote: > > webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ > > src/share/vm/prims/whitebox.hpp > No comments. > > Thumbs up. > > Dan > > > On 2/13/14 11:49 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8034860 >> >> Please review this fix for fixing a regression caused by the fix for >> 8028785. >> >> The problem is that the env->ExpectionCheck() is being called from a >> vm thread >> and triggers the following assert in trasition_from_native(): >> >> assert(thread->thread_state() == _thread_in_native, "coming from >> wrong thread state"); >> >> A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION >> macros. >> >> Thanks to coleen.phillimore at oracle.com who suggested this fix. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ >> >> Testing: >> jtreg hotspot/test/*, java/lang/invoke (on linux_x64) >> jtreg sun/misc (on windows_x64 and linux_x64) >> jprt (in progress) >> >> thanks, >> Calvin > From serguei.spitsyn at oracle.com Fri Feb 14 09:31:37 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Feb 2014 09:31:37 -0800 Subject: RFR (S) 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: <52FE3A2D.808@oracle.com> References: <52FD5CC3.4090502@oracle.com> <52FE3A2D.808@oracle.com> Message-ID: <52FE52F9.5070701@oracle.com> On 2/14/14 7:45 AM, Daniel D. Daugherty wrote: > On 2/13/14 5:01 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8034249 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1 >> > > src/share/vm/prims/jvmtiEnvBase.hpp > line 360 and 446 are a bit long I'll split the lines. > > src/share/vm/prims/jvmtiEnv.cpp > No comments. > > Thumbs up. Thank you for review! Serguei > > Dan > > > >> >> Summary: >> >> This issue was identified in the review of the 8032223 and it is >> similar to the 8032223 >> but impacts different JVMTI functions: >> GetCurrentContendedMonitor, GetOwnedMonitorInfo, >> GetOwnedMonitorStackDepthInfo, GetStackTrace >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() >> may return different results: >> - 1-st: true >> - 2-nd: false >> >> This suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> This fix is to work around the 6280037. >> It is more safe to collect the necesary information at a safepoint >> instead of >> relying on the suspension of the target thread. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei > From calvin.cheung at oracle.com Fri Feb 14 09:43:43 2014 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 14 Feb 2014 09:43:43 -0800 Subject: RFR(S): 8034860: Fatal error due to incorrect thread state during nightly testing In-Reply-To: <52FE24AB.5090708@oracle.com> References: <52FDBC7B.9000204@oracle.com> <52FDC27D.10404@oracle.com> <52FDC4BE.4020906@oracle.com> <52FE24AB.5090708@oracle.com> Message-ID: <52FE55CF.7020305@oracle.com> Thanks for your review, Coleen. Calvin On 2/14/2014 6:14 AM, Coleen Phillimore wrote: > > This looks good. Thank you for the testing and verification. > > Coleen > > On 2/14/14 2:24 AM, Calvin Cheung wrote: >> David, >> >> Thanks for your quick review. >> >> Calvin >> >> On 2/13/2014 11:15 PM, David Holmes wrote: >>> Hi Calvin, >>> >>> On 14/02/2014 4:49 PM, Calvin Cheung wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8034860 >>>> >>>> Please review this fix for fixing a regression caused by the fix for >>>> 8028785. >>>> >>>> The problem is that the env->ExpectionCheck() is being called from >>>> a vm >>>> thread >>>> and triggers the following assert in trasition_from_native(): >>>> >>>> assert(thread->thread_state() == _thread_in_native, "coming from >>>> wrong thread state"); >>>> >>>> A fix is to use the HAS_PENDING_EXCEPTION and CLEAR_PENDING_EXCEPTION >>>> macros. >>> >>> This seems a reasonable solution. >>> >>> Thanks, >>> David >>> >>> >>>> Thanks to coleen.phillimore at oracle.com who suggested this fix. >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8034860/webrev/ >>>> >>>> Testing: >>>> jtreg hotspot/test/*, java/lang/invoke (on linux_x64) >>>> jtreg sun/misc (on windows_x64 and linux_x64) >>>> jprt (in progress) >>>> >>>> thanks, >>>> Calvin >> > From alejandro.murillo at oracle.com Fri Feb 14 10:48:46 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 14 Feb 2014 18:48:46 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.80-b02 for changeset b1d29549dca7 Message-ID: <20140214184848.B6C1A62C79@hg.openjdk.java.net> Changeset: a1c6662d6d87 Author: amurillo Date: 2014-02-14 08:44 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/a1c6662d6d87 Added tag hs24.80-b02 for changeset b1d29549dca7 ! .hgtags From alejandro.murillo at oracle.com Fri Feb 14 13:22:37 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 14 Feb 2014 21:22:37 +0000 Subject: hg: hsx/jdk7u/hotspot: 8034920: new hotspot build - hs24.80-b03 Message-ID: <20140214212240.6536C62C80@hg.openjdk.java.net> Changeset: d2630ee5c3c9 Author: amurillo Date: 2014-02-14 09:19 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d2630ee5c3c9 8034920: new hotspot build - hs24.80-b03 Reviewed-by: jcoomes ! make/hotspot_version From daniel.daugherty at oracle.com Fri Feb 14 14:47:44 2014 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 14 Feb 2014 22:47:44 +0000 Subject: hg: hsx/jdk7u/hotspot: 3 new changesets Message-ID: <20140214224751.4550E62C81@hg.openjdk.java.net> Changeset: 418fb371f2b9 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/418fb371f2b9 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 1c2233fa1996 Author: dcubed Date: 2014-02-14 10:54 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/1c2233fa1996 Merge Changeset: bf22a6e0c183 Author: dcubed Date: 2014-02-14 13:28 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/bf22a6e0c183 Merge From david.holmes at oracle.com Sun Feb 16 17:44:27 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Feb 2014 11:44:27 +1000 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot In-Reply-To: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> References: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> Message-ID: <5301697B.9040307@oracle.com> src/share/vm/prims/jni.cpp Indent is wrong here: JNI_ENTRY(jobject, jni_NewGlobalRef(JNIEnv *env, jobject ref)) JNIWrapper("NewGlobalRef"); ! ! HOTSPOT_JNI_NEWGLOBALREF_ENTRY(env, ref); ! Is it worth renaming src/share/vm/utilities/dtrace_usdt2_disabled.hpp to just src/share/vm/utilities/dtrace_disabled.hpp ? Or maybe even fold the content back into dtrace.hpp Otherwise looks good to see this all get stripped out! Thanks, David On 11/02/2014 8:12 PM, Staffan Larsen wrote: > Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) implementations have moved to USDT2, we can finally remove the USDT1 code from hotspot. > > There are quite a lot of changes in this review, and webrev barfed on the number of change in jni.cpp so that file can only be reviewed from the patch file. The good news is that the changes are mostly trivial removal of #ifdef:ed code. > > bug: https://bugs.openjdk.java.net/browse/JDK-8034080 > webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ > > Testing: I have run jck-runtime, vm.quick.testlist and vm.dtrace.testlist on Solaris and OS X. > > /Staffan > From david.holmes at oracle.com Sun Feb 16 17:53:02 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Feb 2014 11:53:02 +1000 Subject: RFR: JDK-8030350 : (s) Enable additional compiler warnings for GCC In-Reply-To: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> References: <3C1A5F6C-DB56-4D8A-811A-ED63C7AF1BE0@oracle.com> Message-ID: <53016B7E.9060504@oracle.com> On 12/02/2014 5:42 AM, Mike Duigou wrote: > Hello all; > > This is a final update to the previously reviewed changeset. I had to make one slight change in hotspot/src/os/bsd/vm/os_bsd.cpp to accommodate a problem which appeared since this process began. I'd say that's a bug in the checking logic. But all still good. Thanks, David > http://cr.openjdk.java.net/~mduigou/JDK-8030350/5/webrev/ > > This change will be integrated through the jdk9/hs-rt repos. > > From the original review request: > >> This is a change which enables additional compiler warnings for native compilation when using GCC. The (-Wformat -Wformat-security) options are supported by GCC 3.0.4 (the earliest version I checked, c. February 2002) and later so we shouldn't see issues with incompatibility.- Wextra appears to have been added in GCC 3.4.X line (c. 2004) so it should also be reasonably well adopted and replaces -W. >> >> The core of the change is to add : >> >> -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 >> >> for general C and CC++ compilations. For HotSpot C++ compiles a slightly less aggressive set is used: >> >> -Wformat=2 -Wno-error=format-nonliteral >> >> is used. >> >> This change is targeted at the JDK 9 repos but could be backported to JDK 8 fairly easily/safely. > > > Mike > From david.holmes at oracle.com Sun Feb 16 18:15:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Feb 2014 12:15:12 +1000 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <52FC73B6.7070701@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> Message-ID: <530170B0.30308@oracle.com> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: > > On 2014-02-05 19:09, Volker Simonis wrote: >> If there are any more/other comments on this topic I'll be highly >> interested. > > You can count on me having lots of opinion on build issues. ;-) > > I'd like to get rid of the hard-coded map files completely, both in > hotspot and jdk. This can be done without loss of functionality. How? > Because we can generate them on the fly at build time, using information > provided by the source code. Does that account for the dynamically generated symbols used by the SA? David > Note that the exported functions are prefixed by the macro JNIEXPORT. We > can locate all functions that have this prefix and write them to a map > file. This can be done, and was indeed the way we solved things back in > the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" > and check for a symbol name (as provided by nm). We had rules requiring > that JNIEXPORT was to be written on the same line as the function name, > or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" > and then cross-reference for names extracted by nm. Not exactly a formal > semantic parsing, but it was efficient and worked very well. I believe > we can do something very similar for hotspot and jdk. > > Then again, if we could get rid of maps completely, by using visibility > and not linking statically with the standard libs, that would be even > better. :-) > > /Magnus From david.holmes at oracle.com Sun Feb 16 18:46:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Feb 2014 12:46:29 +1000 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <52FE4F7A.8000900@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> <52FDBD13.2070307@oracle.com> <52FDC19B.2080004@oracle.com> <52FE4F7A.8000900@oracle.com> Message-ID: <53017805.80903@oracle.com> On 15/02/2014 3:16 AM, Alejandro E Murillo wrote: > > On 2/14/2014 12:11 AM, David Holmes wrote: >> On 14/02/2014 4:52 PM, Alejandro E Murillo wrote: >>> >>> On 2/13/2014 9:47 PM, Andrew Hughes wrote: >>>> ----- Original Message ----- >>>>> To expand on a solution for this ... >>>>> >>>>> Note that in vm.make and gcc.make the only uses of the JVM_VARIANT >>>>> variables relates to ZERO and ZEROSHARK. That is the real problem >>>>> in my >>>>> view (it was natural to use them as they were very prominent). >>>>> >>>>> Looking through the build process it seems to me that in the generated >>>>> flags.make we will have: >>>>> >>>>> include zero|shark.make >>>>> include gcc.make >>>>> >>>>> And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE can be >>>>> used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH >>>>> will >>>>> also be zero but that doesn't help with shark.) >>>>> >>>>> Aside: note that here zero or shark is the VARIANT but that isn't >>>>> exposed in the generated makefiles as the VARIANT is already >>>>> implicit in >>>>> the path to which the file was generated eg >>>>> hotspot/__/product >>>>> >>>>> Similarly the generated vm.make will include flags.make before the >>>>> repo >>>>> version of vm.make so it too can use TYPE to identify ZERO or SHARK. >>>>> >>>>> If I knew how to build zero/shark I'd test this out. :( >>>>> >>>>> David >>>>> ----- >>>>> >>>> This is a revised webrev using $(TYPE) in gcc.make and vm.make instead: >>>> >>>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ >>>> >>>> The BSD changes mirror the GNU/Linux ones, as in the 7141426 change >>>> which broke the build, but I've no means to test on that platform. >>> I'll submit a couple of jprt jobs with these changes >> >> I read that as meaning Andrew couldn't do a zero BSD build. > Right. so doesn't make sense then to do further testing if that hasn't > been verified, I think it makes sense to test on all the regular platforms while waiting to see if Andrew can find someone (or someone reading this volunteers) who can do a Zero build on BSD. ( Unfortunately I couldn't even get a basic linux zero build to work :( ). Visually the changes are identical to the linux ones so I see no reason to expect they would not work. That said this change has very low risk attached to it now. The change to buildtree.make is one that we already use in JDK 8. The other changes are zero/shark specific. David ----- > Andrew, let me know when that's verified and I can run some additional > tests with jprt > > Thanks > Alejandro >> >> Andrew: thanks for doing this. The functional changes to the build >> files etc look fine to me. >> >> However I don't know about the additional copyrights that were added. >> I can't see anything in the OpenJDK rules/charter/legal, or the OCA, >> that addresses this. >> >> Thanks, >> David >> >>> thanks >>> > From staffan.larsen at oracle.com Sun Feb 16 23:38:09 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Feb 2014 08:38:09 +0100 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot In-Reply-To: <5301697B.9040307@oracle.com> References: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> <5301697B.9040307@oracle.com> Message-ID: On 17 feb 2014, at 02:44, David Holmes wrote: > src/share/vm/prims/jni.cpp > > Indent is wrong here: > > JNI_ENTRY(jobject, jni_NewGlobalRef(JNIEnv *env, jobject ref)) > JNIWrapper("NewGlobalRef"); > ! > ! HOTSPOT_JNI_NEWGLOBALREF_ENTRY(env, ref); > ! Sharp eyes! Fixed. > Is it worth renaming src/share/vm/utilities/dtrace_usdt2_disabled.hpp to just src/share/vm/utilities/dtrace_disabled.hpp ? Or maybe even fold the content back into dtrace.hpp Good point. Given how large (and boring) it is I kept it as a separate file but renamed it. > Otherwise looks good to see this all get stripped out! Updated webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.01/ Thanks, /Staffan > > Thanks, > David > > > > On 11/02/2014 8:12 PM, Staffan Larsen wrote: >> Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) implementations have moved to USDT2, we can finally remove the USDT1 code from hotspot. >> >> There are quite a lot of changes in this review, and webrev barfed on the number of change in jni.cpp so that file can only be reviewed from the patch file. The good news is that the changes are mostly trivial removal of #ifdef:ed code. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8034080 >> webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ >> >> Testing: I have run jck-runtime, vm.quick.testlist and vm.dtrace.testlist on Solaris and OS X. >> >> /Staffan >> From staffan.larsen at oracle.com Sun Feb 16 23:50:16 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Feb 2014 08:50:16 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <530170B0.30308@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> Message-ID: On 17 feb 2014, at 03:15, David Holmes wrote: > On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >> >> On 2014-02-05 19:09, Volker Simonis wrote: >>> If there are any more/other comments on this topic I'll be highly >>> interested. >> >> You can count on me having lots of opinion on build issues. ;-) >> >> I'd like to get rid of the hard-coded map files completely, both in >> hotspot and jdk. This can be done without loss of functionality. How? >> Because we can generate them on the fly at build time, using information >> provided by the source code. > > Does that account for the dynamically generated symbols used by the SA? I think the symbols SA care about are all already declared with JNIEXPORT. /Staffan > > David > >> Note that the exported functions are prefixed by the macro JNIEXPORT. We >> can locate all functions that have this prefix and write them to a map >> file. This can be done, and was indeed the way we solved things back in >> the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" >> and check for a symbol name (as provided by nm). We had rules requiring >> that JNIEXPORT was to be written on the same line as the function name, >> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >> and then cross-reference for names extracted by nm. Not exactly a formal >> semantic parsing, but it was efficient and worked very well. I believe >> we can do something very similar for hotspot and jdk. >> >> Then again, if we could get rid of maps completely, by using visibility >> and not linking statically with the standard libs, that would be even >> better. :-) >> >> /Magnus From erik.joelsson at oracle.com Mon Feb 17 00:09:07 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Feb 2014 09:09:07 +0100 Subject: RFR: 8033580: Old debug information in IMPORT_JDK is not removed In-Reply-To: <52FE481F.5080208@oracle.com> References: <52FB8D4B.7080807@oracle.com> <52FC0683.2010301@oracle.com> <52FD3218.9010403@oracle.com> <52FD5571.4010104@oracle.com> <52FE185F.4070605@oracle.com> <52FE481F.5080208@oracle.com> Message-ID: <5301C3A3.1090406@oracle.com> Hello, The change looks good to me too. Regarding indentation, for the rest of the JDK, we indent rules with make ifeqs like this: target: sources <8 spaces>ifeq (something) recipe line <8 spaces>endif Our reasoning is that it should still look like a recipe when glancing over it quickly (so 8 characters base indentation). After that we apply our standard 2 chars per logical level. Since make regards tab characters as special, we have to use space for non recipe lines. The rest of our guidelines can be found here: http://openjdk.java.net/groups/build/doc/code-conventions.html /Erik On 2014-02-14 17:45, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ > > make/Makefile > No comments. > > Makefile style question: > Since all this ifeq(...) logic is around Makefile rules, > should the rules themselves be indented by one tab or by > one tab and some number of spaces. > > I scrolled around the Makefile and I don't really see > consistent indenting of the rule lines themselves... > > If you change the indenting, I don't see a reason for > another round of review. > > Dan > > > On 2/14/14 6:21 AM, Erik Helin wrote: >> Dan, >> >> On 2014-02-14 00:29, Daniel D. Daugherty wrote: >>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>> >>> make/Makefile >>> >>> + ifeq ($(OSNAME), bsd) >>> + $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>> >>> The above needs to be: >>> >>> ifeq ($(OS_VENDOR), Darwin) >>> $(RM) -rf $(EXPORT_SERVER_DIR)/libjvm.dylib.dSYM >>> >>> I don't think that BSD uses .dylib stuff; that's MacOS X specific. >> >> You are right, thanks for the correction. Please see new webrev at: >> http://cr.openjdk.java.net/~ehelin/8033580/webrev.03/ >> >> Again, same testing as for prior patches were run. >> >> Thanks, >> Erik >> >>> Dan >>> >>> >>> On 2/13/14 1:59 PM, Erik Helin wrote: >>>> Hi Dan, >>>> >>>> thanks for reviewing! See my replies inline. >>>> >>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>> > http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>> >>>>> make/Makefile >>>>> 277 ifeq ($(ZIP_DEBUGINFO_FILES),1) >>>>> 278 ifeq ($(OSNAME), windows) >>>>> 279 $(RM) -f $(EXPORT_SERVER_DIR)/jvm.map >>>>> $(EXPORT_SERVER_DIR)/jvm.pdb >>>>> 280 else >>>>> 281 $(RM) -f $(EXPORT_SERVER_DIR)/libjvm.debuginfo >>>>> 282 endif >>>>> >>>>> On MacOS X, the debuginfo will be in libjvm.dylib.dSYM so >>>>> you'll need a MacOS X specific rule. You don't need an >>>>> update for the JVM_VARIANT_CLIENT version because MacOS X >>>>> doesn't support the Client VM, but if it did... >>>> >>>> Thanks for catching this! I've uploaded a new webrev at: >>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.01/ >>>> >>>> The same testing was done as for the first patch. >>>> >>>> On 02/13/2014 12:40 AM, Daniel D. Daugherty wrote: >>>>> So the above change handles libjvm, but what about the >>>>> other libraries exported by HotSpot? libjsig, libjvm_db, >>>>> and libjvm_dtrace come to mind... >>>> >>>> As we discussed, I would like to implement this for libjvm first and >>>> then take care of the other libraries in a separate patch. >>>> >>>> Thanks, >>>> Erik >>>> >>>>> Dan >>>>> >>>>> >>>>> On 2/12/14 8:03 AM, Erik Helin wrote: >>>>>> Hi all, >>>>>> >>>>>> this patch changes how old debug information copied from >>>>>> IMPORT_JDK is >>>>>> treated. >>>>>> >>>>>> When running the copy_*_jdk target, HotSpot's makefiles copies the >>>>>> entire IMPORT_JDK folder, including additional files (such as >>>>>> unzipped >>>>>> debug information). The export_*_jdk targets will then, via the >>>>>> generic_export target, copy the build artifacts via implicit >>>>>> rules to >>>>>> the correct destination in hotspot/build/JDK_IMAGE_DIR. >>>>>> >>>>>> The bug arises when IMPORT_JDK contains unzipped debug info >>>>>> (libjvm.debuginfo) and the make target produces zipped debug info >>>>>> (libjvm.diz), or vice versa. hotspot/build/JDK_IMAGE_DIR will then >>>>>> contain both libjvm.debuginfo and libjvm.diz, but only one of them >>>>>> will match libjvm.so. >>>>>> >>>>>> Finally, the JPRT make targets jprt_build_* just zips >>>>>> hotspot/build/$(JDK_IMAGE_DIR). The zipped JPRT bundle will end up >>>>>> having different zipped and unzipped debug info, since the >>>>>> IMPORT_JDK >>>>>> in JPRT contains libjvm.debuginfo and we build libjvm.diz by >>>>>> default. >>>>>> >>>>>> This patch removes the debug info that we did *not* build. If we >>>>>> build >>>>>> libjvm.diz, then libjvm.debuginfo will be removed (if it exists). >>>>>> Correspondingly, if we build libjvm.debuginfo, then libjvm.diz >>>>>> will be >>>>>> removed (if it exists). >>>>>> >>>>>> Patch: >>>>>> http://cr.openjdk.java.net/~ehelin/8033580/webrev.00/ >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8033580 >>>>>> >>>>>> Testing: >>>>>> - Building in JPRT >>>>>> - Building Linux 32-bit locally on a Linux 64-bit machine >>>>>> - Building Linux 64-bit locally on a Linux 64-bit machine >>>>>> >>>>>> For all of the above, verify that only the correct debug info is >>>>>> present in the output. >>>>>> >>>>>> Thanks, >>>>>> Erik >>>>> >>> > From dmitry.samersoff at oracle.com Mon Feb 17 00:18:49 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 17 Feb 2014 12:18:49 +0400 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> Message-ID: <5301C5E9.1050703@oracle.com> Staffan, I'd dived into this problem last week. SA uses address of vtable (_ZTV* symbols) to calculate base addresses for couple of internal structures. i.e. (roughly) it takes vtable address, add offset from vm_structs and get the data. Since the time when hotspot build switched to gcc 4.x it doesn't work, so many of SA command (e.g. jdis) is broken now. I'm looking for solution. see https://bugs.openjdk.java.net/browse/JDK-8034065 -Dmitry On 2014-02-17 11:50, Staffan Larsen wrote: > > On 17 feb 2014, at 03:15, David Holmes wrote: > >> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >>> >>> On 2014-02-05 19:09, Volker Simonis wrote: >>>> If there are any more/other comments on this topic I'll be highly >>>> interested. >>> >>> You can count on me having lots of opinion on build issues. ;-) >>> >>> I'd like to get rid of the hard-coded map files completely, both in >>> hotspot and jdk. This can be done without loss of functionality. How? >>> Because we can generate them on the fly at build time, using information >>> provided by the source code. >> >> Does that account for the dynamically generated symbols used by the SA? > > I think the symbols SA care about are all already declared with JNIEXPORT. > > /Staffan > >> >> David >> >>> Note that the exported functions are prefixed by the macro JNIEXPORT. We >>> can locate all functions that have this prefix and write them to a map >>> file. This can be done, and was indeed the way we solved things back in >>> the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" >>> and check for a symbol name (as provided by nm). We had rules requiring >>> that JNIEXPORT was to be written on the same line as the function name, >>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >>> and then cross-reference for names extracted by nm. Not exactly a formal >>> semantic parsing, but it was efficient and worked very well. I believe >>> we can do something very similar for hotspot and jdk. >>> >>> Then again, if we could get rid of maps completely, by using visibility >>> and not linking statically with the standard libs, that would be even >>> better. :-) >>> >>> /Magnus > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From per.liden at oracle.com Mon Feb 17 01:58:05 2014 From: per.liden at oracle.com (Per Liden) Date: Mon, 17 Feb 2014 10:58:05 +0100 Subject: RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline In-Reply-To: <52FBAB90.1020608@oracle.com> References: <52E90809.3000900@oracle.com> <52F91199.6030308@oracle.com> <52FA3DD9.20004@oracle.com> <52FBAB90.1020608@oracle.com> Message-ID: <5301DD2D.3040204@oracle.com> Stefan, I think this is a nice fix for the problem and it also cleans up the gclocker a bit. But I have a few minor comments: vmGCOperations.cpp: 110 err_msg("GC triggered before VM initialization completed. Try increasing " 111 "NewSize, current value " UINTX_FORMAT "K.", NewSize / K)); I'd suggest you use byte_size_in_proper_unit()/proper_unit_for_byte_size() instead of a "K", or maybe just not print the size at all. With the removal of GC_locker::lock()/unlock() there's no longer anyone how modifies Thread::current()->_gc_locked_out_count. So we should be able to remove it. However, UnhandledOops::clear_unhandled_oops() still uses is_gc_locked_out() so that needs to be changed to check for something else, is_init_completed maybe? cheers, /Per On 02/12/2014 06:12 PM, Stefan Johansson wrote: > Hi, > > Stefan K pointed out to me that in the Metaspace code we use > is_init_completed() to verify that the VM is fully initialized. I > started looking at where we do set_init_completed() and realized that it > is right where we are ready to handle a GC. It makes sense to try to > minimize the different ways we check if the VM is fully initialized. > Using is_init_completed() instead of the GC locker to prevent GCs during > startup has another nice effect too; we can remove one of the two > different lock mechanisms in the GC locker. > > The new proposal removes the use of GC_locker::lock()/unlock() which is > only used to prevent GCs during startup. Instead there is a check in the > GC operations prologue, to ensure that the VM is initialized when the GC > starts. > > Please review the new the change: > http://cr.openjdk.java.net/~sjohanss/8028498/webrev.02/ > > Testing: > * JPRT > * GC locker test through UTE > > Thanks, > Stefan > > On 2014-02-11 16:12, Stefan Johansson wrote: >> Hi again =) >> >> Don't spend time on the current webrev (02). I've gotten some more >> comments on the proposed fix and will look at a solution that allow us >> to remove the GC locker usage during initialization. >> >> Cheers, >> Stefan >> >> On 2014-02-10 18:51, Stefan Johansson wrote: >>> Hi again, >>> >>> After a couple of offline discussions with different people I've come >>> to the conclusion to split out the sizing of the young generation >>> from the fix for this issue. I've created a new bug (JDK-8033426) for >>> that, which is currently out for review. >>> >>> The discussions also lead to a different approach for fixing this >>> issue. The new proposal is to use the GC locker to prevent GCs until >>> we are ready to handle them and otherwise fail the VM initialization. >>> The gc locker has two different mechanisms for locking out the GC, >>> one which is used during initialization and one used to stall GCs >>> when doing critical JNI work. The part of the initialization that >>> currently is locked by the GC locker is to narrow and there is no >>> guarantee that a GC can be handled after the GC locker is unlocked. >>> This fix will extend the part that is locked and also add a check >>> that if a GC is initiated while locked during startup the VM exits. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.01/ >>> >>> Thanks, >>> Stefan >>> >>> On 2014-01-29 14:54, Stefan Johansson wrote: >>>> Hi, >>>> >>>> Please review this fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8028498 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/ >>>> >>>> Summary: >>>> The initial young generation size has been fairly small by default >>>> (1.5M) and if setting ObjectAlignmentInBytes to something larger >>>> than the default it can causes CDS to trigger a GC when dumping the >>>> archive. At this point the VM is not ready to handle a GC and we >>>> will hit an assertion. Making sure we can handle a GC at this point >>>> is not trivial and the proposed solution is to alter the default >>>> sizing of the young generation as well as adding a safety check when >>>> dumping the archive to exit the VM if the young generation is too >>>> small. >>>> >>>> Testing: >>>> * JPRT build and test passes >>>> * Failing test now passes on all platforms (tested throught JPRT) >>>> * Verified that the GC and Runtime jtreg tests still passes >>>> >>>> Cheers, >>>> Stefan >>> >> > From staffan.larsen at oracle.com Mon Feb 17 02:08:01 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 17 Feb 2014 11:08:01 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <5301C5E9.1050703@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> Message-ID: <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> Good that you are looking at it. My comment was on map-files. The static map files we have today aren?t involved with creating vtable symbols. /Staffan On 17 feb 2014, at 09:18, Dmitry Samersoff wrote: > Staffan, > > I'd dived into this problem last week. > > SA uses address of vtable (_ZTV* symbols) to calculate base addresses > for couple of internal structures. > > i.e. (roughly) it takes vtable address, add offset from vm_structs and > get the data. > > Since the time when hotspot build switched to gcc 4.x it doesn't work, > so many of SA command (e.g. jdis) is broken now. > > I'm looking for solution. > > see > https://bugs.openjdk.java.net/browse/JDK-8034065 > > -Dmitry > > > On 2014-02-17 11:50, Staffan Larsen wrote: >> >> On 17 feb 2014, at 03:15, David Holmes wrote: >> >>> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >>>> >>>> On 2014-02-05 19:09, Volker Simonis wrote: >>>>> If there are any more/other comments on this topic I'll be highly >>>>> interested. >>>> >>>> You can count on me having lots of opinion on build issues. ;-) >>>> >>>> I'd like to get rid of the hard-coded map files completely, both in >>>> hotspot and jdk. This can be done without loss of functionality. How? >>>> Because we can generate them on the fly at build time, using information >>>> provided by the source code. >>> >>> Does that account for the dynamically generated symbols used by the SA? >> >> I think the symbols SA care about are all already declared with JNIEXPORT. >> >> /Staffan >> >>> >>> David >>> >>>> Note that the exported functions are prefixed by the macro JNIEXPORT. We >>>> can locate all functions that have this prefix and write them to a map >>>> file. This can be done, and was indeed the way we solved things back in >>>> the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" >>>> and check for a symbol name (as provided by nm). We had rules requiring >>>> that JNIEXPORT was to be written on the same line as the function name, >>>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >>>> and then cross-reference for names extracted by nm. Not exactly a formal >>>> semantic parsing, but it was efficient and worked very well. I believe >>>> we can do something very similar for hotspot and jdk. >>>> >>>> Then again, if we could get rid of maps completely, by using visibility >>>> and not linking statically with the standard libs, that would be even >>>> better. :-) >>>> >>>> /Magnus >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sergei.kovalev at oracle.com Mon Feb 17 04:32:42 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 17 Feb 2014 16:32:42 +0400 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof Message-ID: <5302016A.1020906@oracle.com> Hello everyone, I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. As it was discussed, I prepared fix for the issue: http://cr.openjdk.java.net/~anazarov/8022203/webrev.01/ The failure caused by slippage in IO operation due to file system performance. To avoid this situation we will use an unique file name for profiling dump. In this case we will have zero probability that tests would overlapped by output file. By default the file name for dump output builds from library name plus .java. prefix and .txt suffix. Hprof tool supports "file" option that used for providing the output file name. Therefore we can just add unique file name to options string for each individual tests that used hprof. Testing done: - single run of tests - Stability run of all modified tests - Modified stability run. I did some test modification that helped me to increase reproducibility rating. It was 500-1000 iteration instead 10,000 in original case. Test with modified options string ran 10,000 iteration. Could you please approve fix? -- With best regards, Sergei From david.holmes at oracle.com Mon Feb 17 05:56:03 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Feb 2014 23:56:03 +1000 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot In-Reply-To: References: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> <5301697B.9040307@oracle.com> Message-ID: <530214F3.6080803@oracle.com> Ship it! :) David On 17/02/2014 5:38 PM, Staffan Larsen wrote: > > On 17 feb 2014, at 02:44, David Holmes wrote: > >> src/share/vm/prims/jni.cpp >> >> Indent is wrong here: >> >> JNI_ENTRY(jobject, jni_NewGlobalRef(JNIEnv *env, jobject ref)) >> JNIWrapper("NewGlobalRef"); >> ! >> ! HOTSPOT_JNI_NEWGLOBALREF_ENTRY(env, ref); >> ! > > Sharp eyes! Fixed. > >> Is it worth renaming src/share/vm/utilities/dtrace_usdt2_disabled.hpp to just src/share/vm/utilities/dtrace_disabled.hpp ? Or maybe even fold the content back into dtrace.hpp > > Good point. Given how large (and boring) it is I kept it as a separate file but renamed it. > >> Otherwise looks good to see this all get stripped out! > > Updated webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.01/ > > Thanks, > /Staffan > >> >> Thanks, >> David >> >> >> >> On 11/02/2014 8:12 PM, Staffan Larsen wrote: >>> Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) implementations have moved to USDT2, we can finally remove the USDT1 code from hotspot. >>> >>> There are quite a lot of changes in this review, and webrev barfed on the number of change in jni.cpp so that file can only be reviewed from the patch file. The good news is that the changes are mostly trivial removal of #ifdef:ed code. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8034080 >>> webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ >>> >>> Testing: I have run jck-runtime, vm.quick.testlist and vm.dtrace.testlist on Solaris and OS X. >>> >>> /Staffan >>> > From goetz.lindenmaier at sap.com Mon Feb 17 05:56:14 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 17 Feb 2014 13:56:14 +0000 Subject: assertion in ciTypeFlow OSR'ing in finally clause Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> Hi, I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. It tries to osr-compile a method at a bytecode in a finally clause. As far as I understand the assertion is too strict. The initial assertion is # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, tid=4398488891968 # assert(return_address->is_return_address()) failed: verify: wrong type This happens because a block in the finally clause is analyzed while not both predecessor blocks have been looked at. Thus the join of the slots that should contain the return address yields bottom, and the assertion fires. To get the dbg build passing, I have to remove 5 assertions: ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); If I remove these, compilation is aborted a bit later with the message: "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" I wonder whether I should fix this by adapting the assertions, or whether I should abort the compilation right away. I would appreciate some comments on this issue! Best regards, Goetz. From coleen.phillimore at oracle.com Mon Feb 17 06:18:28 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Feb 2014 09:18:28 -0500 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot In-Reply-To: <530214F3.6080803@oracle.com> References: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> <5301697B.9040307@oracle.com> <530214F3.6080803@oracle.com> Message-ID: <53021A34.7000906@oracle.com> Ship it + 1. thank you for doing this change! Coleen On 2/17/14 8:56 AM, David Holmes wrote: > Ship it! :) > > David > > On 17/02/2014 5:38 PM, Staffan Larsen wrote: >> >> On 17 feb 2014, at 02:44, David Holmes wrote: >> >>> src/share/vm/prims/jni.cpp >>> >>> Indent is wrong here: >>> >>> JNI_ENTRY(jobject, jni_NewGlobalRef(JNIEnv *env, jobject ref)) >>> JNIWrapper("NewGlobalRef"); >>> ! >>> ! HOTSPOT_JNI_NEWGLOBALREF_ENTRY(env, ref); >>> ! >> >> Sharp eyes! Fixed. >> >>> Is it worth renaming >>> src/share/vm/utilities/dtrace_usdt2_disabled.hpp to just >>> src/share/vm/utilities/dtrace_disabled.hpp ? Or maybe even fold the >>> content back into dtrace.hpp >> >> Good point. Given how large (and boring) it is I kept it as a >> separate file but renamed it. >> >>> Otherwise looks good to see this all get stripped out! >> >> Updated webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.01/ >> >> Thanks, >> /Staffan >> >>> >>> Thanks, >>> David >>> >>> >>> >>> On 11/02/2014 8:12 PM, Staffan Larsen wrote: >>>> Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) >>>> implementations have moved to USDT2, we can finally remove the >>>> USDT1 code from hotspot. >>>> >>>> There are quite a lot of changes in this review, and webrev barfed >>>> on the number of change in jni.cpp so that file can only be >>>> reviewed from the patch file. The good news is that the changes are >>>> mostly trivial removal of #ifdef:ed code. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8034080 >>>> webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ >>>> >>>> Testing: I have run jck-runtime, vm.quick.testlist and >>>> vm.dtrace.testlist on Solaris and OS X. >>>> >>>> /Staffan >>>> >> From daniel.daugherty at oracle.com Mon Feb 17 06:26:45 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 17 Feb 2014 07:26:45 -0700 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> Message-ID: <53021C25.10106@oracle.com> On 2/17/14 3:08 AM, Staffan Larsen wrote: > Good that you are looking at it. > > My comment was on map-files. The static map files we have today aren?t involved with creating vtable symbols. Perhaps I'm misunderstanding what you mean here. I agree that the map-files do not create the vtable symbols, but they are involved with exporting vtable symols. There's a hook in the non-windows mapfiles: $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/map* make/bsd/makefiles/mapfile-vers-darwin-debug: # INSERT VTABLE SYMBOLS HERE make/bsd/makefiles/mapfile-vers-darwin-product: # INSERT VTABLE SYMBOLS HERE make/bsd/makefiles/mapfile-vers-debug: # INSERT VTABLE SYMBOLS HERE make/bsd/makefiles/mapfile-vers-product: # INSERT VTABLE SYMBOLS HERE make/linux/makefiles/mapfile-vers-debug: # INSERT VTABLE SYMBOLS HERE make/linux/makefiles/mapfile-vers-product: # INSERT VTABLE SYMBOLS HERE make/solaris/makefiles/mapfile-vers: # INSERT VTABLE SYMBOLS HERE and there's logic in the non-Windows Makfiles: $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/*.make make/bsd/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS HERE") \ make/linux/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS HERE") \ make/solaris/makefiles/vm.make: if ($$0 ~ "INSERT VTABLE SYMBOLS HERE") { \ and they show up in the mapfile generated during the build: $ grep -c _vtbl_ solaris_amd64_compiler2/*/mapfilesolaris_amd64_compiler2/fastdebug/mapfile:3682 solaris_amd64_compiler2/product/mapfile:2596 $ grep _vtbl_ solaris_amd64_compiler2/product/mapfile | head -5 __1cCIfG__vtbl_; __1cCosTSuspendedThreadTaskG__vtbl_; __1cDOp2G__vtbl_; __1cDPhiG__vtbl_; __1cDSetG__vtbl_; Dan > > /Staffan > > On 17 feb 2014, at 09:18, Dmitry Samersoff wrote: > >> Staffan, >> >> I'd dived into this problem last week. >> >> SA uses address of vtable (_ZTV* symbols) to calculate base addresses >> for couple of internal structures. >> >> i.e. (roughly) it takes vtable address, add offset from vm_structs and >> get the data. >> >> Since the time when hotspot build switched to gcc 4.x it doesn't work, >> so many of SA command (e.g. jdis) is broken now. >> >> I'm looking for solution. >> >> see >> https://bugs.openjdk.java.net/browse/JDK-8034065 >> >> -Dmitry >> >> >> On 2014-02-17 11:50, Staffan Larsen wrote: >>> On 17 feb 2014, at 03:15, David Holmes wrote: >>> >>>> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >>>>> On 2014-02-05 19:09, Volker Simonis wrote: >>>>>> If there are any more/other comments on this topic I'll be highly >>>>>> interested. >>>>> You can count on me having lots of opinion on build issues. ;-) >>>>> >>>>> I'd like to get rid of the hard-coded map files completely, both in >>>>> hotspot and jdk. This can be done without loss of functionality. How? >>>>> Because we can generate them on the fly at build time, using information >>>>> provided by the source code. >>>> Does that account for the dynamically generated symbols used by the SA? >>> I think the symbols SA care about are all already declared with JNIEXPORT. >>> >>> /Staffan >>> >>>> David >>>> >>>>> Note that the exported functions are prefixed by the macro JNIEXPORT. We >>>>> can locate all functions that have this prefix and write them to a map >>>>> file. This can be done, and was indeed the way we solved things back in >>>>> the JRockit JVM. The technique we used there was to grep for "JNIEXPORT" >>>>> and check for a symbol name (as provided by nm). We had rules requiring >>>>> that JNIEXPORT was to be written on the same line as the function name, >>>>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >>>>> and then cross-reference for names extracted by nm. Not exactly a formal >>>>> semantic parsing, but it was efficient and worked very well. I believe >>>>> we can do something very similar for hotspot and jdk. >>>>> >>>>> Then again, if we could get rid of maps completely, by using visibility >>>>> and not linking statically with the standard libs, that would be even >>>>> better. :-) >>>>> >>>>> /Magnus >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Feb 17 07:08:32 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 17 Feb 2014 19:08:32 +0400 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <53021C25.10106@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> Message-ID: <530225F0.1040905@oracle.com> Dan, It was my bad - missed two related threads. We have two problems related to map files: 1. We have hand-written mapfiles and have to manage it manually. It's better to generate map file automatically or use visibility attributes. 2. Since gcc 4.3.x vtable symbols _ZVT* is not exported ever if they explicitly appears in map file. It brakes large part of SA functionality. -Dmitry On 2014-02-17 18:26, Daniel D. Daugherty wrote: > On 2/17/14 3:08 AM, Staffan Larsen wrote: >> Good that you are looking at it. >> >> My comment was on map-files. The static map files we have today aren?t >> involved with creating vtable symbols. > > Perhaps I'm misunderstanding what you mean here. I agree that the > map-files do not create the vtable symbols, but they are involved > with exporting vtable symols. > > There's a hook in the non-windows mapfiles: > > $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/map* > make/bsd/makefiles/mapfile-vers-darwin-debug: # INSERT > VTABLE SYMBOLS HERE > make/bsd/makefiles/mapfile-vers-darwin-product: # INSERT > VTABLE SYMBOLS HERE > make/bsd/makefiles/mapfile-vers-debug: # INSERT VTABLE SYMBOLS > HERE > make/bsd/makefiles/mapfile-vers-product: # INSERT VTABLE > SYMBOLS HERE > make/linux/makefiles/mapfile-vers-debug: # INSERT VTABLE > SYMBOLS HERE > make/linux/makefiles/mapfile-vers-product: # INSERT VTABLE > SYMBOLS HERE > make/solaris/makefiles/mapfile-vers: # INSERT VTABLE > SYMBOLS HERE > > and there's logic in the non-Windows Makfiles: > > $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/*.make > make/bsd/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS > HERE") \ > make/linux/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS > HERE") \ > make/solaris/makefiles/vm.make: if ($$0 ~ "INSERT VTABLE > SYMBOLS HERE") { \ > > and they show up in the mapfile generated during the build: > > $ grep -c _vtbl_ > solaris_amd64_compiler2/*/mapfilesolaris_amd64_compiler2/fastdebug/mapfile:3682 > > solaris_amd64_compiler2/product/mapfile:2596 > > $ grep _vtbl_ solaris_amd64_compiler2/product/mapfile | head -5 > __1cCIfG__vtbl_; > __1cCosTSuspendedThreadTaskG__vtbl_; > __1cDOp2G__vtbl_; > __1cDPhiG__vtbl_; > __1cDSetG__vtbl_; > > Dan > >> >> /Staffan >> >> On 17 feb 2014, at 09:18, Dmitry Samersoff >> wrote: >> >>> Staffan, >>> >>> I'd dived into this problem last week. >>> >>> SA uses address of vtable (_ZTV* symbols) to calculate base addresses >>> for couple of internal structures. >>> >>> i.e. (roughly) it takes vtable address, add offset from vm_structs and >>> get the data. >>> >>> Since the time when hotspot build switched to gcc 4.x it doesn't work, >>> so many of SA command (e.g. jdis) is broken now. >>> >>> I'm looking for solution. >>> >>> see >>> https://bugs.openjdk.java.net/browse/JDK-8034065 >>> >>> -Dmitry >>> >>> >>> On 2014-02-17 11:50, Staffan Larsen wrote: >>>> On 17 feb 2014, at 03:15, David Holmes wrote: >>>> >>>>> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >>>>>> On 2014-02-05 19:09, Volker Simonis wrote: >>>>>>> If there are any more/other comments on this topic I'll be highly >>>>>>> interested. >>>>>> You can count on me having lots of opinion on build issues. ;-) >>>>>> >>>>>> I'd like to get rid of the hard-coded map files completely, both in >>>>>> hotspot and jdk. This can be done without loss of functionality. How? >>>>>> Because we can generate them on the fly at build time, using >>>>>> information >>>>>> provided by the source code. >>>>> Does that account for the dynamically generated symbols used by the >>>>> SA? >>>> I think the symbols SA care about are all already declared with >>>> JNIEXPORT. >>>> >>>> /Staffan >>>> >>>>> David >>>>> >>>>>> Note that the exported functions are prefixed by the macro >>>>>> JNIEXPORT. We >>>>>> can locate all functions that have this prefix and write them to a >>>>>> map >>>>>> file. This can be done, and was indeed the way we solved things >>>>>> back in >>>>>> the JRockit JVM. The technique we used there was to grep for >>>>>> "JNIEXPORT" >>>>>> and check for a symbol name (as provided by nm). We had rules >>>>>> requiring >>>>>> that JNIEXPORT was to be written on the same line as the function >>>>>> name, >>>>>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >>>>>> and then cross-reference for names extracted by nm. Not exactly a >>>>>> formal >>>>>> semantic parsing, but it was efficient and worked very well. I >>>>>> believe >>>>>> we can do something very similar for hotspot and jdk. >>>>>> >>>>>> Then again, if we could get rid of maps completely, by using >>>>>> visibility >>>>>> and not linking statically with the standard libs, that would be even >>>>>> better. :-) >>>>>> >>>>>> /Magnus >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From volker.simonis at gmail.com Mon Feb 17 08:39:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 17 Feb 2014 17:39:46 +0100 Subject: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default"))) In-Reply-To: <530225F0.1040905@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> Message-ID: On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff wrote: > Dan, > > It was my bad - missed two related threads. > > We have two problems related to map files: > > 1. We have hand-written mapfiles and have to manage it manually. > > It's better to generate map file automatically or use visibility attributes. I would strongly vote against automatically generating the map files from sources by parsing for special patterns as proposed by Magnus because I think this will just introduce another level of complexity and another point of failure. >From this discussion so far I learned the following: - as long as Oracle insists on static linking libstdc++ and libgcc there's no way of getting rid of the map files. - using -fvisibility=hidden/__attribute__((visibility("default"))) is still desirable because it has positive performance impacts on some platforms and because it is the easiest and cleanest solution for the future when we can finally get rid of the map files. Moreover it is already used anyway. - the export of vtable-symbols doesn't seem to be possible with the help of a map-file any more with gcc 4.3 and newer. Taking this three points into account, I'd propose the following for HotSpot/libjvm.so - use a simple map file which exorts the following patterns: SUNWprivate_1.1 { global: # JNI JNI_*; # JVM JVM_*; local: *; }; - This would be easy to maintain (i.e. no need to adjust the map file if new JVM_/JNI_ methods are added or removed) and it would cleanly work together with -fvisibility=hidden/__attribute__((visibility("default"))). Once we stop with static linking, we could just drop it. - This solution would also establish something like a very low level contract that the VM will only ever export JVM_*/JNI_* symbols. Currently, the following symbols which don't start with JNI_ and JVM_ and are exported by the hotspot/make/linux/makefiles/mapfile-vers-product map file from libjvm.so on Linux: # miscellaneous functions jio_fprintf; jio_snprintf; jio_vfprintf; jio_vsnprintf; - exported and used in the jdk/ (trough jdk/src/share/javavm/export/jvm.h) - could be easily renamed to JVM_* jio_printf; - exported but not used in the jdk/ at all. fork1; - exported but not used on Linux in the jdk/ - should be deleted from os_linux.cpp as well as from the map file numa_warn; numa_error; - empty functions exported but not used at all in the jdk/ - should be deleted from os_linux.cpp as well as from the map file # Needed because there is no JVM interface for this. sysThreadAvailableStackWithSlack; - only defined for Solaris but exported on Linux and not used at all in the jdk/ - should be deleted from os_solaris.cpp as well as from the map file # This is for Forte Analyzer profiling support. AsyncGetCallTrace; - not sure if this is still used but I think it could be easily renamed to something like JVM_AsyncGetCallTrace As you can see, we could easily get rid of most of them and appropriately rename the others. 'sysThreadAvailableStackWithSlack()' for example is an extreme example of how the map-file (but also the source code) rots over time. It was initially added for JDK 1.2.2/1.3.0 (back in 2000 - man was I young and cool by then:), see http://bugs.java.com/view_bug.do?bug_id=4341971) and it isn't needed any more. Nevertheless it survived in os_solaris.cpp and in the map-files on all Unix platforms. For the shared libraries in the jdk/ repository, the situation is a little different. Only the following three libraries do statically link libstdc++/libgcc: libfontmanager.so libunpack.so libsunec.so I'd therefore propose to remove the map files for all the other shared libraries and solely use -fvisibility=hidden/__attribute__((visibility("default"))) to control the amount of exported symbols. Again, once static linking is gone, we can then remove the map files for the three remaining libraries. And by the way, I think now would be a real good point in time, to START THINKING ABOUT FINALLY GETTING RID OF STATICALLY LINKING libstdc++/libgcc FOR JDK9 - what do you think? Regards, Volker > > 2. Since gcc 4.3.x vtable symbols _ZVT* is not exported ever if they > explicitly appears in map file. > > It brakes large part of SA functionality. > > -Dmitry > > > On 2014-02-17 18:26, Daniel D. Daugherty wrote: >> On 2/17/14 3:08 AM, Staffan Larsen wrote: >>> Good that you are looking at it. >>> >>> My comment was on map-files. The static map files we have today aren?t >>> involved with creating vtable symbols. >> >> Perhaps I'm misunderstanding what you mean here. I agree that the >> map-files do not create the vtable symbols, but they are involved >> with exporting vtable symols. >> >> There's a hook in the non-windows mapfiles: >> >> $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/map* >> make/bsd/makefiles/mapfile-vers-darwin-debug: # INSERT >> VTABLE SYMBOLS HERE >> make/bsd/makefiles/mapfile-vers-darwin-product: # INSERT >> VTABLE SYMBOLS HERE >> make/bsd/makefiles/mapfile-vers-debug: # INSERT VTABLE SYMBOLS >> HERE >> make/bsd/makefiles/mapfile-vers-product: # INSERT VTABLE >> SYMBOLS HERE >> make/linux/makefiles/mapfile-vers-debug: # INSERT VTABLE >> SYMBOLS HERE >> make/linux/makefiles/mapfile-vers-product: # INSERT VTABLE >> SYMBOLS HERE >> make/solaris/makefiles/mapfile-vers: # INSERT VTABLE >> SYMBOLS HERE >> >> and there's logic in the non-Windows Makfiles: >> >> $ grep 'INSERT VTABLE SYMBOLS HERE' make/*/makefiles/*.make >> make/bsd/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS >> HERE") \ >> make/linux/makefiles/vm.make: awk '{ if ($$0 ~ "INSERT VTABLE SYMBOLS >> HERE") \ >> make/solaris/makefiles/vm.make: if ($$0 ~ "INSERT VTABLE >> SYMBOLS HERE") { \ >> >> and they show up in the mapfile generated during the build: >> >> $ grep -c _vtbl_ >> solaris_amd64_compiler2/*/mapfilesolaris_amd64_compiler2/fastdebug/mapfile:3682 >> >> solaris_amd64_compiler2/product/mapfile:2596 >> >> $ grep _vtbl_ solaris_amd64_compiler2/product/mapfile | head -5 >> __1cCIfG__vtbl_; >> __1cCosTSuspendedThreadTaskG__vtbl_; >> __1cDOp2G__vtbl_; >> __1cDPhiG__vtbl_; >> __1cDSetG__vtbl_; >> >> Dan >> >>> >>> /Staffan >>> >>> On 17 feb 2014, at 09:18, Dmitry Samersoff >>> wrote: >>> >>>> Staffan, >>>> >>>> I'd dived into this problem last week. >>>> >>>> SA uses address of vtable (_ZTV* symbols) to calculate base addresses >>>> for couple of internal structures. >>>> >>>> i.e. (roughly) it takes vtable address, add offset from vm_structs and >>>> get the data. >>>> >>>> Since the time when hotspot build switched to gcc 4.x it doesn't work, >>>> so many of SA command (e.g. jdis) is broken now. >>>> >>>> I'm looking for solution. >>>> >>>> see >>>> https://bugs.openjdk.java.net/browse/JDK-8034065 >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-02-17 11:50, Staffan Larsen wrote: >>>>> On 17 feb 2014, at 03:15, David Holmes wrote: >>>>> >>>>>> On 13/02/2014 5:26 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2014-02-05 19:09, Volker Simonis wrote: >>>>>>>> If there are any more/other comments on this topic I'll be highly >>>>>>>> interested. >>>>>>> You can count on me having lots of opinion on build issues. ;-) >>>>>>> >>>>>>> I'd like to get rid of the hard-coded map files completely, both in >>>>>>> hotspot and jdk. This can be done without loss of functionality. How? >>>>>>> Because we can generate them on the fly at build time, using >>>>>>> information >>>>>>> provided by the source code. >>>>>> Does that account for the dynamically generated symbols used by the >>>>>> SA? >>>>> I think the symbols SA care about are all already declared with >>>>> JNIEXPORT. >>>>> >>>>> /Staffan >>>>> >>>>>> David >>>>>> >>>>>>> Note that the exported functions are prefixed by the macro >>>>>>> JNIEXPORT. We >>>>>>> can locate all functions that have this prefix and write them to a >>>>>>> map >>>>>>> file. This can be done, and was indeed the way we solved things >>>>>>> back in >>>>>>> the JRockit JVM. The technique we used there was to grep for >>>>>>> "JNIEXPORT" >>>>>>> and check for a symbol name (as provided by nm). We had rules >>>>>>> requiring >>>>>>> that JNIEXPORT was to be written on the same line as the function >>>>>>> name, >>>>>>> or the line before that. So we could do like "grep -A 1 -e JNIEXPORT" >>>>>>> and then cross-reference for names extracted by nm. Not exactly a >>>>>>> formal >>>>>>> semantic parsing, but it was efficient and worked very well. I >>>>>>> believe >>>>>>> we can do something very similar for hotspot and jdk. >>>>>>> >>>>>>> Then again, if we could get rid of maps completely, by using >>>>>>> visibility >>>>>>> and not linking statically with the standard libs, that would be even >>>>>>> better. :-) >>>>>>> >>>>>>> /Magnus >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From mattis.castegren at oracle.com Mon Feb 17 09:25:23 2014 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Mon, 17 Feb 2014 09:25:23 -0800 (PST) Subject: Project to improve hs_err files In-Reply-To: <88AE7720-7874-4021-9671-63D1DDDF6D71@oracle.com> References: <88AE7720-7874-4021-9671-63D1DDDF6D71@oracle.com> Message-ID: Hi Thanks for the comments on this thread lately. I have added all comments to my tracking page, and I have filed bugs for the new suggestions. Now that JDK8 is all but done, I would like to get this project moving again. However, before I ask someone in my team to start working on these bugs, I would like to make one last round on the mailing list to see if anyone have a strong opinion against any of the feature requests (all labeled with hs_err_improvements): https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20hs_err_improvements%20and%20resolution%20is%20empty I expect there to be some discussions about the robustness of the implementation, but that can be handled in the code reviews. What I want to know is if anyone have any larger objections that we should sort out before we even start implementation. The biggest change is https://bugs.openjdk.java.net/browse/JDK-8026324 - Add summary section to hs_err file Overall, the feedback I have got on this feature has been positive, but the last time I asked everyone was busy with JKD8 Zero Bug Bounce, so I thought it best to ask one last time. We plan to start working on this sometime next week Kind Regards /Mattis PS: Still gathering suggestions, so send them if you have them. -----Original Message----- From: John Rose Sent: den 12 februari 2014 20:15 To: Mattis Castegren Cc: hotspot-dev at openjdk.java.net Subject: Re: Project to improve hs_err files The hs_err file has grown to include lots of handy information. I agree that it would be reasonable to add more, and I'm really glad that you are thinking about it in this level of detail. This is especially good as you are an experienced consumer of these files. The typical size of such a file is currently about 40kb. As long as the most useful information is kept near the top, there is (IMO) room for this file to grow 2x or more in typical size. Some of the configuration information you mention may be present at the top of the hotspot.log file, before the big element. It might be fruitful to ensure that such preamble information is always captured at startup, and dumped into the log file. I don't think dump-time disassembly is practical, since we don't have an engine bundled in the JVM, but we should make it possible with post-processing to get a good disassembly from hex dumps in the error dump file. This has been done before; perhaps it needs reviving or refinement. Here's another thought, along the lines of symbolic disassembly, but for data rather than code: One thing I would like to see more of is memory contents, along with a way to interpret their meaning. The memory blocks around current PC and SP is supplied. It might be worth while dumping additional memory blocks one or two indirections away from the (apparent) pointers in those initial memory blocks. I often wonder, "is that the object I care about?" when looking at those memory dumps. I am guessing that there is a cheap, robust way to put more clues into the dump, without getting entangled in object parsing (which as David points out could cause further crashing). Perhaps there is a way to classify data words in a post-processing tool, like we can pull out disassembled code. At least, we can observe whether an apparent point refers into a live part of the heap (assuming we have the right few words of heap boundary info). We could also (maybe) identify Klass pointers in the headers of objects and output a little bit of data in the crash log to make it possible to identify the (apparent) classes of (apparent) object pointers in the regions dumped. At least the values of well-known classes (in SystemDictionary::_something), if they occur as the (apparent) classes of hex dump addresses, could be supplied as an extra hint. Clearly this could scale beyond the reasonable size of a crash dump, so some sort of size limit would need to be applied. (The size limit could be set to zero, or the log file section removed, if customers are nervous about memory dumps.) I think there is scope for tasteful engineering here, especially if we push fancy formatting work into a post-pass tool. Perhaps there is a way to join hands with the SA (serviceability agent) infrastructure, and run a tiny SA instance out of a relatively limited supply of hex dump from the crash file, instead of out of the full picture supplied by the core file or a live process. It's at least an interesting thought experiment. Please keep up this good work! - John On Sep 9, 2013, at 10:38 AM, Mattis Castegren wrote: > Hi. I sent this email to serviceability and runtime, but I got a request to forward the mail to all of hotspot dev as hs_err files affects all areas. Please let me know if you have any feedback. Don't worry about if the suggestions are feasible or not, that will come in a second step. From coleen.phillimore at oracle.com Mon Feb 17 10:11:45 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 17 Feb 2014 13:11:45 -0500 Subject: Result: New jdk9 Committer: Lois Foltan In-Reply-To: <52F26461.9010202@oracle.com> References: <52F26461.9010202@oracle.com> Message-ID: <530250E1.1020303@oracle.com> On 2/5/14 11:18 AM, Coleen Phillimore wrote: > Voting for Lois Foltan [1] is now closed. > > Yes: 25 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > Coleen Phillimore > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-January/000290.html > Trying hotspot-dev mailing list too in case I did this wrong. Coleen From alejandro.murillo at oracle.com Mon Feb 17 11:19:55 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 17 Feb 2014 12:19:55 -0700 Subject: [7u60] RFR 8024648 : 8016131 breaks Zero port In-Reply-To: <53017805.80903@oracle.com> References: <1207859431.5687349.1391721689333.JavaMail.root@redhat.com> <52F406B1.70300@oracle.com> <52F4084D.9060605@oracle.com> <52F46BA9.3060204@oracle.com> <52F48CEF.4000806@oracle.com> <1394667851.3418706.1392353222180.JavaMail.zimbra@redhat.com> <52FDBD13.2070307@oracle.com> <52FDC19B.2080004@oracle.com> <52FE4F7A.8000900@oracle.com> <53017805.80903@oracle.com> Message-ID: <530260DB.1050306@oracle.com> On 2/16/2014 7:46 PM, David Holmes wrote: > On 15/02/2014 3:16 AM, Alejandro E Murillo wrote: >> >> On 2/14/2014 12:11 AM, David Holmes wrote: >>> On 14/02/2014 4:52 PM, Alejandro E Murillo wrote: >>>> >>>> On 2/13/2014 9:47 PM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> To expand on a solution for this ... >>>>>> >>>>>> Note that in vm.make and gcc.make the only uses of the JVM_VARIANT >>>>>> variables relates to ZERO and ZEROSHARK. That is the real problem >>>>>> in my >>>>>> view (it was natural to use them as they were very prominent). >>>>>> >>>>>> Looking through the build process it seems to me that in the >>>>>> generated >>>>>> flags.make we will have: >>>>>> >>>>>> include zero|shark.make >>>>>> include gcc.make >>>>>> >>>>>> And in zero|shark.make we have TYPE=ZERO or TYPE=SHARK. So TYPE >>>>>> can be >>>>>> used in gcc.make instead of the JVM_VARIANT_* variable. (BUILDARCH >>>>>> will >>>>>> also be zero but that doesn't help with shark.) >>>>>> >>>>>> Aside: note that here zero or shark is the VARIANT but that isn't >>>>>> exposed in the generated makefiles as the VARIANT is already >>>>>> implicit in >>>>>> the path to which the file was generated eg >>>>>> hotspot/__/product >>>>>> >>>>>> Similarly the generated vm.make will include flags.make before the >>>>>> repo >>>>>> version of vm.make so it too can use TYPE to identify ZERO or SHARK. >>>>>> >>>>>> If I knew how to build zero/shark I'd test this out. :( >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>> This is a revised webrev using $(TYPE) in gcc.make and vm.make >>>>> instead: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/jdk7u/8024648/webrev.02/ >>>>> >>>>> The BSD changes mirror the GNU/Linux ones, as in the 7141426 change >>>>> which broke the build, but I've no means to test on that platform. >>>> I'll submit a couple of jprt jobs with these changes >>> >>> I read that as meaning Andrew couldn't do a zero BSD build. >> Right. so doesn't make sense then to do further testing if that hasn't >> been verified, > > I think it makes sense to test on all the regular platforms while > waiting to see if Andrew can find someone (or someone reading this > volunteers) who can do a Zero build on BSD. ( Unfortunately I couldn't > even get a basic linux zero build to work :( ). Visually the changes > are identical to the linux ones so I see no reason to expect they > would not work. > > That said this change has very low risk attached to it now. The change > to buildtree.make is one that we already use in JDK 8. The other > changes are zero/shark specific. sound good, I will proceed with the jprt testing then thanks Alejandro > > David > ----- > >> Andrew, let me know when that's verified and I can run some additional >> tests with jprt >> >> Thanks >> Alejandro >>> >>> Andrew: thanks for doing this. The functional changes to the build >>> files etc look fine to me. >>> >>> However I don't know about the additional copyrights that were added. >>> I can't see anything in the OpenJDK rules/charter/legal, or the OCA, >>> that addresses this. >>> >>> Thanks, >>> David >>> >>>> thanks >>>> >> -- Alejandro From vladimir.kozlov at oracle.com Mon Feb 17 11:34:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Feb 2014 11:34:30 -0800 Subject: assertion in ciTypeFlow OSR'ing in finally clause In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> Message-ID: <53026446.4030000@oracle.com> Hi Goetz, Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case which I see for the first time. But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? Regards, Vladimir On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: > Hi, > > I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. > > It tries to osr-compile a method at a bytecode in a finally clause. > > As far as I understand the assertion is too strict. > > The initial assertion is > > # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, > tid=4398488891968 > > # assert(return_address->is_return_address()) failed: verify: wrong type > > This happens because a block in the finally clause is analyzed while not > > both predecessor blocks have been looked at. Thus the join of the > > slots that should contain the return address yields bottom, and the assertion > > fires. > > To get the dbg build passing, I have to remove 5 assertions: > > ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); > > ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); > > ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); > > ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); > > ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); > > If I remove these, compilation is aborted a bit later with the message: > > ?COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)? > > I wonder whether I should fix this by adapting the assertions, or > > whether I should abort the compilation right away. > > I would appreciate some comments on this issue! > > Best regards, > > Goetz. > From igor.veresov at oracle.com Mon Feb 17 19:26:35 2014 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 18 Feb 2014 03:26:35 +0000 Subject: hg: hsx/jdk7u/hotspot: 3 new changesets Message-ID: <20140218032642.6315762CEF@hg.openjdk.java.net> Changeset: d159f9d85a18 Author: iveresov Date: 2014-01-17 18:09 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/d159f9d85a18 8032207: C2: assert(VerifyOops || MachNode::size(ra_) <= (3+1)*4) failed: bad fixed size Summary: Fix the sizing of loadUS2L_immI16 and loadI2L_immI Reviewed-by: kvn, azeemj ! src/cpu/sparc/vm/sparc.ad + test/compiler/codegen/LoadWithMask.java Changeset: 179c1940854f Author: iveresov Date: 2014-01-21 20:05 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/179c1940854f 8031743: C2: loadI2L_immI broken for negative memory values Summary: Restrict loadI2L_imm optimizations to positive values of mask Reviewed-by: kvn, dlong ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad + test/compiler/codegen/LoadWithMask2.java Changeset: b69db305483d Author: iveresov Date: 2014-02-17 17:48 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/b69db305483d Merge From poonam.bajaj at oracle.com Mon Feb 17 20:42:47 2014 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Tue, 18 Feb 2014 04:42:47 +0000 Subject: hg: hsx/jdk7u/hotspot: 2 new changesets Message-ID: <20140218044252.E9D9F62CF0@hg.openjdk.java.net> Changeset: 119d8702550e Author: poonam Date: 2014-02-17 18:14 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/119d8702550e 6412968: CMS: Long initial mark pauses 6990419: CMS: Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Summary: Backport of fixes for 6412968 and 6990419 Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 2efefc495ae0 Author: poonam Date: 2014-02-17 19:28 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/2efefc495ae0 Merge From david.holmes at oracle.com Mon Feb 17 20:44:44 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Feb 2014 14:44:44 +1000 Subject: Project to improve hs_err files In-Reply-To: References: <88AE7720-7874-4021-9671-63D1DDDF6D71@oracle.com> Message-ID: <5302E53C.6020306@oracle.com> Hi Mattis, As I wrote in 8035084 re gathering register info on assert/guarantee failures: "It is not at all clear to me that this is needed or even that useful. When an assert or guarantee fails you know exactly why. If you need to then go and examine other state then a core dump is the best. Anything you do to try and capture the register information will modify some of the registers - and that could be more confusing than not having any register information. It may also be that the interesting register values have already been overwritten by the time the assert/guarantee actually fires. What you really want is the state of the registers _before_ the assert/guarantee is evaluated." Cheers, David On 18/02/2014 3:25 AM, Mattis Castegren wrote: > Hi > > Thanks for the comments on this thread lately. I have added all comments to my tracking page, and I have filed bugs for the new suggestions. > > Now that JDK8 is all but done, I would like to get this project moving again. However, before I ask someone in my team to start working on these bugs, I would like to make one last round on the mailing list to see if anyone have a strong opinion against any of the feature requests (all labeled with hs_err_improvements): > > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20hs_err_improvements%20and%20resolution%20is%20empty > > I expect there to be some discussions about the robustness of the implementation, but that can be handled in the code reviews. What I want to know is if anyone have any larger objections that we should sort out before we even start implementation. > > The biggest change is https://bugs.openjdk.java.net/browse/JDK-8026324 - Add summary section to hs_err file > > Overall, the feedback I have got on this feature has been positive, but the last time I asked everyone was busy with JKD8 Zero Bug Bounce, so I thought it best to ask one last time. > > We plan to start working on this sometime next week > > Kind Regards > /Mattis > > PS: Still gathering suggestions, so send them if you have them. > > > -----Original Message----- > From: John Rose > Sent: den 12 februari 2014 20:15 > To: Mattis Castegren > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Project to improve hs_err files > > The hs_err file has grown to include lots of handy information. I agree that it would be reasonable to add more, and I'm really glad that you are thinking about it in this level of detail. This is especially good as you are an experienced consumer of these files. > > The typical size of such a file is currently about 40kb. As long as the most useful information is kept near the top, there is (IMO) room for this file to grow 2x or more in typical size. > > Some of the configuration information you mention may be present at the top of the hotspot.log file, before the big element. It might be fruitful to ensure that such preamble information is always captured at startup, and dumped into the log file. > > I don't think dump-time disassembly is practical, since we don't have an engine bundled in the JVM, but we should make it possible with post-processing to get a good disassembly from hex dumps in the error dump file. This has been done before; perhaps it needs reviving or refinement. > > Here's another thought, along the lines of symbolic disassembly, but for data rather than code: > > One thing I would like to see more of is memory contents, along with a way to interpret their meaning. The memory blocks around current PC and SP is supplied. It might be worth while dumping additional memory blocks one or two indirections away from the (apparent) pointers in those initial memory blocks. I often wonder, "is that the object I care about?" when looking at those memory dumps. I am guessing that there is a cheap, robust way to put more clues into the dump, without getting entangled in object parsing (which as David points out could cause further crashing). Perhaps there is a way to classify data words in a post-processing tool, like we can pull out disassembled code. At least, we can observe whether an apparent point refers into a live part of the heap (assuming we have the right few words of heap boundary info). > > We could also (maybe) identify Klass pointers in the headers of objects and output a little bit of data in the crash log to make it possible to identify the (apparent) classes of (apparent) object pointers in the regions dumped. At least the values of well-known classes (in SystemDictionary::_something), if they occur as the (apparent) classes of hex dump addresses, could be supplied as an extra hint. Clearly this could scale beyond the reasonable size of a crash dump, so some sort of size limit would need to be applied. (The size limit could be set to zero, or the log file section removed, if customers are nervous about memory dumps.) I think there is scope for tasteful engineering here, especially if we push fancy formatting work into a post-pass tool. > > Perhaps there is a way to join hands with the SA (serviceability agent) infrastructure, and run a tiny SA instance out of a relatively limited supply of hex dump from the crash file, instead of out of the full picture supplied by the core file or a live process. It's at least an interesting thought experiment. > > Please keep up this good work! > > - John > > On Sep 9, 2013, at 10:38 AM, Mattis Castegren wrote: > >> Hi. I sent this email to serviceability and runtime, but I got a request to forward the mail to all of hotspot dev as hs_err files affects all areas. Please let me know if you have any feedback. Don't worry about if the suggestions are feasible or not, that will come in a second step. > From david.holmes at oracle.com Mon Feb 17 21:02:29 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Feb 2014 15:02:29 +1000 Subject: RFR (S) 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: <52FD5CC3.4090502@oracle.com> References: <52FD5CC3.4090502@oracle.com> Message-ID: <5302E965.3090505@oracle.com> Hi Serguei, This looks good to me. I wonder if we will reach a point where we can delete is_thread_fully_suspended? ;-) David On 14/02/2014 10:01 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8034249 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1 > > > Summary: > > This issue was identified in the review of the 8032223 and it is > similar to the 8032223 > but impacts different JVMTI functions: > GetCurrentContendedMonitor, GetOwnedMonitorInfo, > GetOwnedMonitorStackDepthInfo, GetStackTrace > > There is a general issue in the suspend equivalent condition mechanism: > Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may > return different results: > - 1-st: true > - 2-nd: false > > This suspend equivalent issue is covered by another bug: > https://bugs.openjdk.java.net/browse/JDK-6280037 > > This fix is to work around the 6280037. > It is more safe to collect the necesary information at a safepoint > instead of > relying on the suspension of the target thread. > > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Mon Feb 17 21:33:08 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 17 Feb 2014 21:33:08 -0800 Subject: RFR (S) 8034249: need more workarounds for suspend equivalent condition issue In-Reply-To: <5302E965.3090505@oracle.com> References: <52FD5CC3.4090502@oracle.com> <5302E965.3090505@oracle.com> Message-ID: <5302F094.7090006@oracle.com> Thank you a lot, David! On 2/17/14 9:02 PM, David Holmes wrote: > Hi Serguei, > > This looks good to me. > > I wonder if we will reach a point where we can delete > is_thread_fully_suspended? ;-) I know what you mean by this. :) There are still some space to improve safety with the safepoint mechanizm. Of course, the is_thread_fully_suspended() is still needed for external JVMTI/JDI purposes. Thanks, Serguei > > David > > On 14/02/2014 10:01 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8034249 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8034249-JVMTI-MON.1 >> >> >> >> Summary: >> >> This issue was identified in the review of the 8032223 and it is >> similar to the 8032223 >> but impacts different JVMTI functions: >> GetCurrentContendedMonitor, GetOwnedMonitorInfo, >> GetOwnedMonitorStackDepthInfo, GetStackTrace >> >> There is a general issue in the suspend equivalent condition >> mechanism: >> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended() may >> return different results: >> - 1-st: true >> - 2-nd: false >> >> This suspend equivalent issue is covered by another bug: >> https://bugs.openjdk.java.net/browse/JDK-6280037 >> >> This fix is to work around the 6280037. >> It is more safe to collect the necesary information at a safepoint >> instead of >> relying on the suspension of the target thread. >> >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei From staffan.larsen at oracle.com Mon Feb 17 23:40:02 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 18 Feb 2014 08:40:02 +0100 Subject: RFR(M): 8034080 Remove the USDT1 dtrace code from Hotspot In-Reply-To: <53021A34.7000906@oracle.com> References: <5BD4A849-C93C-4455-B627-0C941AA552DC@oracle.com> <5301697B.9040307@oracle.com> <530214F3.6080803@oracle.com> <53021A34.7000906@oracle.com> Message-ID: Coleen, David: Thanks! On 17 feb 2014, at 15:18, Coleen Phillimore wrote: > > Ship it + 1. thank you for doing this change! > Coleen > > On 2/17/14 8:56 AM, David Holmes wrote: >> Ship it! :) >> >> David >> >> On 17/02/2014 5:38 PM, Staffan Larsen wrote: >>> >>> On 17 feb 2014, at 02:44, David Holmes wrote: >>> >>>> src/share/vm/prims/jni.cpp >>>> >>>> Indent is wrong here: >>>> >>>> JNI_ENTRY(jobject, jni_NewGlobalRef(JNIEnv *env, jobject ref)) >>>> JNIWrapper("NewGlobalRef"); >>>> ! >>>> ! HOTSPOT_JNI_NEWGLOBALREF_ENTRY(env, ref); >>>> ! >>> >>> Sharp eyes! Fixed. >>> >>>> Is it worth renaming src/share/vm/utilities/dtrace_usdt2_disabled.hpp to just src/share/vm/utilities/dtrace_disabled.hpp ? Or maybe even fold the content back into dtrace.hpp >>> >>> Good point. Given how large (and boring) it is I kept it as a separate file but renamed it. >>> >>>> Otherwise looks good to see this all get stripped out! >>> >>> Updated webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.01/ >>> >>> Thanks, >>> /Staffan >>> >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> On 11/02/2014 8:12 PM, Staffan Larsen wrote: >>>>> Now that both the Solaris (JDK-8030812) and the Linux (JDK-8032462) implementations have moved to USDT2, we can finally remove the USDT1 code from hotspot. >>>>> >>>>> There are quite a lot of changes in this review, and webrev barfed on the number of change in jni.cpp so that file can only be reviewed from the patch file. The good news is that the changes are mostly trivial removal of #ifdef:ed code. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8034080 >>>>> webrev: http://cr.openjdk.java.net/~sla/8034080/webrev.00/ >>>>> >>>>> Testing: I have run jck-runtime, vm.quick.testlist and vm.dtrace.testlist on Solaris and OS X. >>>>> >>>>> /Staffan >>>>> >>> > From staffan.larsen at oracle.com Tue Feb 18 02:04:14 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 18 Feb 2014 11:04:14 +0100 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: <5302016A.1020906@oracle.com> References: <5302016A.1020906@oracle.com> Message-ID: <6A4175A3-DAEC-42D2-99E6-42960B6122E1@oracle.com> Looks good! Thanks, /Staffan On 17 feb 2014, at 13:32, Sergei Kovalev wrote: > Hello everyone, > > I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. > > As it was discussed, I prepared fix for the issue: http://cr.openjdk.java.net/~anazarov/8022203/webrev.01/ > > The failure caused by slippage in IO operation due to file system performance. To avoid this situation we will use an unique file name for profiling dump. In this case we will have zero probability that tests would overlapped by output file. By default the file name for dump output builds from library name plus .java. prefix and .txt suffix. Hprof tool supports "file" option that used for providing the output file name. Therefore we can just add unique file name to options string for each individual tests that used hprof. > > Testing done: > - single run of tests > - Stability run of all modified tests > - Modified stability run. I did some test modification that helped me to increase reproducibility rating. It was 500-1000 iteration instead 10,000 in original case. Test with modified options string ran 10,000 iteration. > > Could you please approve fix? > > -- > With best regards, > Sergei > From goetz.lindenmaier at sap.com Tue Feb 18 08:22:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 18 Feb 2014 16:22:36 +0000 Subject: assertion in ciTypeFlow OSR'ing in finally clause In-Reply-To: <53026446.4030000@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> <53026446.4030000@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> Hi Vladimir, No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until running into the problem. I tried replay compilation, but I don't get that to work. Is there some docu on that? I don't think the visiting order is wrong, as the blocks are analyzed twice successfully. On a third try a block is marked 'irred' and has no info about the return address. This is the block with bytecodes 294-300. I dumped the trace of the analysis: http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt In this run, I removed all the assertions, so it runs until it aborts compilation. There is some debug output where the first assertion would fire, in line 10524 of the trace file. Local 4 is bottom, so the assertion fires in ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type") I think the assertion is just too strict if the control flow gets irreducible? But I didn't figure yet why it analyzes the block a third time with po #87. Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Monday, February 17, 2014 8:35 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause Hi Goetz, Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case which I see for the first time. But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? Regards, Vladimir On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: > Hi, > > I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. > > It tries to osr-compile a method at a bytecode in a finally clause. > > As far as I understand the assertion is too strict. > > The initial assertion is > > # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, > tid=4398488891968 > > # assert(return_address->is_return_address()) failed: verify: wrong type > > This happens because a block in the finally clause is analyzed while not > > both predecessor blocks have been looked at. Thus the join of the > > slots that should contain the return address yields bottom, and the assertion > > fires. > > To get the dbg build passing, I have to remove 5 assertions: > > ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); > > ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); > > ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); > > ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); > > ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); > > If I remove these, compilation is aborted a bit later with the message: > > "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" > > I wonder whether I should fix this by adapting the assertions, or > > whether I should abort the compilation right away. > > I would appreciate some comments on this issue! > > Best regards, > > Goetz. > From mattis.castegren at oracle.com Tue Feb 18 09:52:25 2014 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Tue, 18 Feb 2014 09:52:25 -0800 (PST) Subject: Project to improve hs_err files In-Reply-To: <5302E53C.6020306@oracle.com> References: <88AE7720-7874-4021-9671-63D1DDDF6D71@oracle.com> <5302E53C.6020306@oracle.com> Message-ID: <9143ce96-f881-4984-8e52-2f43fe478bda@default> Hi This request came in from the compiler team. Nils, I believe you brought it up, do you have any examples when getting register information from an assert would be useful? We rarely get bugs filed on debug builds in Sustaining, so I don't have much of an opinion here Kind Regards /Mattis -----Original Message----- From: David Holmes Sent: den 18 februari 2014 05:45 To: Mattis Castegren; hotspot-dev at openjdk.java.net Cc: David Buck; Roger Calnan Subject: Re: Project to improve hs_err files Hi Mattis, As I wrote in 8035084 re gathering register info on assert/guarantee failures: "It is not at all clear to me that this is needed or even that useful. When an assert or guarantee fails you know exactly why. If you need to then go and examine other state then a core dump is the best. Anything you do to try and capture the register information will modify some of the registers - and that could be more confusing than not having any register information. It may also be that the interesting register values have already been overwritten by the time the assert/guarantee actually fires. What you really want is the state of the registers _before_ the assert/guarantee is evaluated." Cheers, David On 18/02/2014 3:25 AM, Mattis Castegren wrote: > Hi > > Thanks for the comments on this thread lately. I have added all comments to my tracking page, and I have filed bugs for the new suggestions. > > Now that JDK8 is all but done, I would like to get this project moving again. However, before I ask someone in my team to start working on these bugs, I would like to make one last round on the mailing list to see if anyone have a strong opinion against any of the feature requests (all labeled with hs_err_improvements): > > https://bugs.openjdk.java.net/issues/?jql=labels%20%3D%20hs_err_improvements%20and%20resolution%20is%20empty > > I expect there to be some discussions about the robustness of the implementation, but that can be handled in the code reviews. What I want to know is if anyone have any larger objections that we should sort out before we even start implementation. > > The biggest change is https://bugs.openjdk.java.net/browse/JDK-8026324 - Add summary section to hs_err file > > Overall, the feedback I have got on this feature has been positive, but the last time I asked everyone was busy with JKD8 Zero Bug Bounce, so I thought it best to ask one last time. > > We plan to start working on this sometime next week > > Kind Regards > /Mattis > > PS: Still gathering suggestions, so send them if you have them. > > > -----Original Message----- > From: John Rose > Sent: den 12 februari 2014 20:15 > To: Mattis Castegren > Cc: hotspot-dev at openjdk.java.net > Subject: Re: Project to improve hs_err files > > The hs_err file has grown to include lots of handy information. I agree that it would be reasonable to add more, and I'm really glad that you are thinking about it in this level of detail. This is especially good as you are an experienced consumer of these files. > > The typical size of such a file is currently about 40kb. As long as the most useful information is kept near the top, there is (IMO) room for this file to grow 2x or more in typical size. > > Some of the configuration information you mention may be present at the top of the hotspot.log file, before the big element. It might be fruitful to ensure that such preamble information is always captured at startup, and dumped into the log file. > > I don't think dump-time disassembly is practical, since we don't have an engine bundled in the JVM, but we should make it possible with post-processing to get a good disassembly from hex dumps in the error dump file. This has been done before; perhaps it needs reviving or refinement. > > Here's another thought, along the lines of symbolic disassembly, but for data rather than code: > > One thing I would like to see more of is memory contents, along with a way to interpret their meaning. The memory blocks around current PC and SP is supplied. It might be worth while dumping additional memory blocks one or two indirections away from the (apparent) pointers in those initial memory blocks. I often wonder, "is that the object I care about?" when looking at those memory dumps. I am guessing that there is a cheap, robust way to put more clues into the dump, without getting entangled in object parsing (which as David points out could cause further crashing). Perhaps there is a way to classify data words in a post-processing tool, like we can pull out disassembled code. At least, we can observe whether an apparent point refers into a live part of the heap (assuming we have the right few words of heap boundary info). > > We could also (maybe) identify Klass pointers in the headers of objects and output a little bit of data in the crash log to make it possible to identify the (apparent) classes of (apparent) object pointers in the regions dumped. At least the values of well-known classes (in SystemDictionary::_something), if they occur as the (apparent) classes of hex dump addresses, could be supplied as an extra hint. Clearly this could scale beyond the reasonable size of a crash dump, so some sort of size limit would need to be applied. (The size limit could be set to zero, or the log file section removed, if customers are nervous about memory dumps.) I think there is scope for tasteful engineering here, especially if we push fancy formatting work into a post-pass tool. > > Perhaps there is a way to join hands with the SA (serviceability agent) infrastructure, and run a tiny SA instance out of a relatively limited supply of hex dump from the crash file, instead of out of the full picture supplied by the core file or a live process. It's at least an interesting thought experiment. > > Please keep up this good work! > > - John > > On Sep 9, 2013, at 10:38 AM, Mattis Castegren wrote: > >> Hi. I sent this email to serviceability and runtime, but I got a request to forward the mail to all of hotspot dev as hs_err files affects all areas. Please let me know if you have any feedback. Don't worry about if the suggestions are feasible or not, that will come in a second step. > From vladimir.kozlov at oracle.com Tue Feb 18 10:15:10 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 18 Feb 2014 10:15:10 -0800 Subject: assertion in ciTypeFlow OSR'ing in finally clause In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> <53026446.4030000@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> Message-ID: <5303A32E.1000208@oracle.com> On 2/18/14 8:22 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until > running into the problem. I tried replay compilation, but I don't get that to work. > Is there some docu on that? No docu, as usual :) You add next flags to your command line you used to run app and run with debug VM: -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid1234.log And it is better if you use latest sources from hs/hs-comp which also record/replay inlining. > > I don't think the visiting order is wrong, as the blocks are analyzed > twice successfully. On a third try a block is marked 'irred' and has > no info about the return address. This is the block with bytecodes 294-300. > I dumped the trace of the analysis: > http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt > In this run, I removed all the assertions, so it runs until it aborts compilation. > There is some debug output where the first assertion would fire, in line 10524 > of the trace file. Local 4 is bottom, so the assertion fires in > ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type") I will look on it later. > > I think the assertion is just too strict if the control flow gets irreducible? I would like to keep the assert. We need to get full understanding about what happened before we consider removing it. And we do handle irreducible code for long time already. thanks, Vladimir > But I didn't figure yet why it analyzes the block a third time with po #87. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, February 17, 2014 8:35 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net > Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause > > Hi Goetz, > > Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. > I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case > which I see for the first time. > But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? > > Regards, > Vladimir > > On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. >> >> It tries to osr-compile a method at a bytecode in a finally clause. >> >> As far as I understand the assertion is too strict. >> >> The initial assertion is >> >> # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, >> tid=4398488891968 >> >> # assert(return_address->is_return_address()) failed: verify: wrong type >> >> This happens because a block in the finally clause is analyzed while not >> >> both predecessor blocks have been looked at. Thus the join of the >> >> slots that should contain the return address yields bottom, and the assertion >> >> fires. >> >> To get the dbg build passing, I have to remove 5 assertions: >> >> ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); >> >> ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); >> >> ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); >> >> If I remove these, compilation is aborted a bit later with the message: >> >> "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" >> >> I wonder whether I should fix this by adapting the assertions, or >> >> whether I should abort the compilation right away. >> >> I would appreciate some comments on this issue! >> >> Best regards, >> >> Goetz. >> From magnus.ihse.bursie at oracle.com Wed Feb 19 01:22:09 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Feb 2014 10:22:09 +0100 Subject: Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))) In-Reply-To: References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> Message-ID: <530477C1.2010507@oracle.com> (Adding in build-dev since we're moving into the jdk build as well now.) On 2014-02-17 17:39, Volker Simonis wrote: > On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff > wrote: >> Dan, >> >> It was my bad - missed two related threads. >> >> We have two problems related to map files: >> >> 1. We have hand-written mapfiles and have to manage it manually. >> >> It's better to generate map file automatically or use visibility attributes. > I would strongly vote against automatically generating the map files > from sources by parsing for special patterns as proposed by Magnus > because I think this will just introduce another level of complexity > and another point of failure. My priorities is to prefer no map files if we can avoid it, but to prefer automatically generated over static, checked in, mapfiles if they cannot be avoided. So I'll try to join you in the fight to get rid of them altogether, but if that fails, I still want to generate them. :-) Having static map files are a source of complexity and point of failure in itself as well. > >From this discussion so far I learned the following: > > - as long as Oracle insists on static linking libstdc++ and libgcc > there's no way of getting rid of the map files. > > - using -fvisibility=hidden/__attribute__((visibility("default"))) is > still desirable because it has positive performance impacts on some > platforms and because it is the easiest and cleanest solution for the > future when we can finally get rid of the map files. Moreover it is > already used anyway. __attribute__((visibility("default"))) sounds very much like a gcc extension. Is there a similar construct for solaris studio? Otherwise we would still need mapfiles on solaris. Also, does __attribute__((visibility("default"))) work with clang? When I check the jdk build system, I notice that we do not use mapfiles on macosx. (This does not stop us from having a "mapfile-macosx" in a library... :-/) Also, it seems that the same goes for xlc on aix; we will process mapfiles but in the end ignore them. I have no idea what this means for the situation on the exported symbols on these platforms. And then we have the reorder files in jdk, where we extend the mapfiles with a reorder section which specify a specific order in which to store functions, based on a (believed, perceived, or once upon a time, real) performance boost. Oh my! When I carefully checked the jdk code, it seems that there's a bug in NativeCompilation, that makes all mapfiles ignored unless there is also a reorder file. That's only true for 7 libraries, out of the 40 that has mapfiles. The same goes for launchers, we point to an incorrect directory containing the mapfiles. So either I'm mis-reading the code, or we have not actually used most of the mapfiles for possibly a very long time. I'm not sure why this has not been noticed. > - This solution would also establish something like a very low level > contract that the VM will only ever export JVM_*/JNI_* symbols. > > Currently, the following symbols which don't start with JNI_ and JVM_ > and are exported by the > hotspot/make/linux/makefiles/mapfile-vers-product map file from > libjvm.so on Linux: > > # miscellaneous functions > jio_fprintf; > jio_snprintf; > jio_vfprintf; > jio_vsnprintf; > - exported and used in the jdk/ (trough jdk/src/share/javavm/export/jvm.h) > - could be easily renamed to JVM_* Unfortunately, it's not that easy. While not nicely designed, those function that by tradition has been exported by libjvm.so can be considered part of the already-existing JVM/JDK contract. > For the shared libraries in the jdk/ repository, the situation is a > little different. > Only the following three libraries do statically link libstdc++/libgcc: > > libfontmanager.so > libunpack.so > libsunec.so Yeah, that's a story in itself, isn't it. I remember being upset about it when I realized this was the case, but then forgot about it. We shouldn't mix statically and dynamically linking the standard library, that's just dumb. * The benefits of static linking is that we do not depend on a specific version of the library being available on the customer's computer; we can run with our own well known, tested and trusted version. But if you still do dynamic linking, other libraries are susceptible to this problem. * The benefits of dynamic linking is that we get a smaller footprint, and do not need to keep track of security patches in the standard libraries. But if we ship some libraries with static linking, we get a unneccessary large footprint and we *still* need to keep track of security issues. I can see good points for both approaches (even though I would tend to prefer dynamic linking), but mixing them just gives us the bad parts from both worlds. /Magnus From david.holmes at oracle.com Wed Feb 19 01:33:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Feb 2014 19:33:35 +1000 Subject: Mapfiles and static linking of standard libraries In-Reply-To: <530477C1.2010507@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> <530477C1.2010507@oracle.com> Message-ID: <53047A6F.3000101@oracle.com> Note that we (hotspot) do use a mapfile on OSX. This was needed to avoid every symbol in libjvm being exported resulting in the wrong versions of operator new/delete being used. David On 19/02/2014 7:22 PM, Magnus Ihse Bursie wrote: > (Adding in build-dev since we're moving into the jdk build as well now.) > > On 2014-02-17 17:39, Volker Simonis wrote: >> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff >> wrote: >>> Dan, >>> >>> It was my bad - missed two related threads. >>> >>> We have two problems related to map files: >>> >>> 1. We have hand-written mapfiles and have to manage it manually. >>> >>> It's better to generate map file automatically or use visibility >>> attributes. >> I would strongly vote against automatically generating the map files >> from sources by parsing for special patterns as proposed by Magnus >> because I think this will just introduce another level of complexity >> and another point of failure. > > My priorities is to prefer no map files if we can avoid it, but to > prefer automatically generated over static, checked in, mapfiles if they > cannot be avoided. So I'll try to join you in the fight to get rid of > them altogether, but if that fails, I still want to generate them. :-) > Having static map files are a source of complexity and point of failure > in itself as well. > > >> >From this discussion so far I learned the following: >> >> - as long as Oracle insists on static linking libstdc++ and libgcc >> there's no way of getting rid of the map files. >> >> - using -fvisibility=hidden/__attribute__((visibility("default"))) is >> still desirable because it has positive performance impacts on some >> platforms and because it is the easiest and cleanest solution for the >> future when we can finally get rid of the map files. Moreover it is >> already used anyway. > > __attribute__((visibility("default"))) sounds very much like a gcc > extension. Is there a similar construct for solaris studio? Otherwise we > would still need mapfiles on solaris. Also, does > __attribute__((visibility("default"))) work with clang? When I check the > jdk build system, I notice that we do not use mapfiles on macosx. (This > does not stop us from having a "mapfile-macosx" in a library... :-/) > Also, it seems that the same goes for xlc on aix; we will process > mapfiles but in the end ignore them. I have no idea what this means for > the situation on the exported symbols on these platforms. > > And then we have the reorder files in jdk, where we extend the mapfiles > with a reorder section which specify a specific order in which to store > functions, based on a (believed, perceived, or once upon a time, real) > performance boost. > > Oh my! When I carefully checked the jdk code, it seems that there's a > bug in NativeCompilation, that makes all mapfiles ignored unless there > is also a reorder file. That's only true for 7 libraries, out of the 40 > that has mapfiles. The same goes for launchers, we point to an incorrect > directory containing the mapfiles. > > So either I'm mis-reading the code, or we have not actually used most of > the mapfiles for possibly a very long time. I'm not sure why this has > not been noticed. > >> - This solution would also establish something like a very low level >> contract that the VM will only ever export JVM_*/JNI_* symbols. >> >> Currently, the following symbols which don't start with JNI_ and JVM_ >> and are exported by the >> hotspot/make/linux/makefiles/mapfile-vers-product map file from >> libjvm.so on Linux: >> >> # miscellaneous functions >> jio_fprintf; >> jio_snprintf; >> jio_vfprintf; >> jio_vsnprintf; >> - exported and used in the jdk/ (trough >> jdk/src/share/javavm/export/jvm.h) >> - could be easily renamed to JVM_* > > Unfortunately, it's not that easy. While not nicely designed, those > function that by tradition has been exported by libjvm.so can be > considered part of the already-existing JVM/JDK contract. > >> For the shared libraries in the jdk/ repository, the situation is a >> little different. >> Only the following three libraries do statically link libstdc++/libgcc: >> >> libfontmanager.so >> libunpack.so >> libsunec.so > > Yeah, that's a story in itself, isn't it. I remember being upset about > it when I realized this was the case, but then forgot about it. We > shouldn't mix statically and dynamically linking the standard library, > that's just dumb. > * The benefits of static linking is that we do not depend on a specific > version of the library being available on the customer's computer; we > can run with our own well known, tested and trusted version. But if you > still do dynamic linking, other libraries are susceptible to this problem. > * The benefits of dynamic linking is that we get a smaller footprint, > and do not need to keep track of security patches in the standard > libraries. But if we ship some libraries with static linking, we get a > unneccessary large footprint and we *still* need to keep track of > security issues. > > I can see good points for both approaches (even though I would tend to > prefer dynamic linking), but mixing them just gives us the bad parts > from both worlds. > > /Magnus > From goetz.lindenmaier at sap.com Wed Feb 19 01:55:33 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 19 Feb 2014 09:55:33 +0000 Subject: assertion in ciTypeFlow OSR'ing in finally clause In-Reply-To: <5303A32E.1000208@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> <53026446.4030000@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> <5303A32E.1000208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA336E@DEWDFEMB12A.global.corp.sap> Hi Vladimir, Thanks for the short docu ;). That's just what I already tried, along with some Replay flags handling initialization errors. I made sure that I use consistently hs-comp. But that does not help. It does not find the java classes. I figured the benchmark runner only loads the benchmarks from zip files in the dacapo .jar. So I added that directly, but that does not help either (see below). Probably replay only works with Java programs where all files are directly in a jar file. Best regards, Goetz. test/dacapo-2> dbg-ppc_vm/bin/jar -tf /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar | grep InternalCompletionContext org/eclipse/jdt/internal/codeassist/InternalCompletionContext.class test/dacapo-2> dbg-ppc_vm/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid17515.log -XX:-UseSIGTRAP -XX:+DeoptimizeALot -jar /sapmnt/home/d045726/sapjvm_tools/benchmarks/dacapo/dacapo-2006-10-MR2.jar -cp /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar eclipse java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.codeassist.InternalCompletionContext at java.net.URLClassLoader$1.run(URLClassLoader.java:372) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) Failed on org/eclipse/jdt/internal/codeassist/InternalCompletionContext -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Dienstag, 18. Februar 2014 19:15 To: hotspot-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause On 2/18/14 8:22 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until > running into the problem. I tried replay compilation, but I don't get that to work. > Is there some docu on that? No docu, as usual :) You add next flags to your command line you used to run app and run with debug VM: -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid1234.log And it is better if you use latest sources from hs/hs-comp which also record/replay inlining. > > I don't think the visiting order is wrong, as the blocks are analyzed > twice successfully. On a third try a block is marked 'irred' and has > no info about the return address. This is the block with bytecodes 294-300. > I dumped the trace of the analysis: > http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt > In this run, I removed all the assertions, so it runs until it aborts compilation. > There is some debug output where the first assertion would fire, in line 10524 > of the trace file. Local 4 is bottom, so the assertion fires in > ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type") I will look on it later. > > I think the assertion is just too strict if the control flow gets irreducible? I would like to keep the assert. We need to get full understanding about what happened before we consider removing it. And we do handle irreducible code for long time already. thanks, Vladimir > But I didn't figure yet why it analyzes the block a third time with po #87. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, February 17, 2014 8:35 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net > Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause > > Hi Goetz, > > Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. > I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case > which I see for the first time. > But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? > > Regards, > Vladimir > > On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. >> >> It tries to osr-compile a method at a bytecode in a finally clause. >> >> As far as I understand the assertion is too strict. >> >> The initial assertion is >> >> # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, >> tid=4398488891968 >> >> # assert(return_address->is_return_address()) failed: verify: wrong type >> >> This happens because a block in the finally clause is analyzed while not >> >> both predecessor blocks have been looked at. Thus the join of the >> >> slots that should contain the return address yields bottom, and the assertion >> >> fires. >> >> To get the dbg build passing, I have to remove 5 assertions: >> >> ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); >> >> ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); >> >> ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); >> >> If I remove these, compilation is aborted a bit later with the message: >> >> "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" >> >> I wonder whether I should fix this by adapting the assertions, or >> >> whether I should abort the compilation right away. >> >> I would appreciate some comments on this issue! >> >> Best regards, >> >> Goetz. >> From volker.simonis at gmail.com Wed Feb 19 02:14:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 19 Feb 2014 11:14:52 +0100 Subject: Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))) In-Reply-To: <530477C1.2010507@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> <530477C1.2010507@oracle.com> Message-ID: Hi, please see some comments inline. More to follow... On Wed, Feb 19, 2014 at 10:22 AM, Magnus Ihse Bursie wrote: > (Adding in build-dev since we're moving into the jdk build as well now.) > > On 2014-02-17 17:39, Volker Simonis wrote: >> >> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff >> wrote: >>> >>> Dan, >>> >>> It was my bad - missed two related threads. >>> >>> We have two problems related to map files: >>> >>> 1. We have hand-written mapfiles and have to manage it manually. >>> >>> It's better to generate map file automatically or use visibility >>> attributes. >> >> I would strongly vote against automatically generating the map files >> from sources by parsing for special patterns as proposed by Magnus >> because I think this will just introduce another level of complexity >> and another point of failure. > > > My priorities is to prefer no map files if we can avoid it, but to prefer > automatically generated over static, checked in, mapfiles if they cannot be > avoided. So I'll try to join you in the fight to get rid of them altogether, > but if that fails, I still want to generate them. :-) Having static map > files are a source of complexity and point of failure in itself as well. > > >> >From this discussion so far I learned the following: >> >> - as long as Oracle insists on static linking libstdc++ and libgcc >> there's no way of getting rid of the map files. >> >> - using -fvisibility=hidden/__attribute__((visibility("default"))) is >> still desirable because it has positive performance impacts on some >> platforms and because it is the easiest and cleanest solution for the >> future when we can finally get rid of the map files. Moreover it is >> already used anyway. > > > __attribute__((visibility("default"))) sounds very much like a gcc > extension. Is there a similar construct for solaris studio? Otherwise we > would still need mapfiles on solaris. Also, does > __attribute__((visibility("default"))) work with clang? When I check the jdk > build system, I notice that we do not use mapfiles on macosx. (This does not > stop us from having a "mapfile-macosx" in a library... :-/) Also, it seems > that the same goes for xlc on aix; we will process mapfiles but in the end > ignore them. I have no idea what this means for the situation on the > exported symbols on these platforms. For AIX, that's a known problem. It was just done this way to integrate the AIX port with minimal changes. xlc/AIX has a concept similar to map files but with a slightly different syntax (e.g. no wildcards) and we havn't impleneted that until now. > > And then we have the reorder files in jdk, where we extend the mapfiles with > a reorder section which specify a specific order in which to store > functions, based on a (believed, perceived, or once upon a time, real) > performance boost. > > Oh my! When I carefully checked the jdk code, it seems that there's a bug in > NativeCompilation, that makes all mapfiles ignored unless there is also a > reorder file. That's only true for 7 libraries, out of the 40 that has > mapfiles. The same goes for launchers, we point to an incorrect directory > containing the mapfiles. > Map files on executables (e.g. launchers) make no sense. I've pointed that out before but apparently nobody has changed that until now. I suppose that's just a leftover from the old build system. The reorder stuff is only relevant on Solaris, where the reorder files are appended on the map files. I'm not an Solaris/SunStudio expert, but I actually doubt the the current reorder files really result in some performance advantage. As far as I know, they have to be build with Performance Analyzer. Even if that was done the right way and resulted in some performance improvement, that was a long time ago and since then nobody has ever verified this. > So either I'm mis-reading the code, or we have not actually used most of the > mapfiles for possibly a very long time. I'm not sure why this has not been > noticed. > >> - This solution would also establish something like a very low level >> contract that the VM will only ever export JVM_*/JNI_* symbols. >> >> Currently, the following symbols which don't start with JNI_ and JVM_ >> and are exported by the >> hotspot/make/linux/makefiles/mapfile-vers-product map file from >> libjvm.so on Linux: >> >> # miscellaneous functions >> jio_fprintf; >> jio_snprintf; >> jio_vfprintf; >> jio_vsnprintf; >> - exported and used in the jdk/ (trough jdk/src/share/javavm/export/jvm.h) >> - could be easily renamed to JVM_* > OK, but even with that being true, we could get away with a three-line map file for HotSpot which should do the job: SUNWprivate_1.1 { global: # JNI JNI_*; # JVM JVM_*; # jio jio_*; local: *; }; I don't see the benefits of automatic generation here. > > Unfortunately, it's not that easy. While not nicely designed, those function > that by tradition has been exported by libjvm.so can be considered part of > the already-existing JVM/JDK contract. > >> For the shared libraries in the jdk/ repository, the situation is a >> little different. >> Only the following three libraries do statically link libstdc++/libgcc: >> >> libfontmanager.so >> libunpack.so >> libsunec.so > > > Yeah, that's a story in itself, isn't it. I remember being upset about it > when I realized this was the case, but then forgot about it. We shouldn't > mix statically and dynamically linking the standard library, that's just > dumb. > * The benefits of static linking is that we do not depend on a specific > version of the library being available on the customer's computer; we can > run with our own well known, tested and trusted version. But if you still do > dynamic linking, other libraries are susceptible to this problem. > * The benefits of dynamic linking is that we get a smaller footprint, and > do not need to keep track of security patches in the standard libraries. But > if we ship some libraries with static linking, we get a unneccessary large > footprint and we *still* need to keep track of security issues. > > I can see good points for both approaches (even though I would tend to > prefer dynamic linking), but mixing them just gives us the bad parts from > both worlds. > The only libraries which are statically linked are libstdc++/libgcc and this is only necessary for C++ code - hence only three libraries in the class libraries and libjvm.so. Regarding the pros and cons of static linking I can only quote my own statement from a mail on the previous thread: It's bad - security-wise as well as from a usability perspective: Security-wise because the JDK will need to be rebuild for every security fix in libgcc and libstdc++. I'm not sure if there's at least somebody actively and regularly looking at libgcc/libstdc++ security issues. Considering the fact, that the JDK is usually build on a "not so new" Linux release when it is released for the first time, this even decreases the possibility that libgcc/libstdc++ are actively supported on that release for the full JDK life time. >From a user perspective, because users can only safely use/link C++ JNI libraries with the JDK which have been build against the exactly same libgcc/libstdc++ version. Others, like RedHat (OpenJDK/IcedTea) and SAP (SAP JVM) don't do this any more - i.e. they link libgcc/libstdc++ dynamically, without any problems. While I'm aware that dynamic linking imposes some compatibility risks as well if the same binary must support a bunch of different releases, I still think that is easier to mange. I think static linking of libgcc/libstdc++ is pre-gcc-2.9.2 paranoia (just look at the (old) makefiles). > /Magnus > From goetz.lindenmaier at sap.com Wed Feb 19 07:47:49 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 19 Feb 2014 15:47:49 +0000 Subject: assertion in ciTypeFlow OSR'ing in finally clause References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> <53026446.4030000@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> <5303A32E.1000208@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA346E@DEWDFEMB12A.global.corp.sap> Hi, I found out that putting the classes on the bootclasspath helps. But then it stops at classes generated by reflection:it stops at classes generated by reflection: ... Resolving klass sun/reflect/Reflection at 247 Resolving klass sun/reflect/MagicAccessorImpl at 3 java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4 java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4 Caused by: java.lang.ClassNotFoundException: sun.reflect.GeneratedConstructorAccessor4 at java.net.URLClassLoader$1.run(URLClassLoader.java:372) ... Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Mittwoch, 19. Februar 2014 10:56 To: 'Vladimir Kozlov'; hotspot-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: RE: assertion in ciTypeFlow OSR'ing in finally clause Hi Vladimir, Thanks for the short docu ;). That's just what I already tried, along with some Replay flags handling initialization errors. I made sure that I use consistently hs-comp. But that does not help. It does not find the java classes. I figured the benchmark runner only loads the benchmarks from zip files in the dacapo .jar. So I added that directly, but that does not help either (see below). Probably replay only works with Java programs where all files are directly in a jar file. Best regards, Goetz. test/dacapo-2> dbg-ppc_vm/bin/jar -tf /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar | grep InternalCompletionContext org/eclipse/jdt/internal/codeassist/InternalCompletionContext.class test/dacapo-2> dbg-ppc_vm/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid17515.log -XX:-UseSIGTRAP -XX:+DeoptimizeALot -jar /sapmnt/home/d045726/sapjvm_tools/benchmarks/dacapo/dacapo-2006-10-MR2.jar -cp /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar eclipse java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.codeassist.InternalCompletionContext at java.net.URLClassLoader$1.run(URLClassLoader.java:372) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:360) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) Failed on org/eclipse/jdt/internal/codeassist/InternalCompletionContext -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Dienstag, 18. Februar 2014 19:15 To: hotspot-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause On 2/18/14 8:22 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until > running into the problem. I tried replay compilation, but I don't get that to work. > Is there some docu on that? No docu, as usual :) You add next flags to your command line you used to run app and run with debug VM: -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid1234.log And it is better if you use latest sources from hs/hs-comp which also record/replay inlining. > > I don't think the visiting order is wrong, as the blocks are analyzed > twice successfully. On a third try a block is marked 'irred' and has > no info about the return address. This is the block with bytecodes 294-300. > I dumped the trace of the analysis: > http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt > In this run, I removed all the assertions, so it runs until it aborts compilation. > There is some debug output where the first assertion would fire, in line 10524 > of the trace file. Local 4 is bottom, so the assertion fires in > ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type") I will look on it later. > > I think the assertion is just too strict if the control flow gets irreducible? I would like to keep the assert. We need to get full understanding about what happened before we consider removing it. And we do handle irreducible code for long time already. thanks, Vladimir > But I didn't figure yet why it analyzes the block a third time with po #87. > > Best regards, > Goetz. > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Monday, February 17, 2014 8:35 PM > To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net > Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause > > Hi Goetz, > > Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. > I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case > which I see for the first time. > But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? > > Regards, > Vladimir > > On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. >> >> It tries to osr-compile a method at a bytecode in a finally clause. >> >> As far as I understand the assertion is too strict. >> >> The initial assertion is >> >> # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, >> tid=4398488891968 >> >> # assert(return_address->is_return_address()) failed: verify: wrong type >> >> This happens because a block in the finally clause is analyzed while not >> >> both predecessor blocks have been looked at. Thus the join of the >> >> slots that should contain the return address yields bottom, and the assertion >> >> fires. >> >> To get the dbg build passing, I have to remove 5 assertions: >> >> ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); >> >> ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); >> >> ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); >> >> ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); >> >> If I remove these, compilation is aborted a bit later with the message: >> >> "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" >> >> I wonder whether I should fix this by adapting the assertions, or >> >> whether I should abort the compilation right away. >> >> I would appreciate some comments on this issue! >> >> Best regards, >> >> Goetz. >> From jeremymanson at google.com Wed Feb 19 08:10:26 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 19 Feb 2014 08:10:26 -0800 Subject: Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))) In-Reply-To: <530477C1.2010507@oracle.com> References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> <530477C1.2010507@oracle.com> Message-ID: On Wed, Feb 19, 2014 at 1:22 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > (Adding in build-dev since we're moving into the jdk build as well now.) > > On 2014-02-17 17:39, Volker Simonis wrote: > >> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff >> wrote: >> >>> Dan, >>> >>> It was my bad - missed two related threads. >>> >>> We have two problems related to map files: >>> >>> 1. We have hand-written mapfiles and have to manage it manually. >>> >>> It's better to generate map file automatically or use visibility >>> attributes. >>> >> I would strongly vote against automatically generating the map files >> from sources by parsing for special patterns as proposed by Magnus >> because I think this will just introduce another level of complexity >> and another point of failure. >> > > My priorities is to prefer no map files if we can avoid it, but to prefer > automatically generated over static, checked in, mapfiles if they cannot be > avoided. So I'll try to join you in the fight to get rid of them > altogether, but if that fails, I still want to generate them. :-) Having > static map files are a source of complexity and point of failure in itself > as well. > > > >From this discussion so far I learned the following: >> >> - as long as Oracle insists on static linking libstdc++ and libgcc >> there's no way of getting rid of the map files. >> >> - using -fvisibility=hidden/__attribute__((visibility("default"))) is >> still desirable because it has positive performance impacts on some >> platforms and because it is the easiest and cleanest solution for the >> future when we can finally get rid of the map files. Moreover it is >> already used anyway. >> > > __attribute__((visibility("default"))) sounds very much like a gcc > extension. Is there a similar construct for solaris studio? Otherwise we > would still need mapfiles on solaris. Also, does __attribute__((visibility("default"))) > work with clang? I don't know the story for Solaris, but Clang supports this (they have almost complete gcc compatibility). Other compilers tend to have other kinds of support - I think MSVC has _declspec(dllexport). Note also that __attribute__ is now standard in c++11, although visibility is still gcc (and friends) specific. Since you seem to be meandering down this path, someone might want to check on what is needed for linker gc. I think you guys still compile hotspot with -export-dynamic (boo!). (Or, it might be more interesting to clean up dead code.) Jeremy From vladimir.kozlov at oracle.com Wed Feb 19 08:29:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Feb 2014 08:29:50 -0800 Subject: assertion in ciTypeFlow OSR'ing in finally clause In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA346E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA2AD0@DEWDFEMB12A.global.corp.sap> <53026446.4030000@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA30FA@DEWDFEMB12A.global.corp.sap> <5303A32E.1000208@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA346E@DEWDFEMB12A.global.corp.sap> Message-ID: <5304DBFE.7080904@oracle.com> Yes, unfortunately Replay tool has problems with such classes and also Lambda methods. Essentially with everything which is generated during execution. Sometimes it will work if you remove such info from replay.log file when there is no direct dependency on it during compilation. Thanks, Vladimir On 2/19/14 7:47 AM, Lindenmaier, Goetz wrote: > Hi, > > I found out that putting the classes on the bootclasspath helps. > But then it stops at classes generated by reflection:it stops at classes generated by reflection: > > ... > Resolving klass sun/reflect/Reflection at 247 > Resolving klass sun/reflect/MagicAccessorImpl at 3 > java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4 > java.lang.NoClassDefFoundError: sun/reflect/GeneratedConstructorAccessor4 > Caused by: java.lang.ClassNotFoundException: sun.reflect.GeneratedConstructorAccessor4 > at java.net.URLClassLoader$1.run(URLClassLoader.java:372) > ... > > Best regards, > Goetz. > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 19. Februar 2014 10:56 > To: 'Vladimir Kozlov'; hotspot-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RE: assertion in ciTypeFlow OSR'ing in finally clause > > Hi Vladimir, > > Thanks for the short docu ;). That's just what I already tried, > along with some Replay flags handling initialization errors. > I made sure that I use consistently hs-comp. But that does not help. > It does not find the java classes. > I figured the benchmark runner only loads the benchmarks from > zip files in the dacapo .jar. So I added that directly, but that does > not help either (see below). > > Probably replay only works with Java programs where all files > are directly in a jar file. > > Best regards, > Goetz. > > test/dacapo-2> dbg-ppc_vm/bin/jar -tf /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar | grep InternalCompletionContext > org/eclipse/jdt/internal/codeassist/InternalCompletionContext.class > test/dacapo-2> dbg-ppc_vm/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid17515.log -XX:-UseSIGTRAP -XX:+DeoptimizeALot -jar /sapmnt/home/d045726/sapjvm_tools/benchmarks/dacapo/dacapo-2006-10-MR2.jar -cp /usr/work/d045726/tmp/test/dacapo-2/data/eclipse/plugins/org.eclipse.jdt.core_3.1.2.jar eclipse > java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext > java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/codeassist/InternalCompletionContext > Caused by: java.lang.ClassNotFoundException: org.eclipse.jdt.internal.codeassist.InternalCompletionContext > at java.net.URLClassLoader$1.run(URLClassLoader.java:372) > at java.net.URLClassLoader$1.run(URLClassLoader.java:361) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:360) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > > Failed on org/eclipse/jdt/internal/codeassist/InternalCompletionContext > > > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Dienstag, 18. Februar 2014 19:15 > To: hotspot-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause > > On 2/18/14 8:22 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> No, I couldn't yet reproduce it in a small test case. Dacapo runs around 30min until >> running into the problem. I tried replay compilation, but I don't get that to work. >> Is there some docu on that? > > No docu, as usual :) > > You add next flags to your command line you used to run app and run with > debug VM: > > -XX:+ReplayCompiles -XX:ReplayDataFile=replay_pid1234.log > > And it is better if you use latest sources from hs/hs-comp which also > record/replay inlining. > >> >> I don't think the visiting order is wrong, as the blocks are analyzed >> twice successfully. On a third try a block is marked 'irred' and has >> no info about the return address. This is the block with bytecodes 294-300. >> I dumped the trace of the analysis: >> http://cr.openjdk.java.net/~goetz/bug-ciTypeFlow/ciTypeFlow_trace.txt >> In this run, I removed all the assertions, so it runs until it aborts compilation. >> There is some debug output where the first assertion would fire, in line 10524 >> of the trace file. Local 4 is bottom, so the assertion fires in >> ciTypeFlow::JsrSet::apply_control(): assert(... "verify: wrong type") > > I will look on it later. > >> >> I think the assertion is just too strict if the control flow gets irreducible? > > I would like to keep the assert. We need to get full understanding about > what happened before we consider removing it. And we do handle > irreducible code for long time already. > > thanks, > Vladimir > >> But I didn't figure yet why it analyzes the block a third time with po #87. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Monday, February 17, 2014 8:35 PM >> To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: assertion in ciTypeFlow OSR'ing in finally clause >> >> Hi Goetz, >> >> Do you have a simple test case? It would be nice to have it in VM regression tests as part of changes. >> I would suggest to bail out from compilation immediately and leave asserts as they are. It looks like a corner case >> which I see for the first time. >> But before that, can you check that there is no issue in RPO blocks ordering in ciTypeFlow? >> >> Regards, >> Vladimir >> >> On 2/17/14 5:56 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I get an assertion in ciTypeFlow running the ppc port with DeotimizeALot. >>> >>> It tries to osr-compile a method at a bytecode in a finally clause. >>> >>> As far as I understand the assertion is too strict. >>> >>> The initial assertion is >>> >>> # Internal Error (/sapmnt/home1/d045726/oJ/raw-2-stage-hotspot/src/share/vm/ci/ciTypeFlow.cpp:218), pid=7287, >>> tid=4398488891968 >>> >>> # assert(return_address->is_return_address()) failed: verify: wrong type >>> >>> This happens because a block in the finally clause is analyzed while not >>> >>> both predecessor blocks have been looked at. Thus the join of the >>> >>> slots that should contain the return address yields bottom, and the assertion >>> >>> fires. >>> >>> To get the dbg build passing, I have to remove 5 assertions: >>> >>> ciTypeFlow.cpp:195 assert(false, "verify: returning from invalid subroutine"); >>> >>> ciTypeFlow.cpp:218 assert(return_address->is_return_address(), "verify: wrong type"); >>> >>> ciTypeFlow.cpp:812 assert(address->is_return_address(), "bad return address"); >>> >>> ciTypeFlow.cpp:1758 assert(return_address->is_return_address(), "verify: wrong type"); >>> >>> ciMetadata.hpp:83 assert(is_return_address(), "bad cast"); >>> >>> If I remove these, compilation is aborted a bit later with the message: >>> >>> "COMPILE SKIPPED: OSR starts with non-empty stack (not retryable)" >>> >>> I wonder whether I should fix this by adapting the assertions, or >>> >>> whether I should abort the compilation right away. >>> >>> I would appreciate some comments on this issue! >>> >>> Best regards, >>> >>> Goetz. >>> From volker.simonis at gmail.com Wed Feb 19 09:43:16 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 19 Feb 2014 18:43:16 +0100 Subject: Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))) In-Reply-To: References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> <530477C1.2010507@oracle.com> Message-ID: On Wed, Feb 19, 2014 at 5:10 PM, Jeremy Manson wrote: > > > > On Wed, Feb 19, 2014 at 1:22 AM, Magnus Ihse Bursie > wrote: >> >> (Adding in build-dev since we're moving into the jdk build as well now.) >> >> On 2014-02-17 17:39, Volker Simonis wrote: >>> >>> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff >>> wrote: >>>> >>>> Dan, >>>> >>>> It was my bad - missed two related threads. >>>> >>>> We have two problems related to map files: >>>> >>>> 1. We have hand-written mapfiles and have to manage it manually. >>>> >>>> It's better to generate map file automatically or use visibility >>>> attributes. >>> >>> I would strongly vote against automatically generating the map files >>> from sources by parsing for special patterns as proposed by Magnus >>> because I think this will just introduce another level of complexity >>> and another point of failure. >> >> >> My priorities is to prefer no map files if we can avoid it, but to prefer >> automatically generated over static, checked in, mapfiles if they cannot be >> avoided. So I'll try to join you in the fight to get rid of them altogether, >> but if that fails, I still want to generate them. :-) Having static map >> files are a source of complexity and point of failure in itself as well. >> >> >>> >From this discussion so far I learned the following: >>> >>> - as long as Oracle insists on static linking libstdc++ and libgcc >>> there's no way of getting rid of the map files. >>> >>> - using -fvisibility=hidden/__attribute__((visibility("default"))) is >>> still desirable because it has positive performance impacts on some >>> platforms and because it is the easiest and cleanest solution for the >>> future when we can finally get rid of the map files. Moreover it is >>> already used anyway. >> >> >> __attribute__((visibility("default"))) sounds very much like a gcc >> extension. Is there a similar construct for solaris studio? Otherwise we >> would still need mapfiles on solaris. Also, does >> __attribute__((visibility("default"))) work with clang? > > > I don't know the story for Solaris, but Clang supports this (they have > almost complete gcc compatibility). Other compilers tend to have other > kinds of support - I think MSVC has _declspec(dllexport). > > Note also that __attribute__ is now standard in c++11, although visibility > is still gcc (and friends) specific. > > Since you seem to be meandering down this path, someone might want to check > on what is needed for linker gc. I think you guys still compile hotspot > with -export-dynamic (boo!). (Or, it might be more interesting to clean up > dead code.) As far as I can see, '-export-dynamic' is currently only used for linking "adlc" (which is a build-time only tool). > > Jeremy From jeremymanson at google.com Wed Feb 19 11:21:11 2014 From: jeremymanson at google.com (Jeremy Manson) Date: Wed, 19 Feb 2014 11:21:11 -0800 Subject: Mapfiles and static linking of standard libraries (was: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))) In-Reply-To: References: <52F18B03.1000107@oracle.com> <52F1E551.2070304@oracle.com> <52FC73B6.7070701@oracle.com> <530170B0.30308@oracle.com> <5301C5E9.1050703@oracle.com> <1F19B361-8CAA-4404-8034-90276164846A@oracle.com> <53021C25.10106@oracle.com> <530225F0.1040905@oracle.com> <530477C1.2010507@oracle.com> Message-ID: You're right - I misread it. Jeremy On Wed, Feb 19, 2014 at 9:43 AM, Volker Simonis wrote: > On Wed, Feb 19, 2014 at 5:10 PM, Jeremy Manson > wrote: > > > > > > > > On Wed, Feb 19, 2014 at 1:22 AM, Magnus Ihse Bursie > > wrote: > >> > >> (Adding in build-dev since we're moving into the jdk build as well now.) > >> > >> On 2014-02-17 17:39, Volker Simonis wrote: > >>> > >>> On Mon, Feb 17, 2014 at 4:08 PM, Dmitry Samersoff > >>> wrote: > >>>> > >>>> Dan, > >>>> > >>>> It was my bad - missed two related threads. > >>>> > >>>> We have two problems related to map files: > >>>> > >>>> 1. We have hand-written mapfiles and have to manage it manually. > >>>> > >>>> It's better to generate map file automatically or use visibility > >>>> attributes. > >>> > >>> I would strongly vote against automatically generating the map files > >>> from sources by parsing for special patterns as proposed by Magnus > >>> because I think this will just introduce another level of complexity > >>> and another point of failure. > >> > >> > >> My priorities is to prefer no map files if we can avoid it, but to > prefer > >> automatically generated over static, checked in, mapfiles if they > cannot be > >> avoided. So I'll try to join you in the fight to get rid of them > altogether, > >> but if that fails, I still want to generate them. :-) Having static map > >> files are a source of complexity and point of failure in itself as well. > >> > >> > >>> >From this discussion so far I learned the following: > >>> > >>> - as long as Oracle insists on static linking libstdc++ and libgcc > >>> there's no way of getting rid of the map files. > >>> > >>> - using -fvisibility=hidden/__attribute__((visibility("default"))) is > >>> still desirable because it has positive performance impacts on some > >>> platforms and because it is the easiest and cleanest solution for the > >>> future when we can finally get rid of the map files. Moreover it is > >>> already used anyway. > >> > >> > >> __attribute__((visibility("default"))) sounds very much like a gcc > >> extension. Is there a similar construct for solaris studio? Otherwise we > >> would still need mapfiles on solaris. Also, does > >> __attribute__((visibility("default"))) work with clang? > > > > > > I don't know the story for Solaris, but Clang supports this (they have > > almost complete gcc compatibility). Other compilers tend to have other > > kinds of support - I think MSVC has _declspec(dllexport). > > > > Note also that __attribute__ is now standard in c++11, although > visibility > > is still gcc (and friends) specific. > > > > Since you seem to be meandering down this path, someone might want to > check > > on what is needed for linker gc. I think you guys still compile hotspot > > with -export-dynamic (boo!). (Or, it might be more interesting to clean > up > > dead code.) > > As far as I can see, '-export-dynamic' is currently only used for > linking "adlc" (which is a build-time only tool). > > > > > Jeremy > From vladimir.kozlov at oracle.com Wed Feb 19 15:24:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Feb 2014 15:24:26 -0800 Subject: Sync jdk9/hs-comp and jdk9/hs (ppc-aix changes) Message-ID: <53053D2A.20304@oracle.com> The testing of PPC-AIX changes in jdk9/hs-comp is finished. I pulled all hotspot changes from jdk9/hs/hotspot to jdk9/hs-comp/hotspot today. And I am pushing additional ppc fix for 8034797. I merged jdk from jdk9/hs/jdk yesterday. Now jdk9/hs-comp forest has all changes from jdk9/hs. I ran jdk control build of whole jdk9/hs-comp forest in JPRT and it passed. Volker and Goetz, please, verify that jdk9/hs-comp does not have any problems for you. I will merge it into jdk9/hs tomorrow if it is good. Thanks, Vladimir From sergei.kovalev at oracle.com Wed Feb 19 23:18:44 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 20 Feb 2014 11:18:44 +0400 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: <6A4175A3-DAEC-42D2-99E6-42960B6122E1@oracle.com> References: <5302016A.1020906@oracle.com> <6A4175A3-DAEC-42D2-99E6-42960B6122E1@oracle.com> Message-ID: <5305AC54.2010102@oracle.com> Hello Team, Could somebody else take a look? I need one more approval. 18.02.2014 14:04, Staffan Larsen ?????: > Looks good! > > Thanks, > /Staffan > > On 17 feb 2014, at 13:32, Sergei Kovalev wrote: > >> Hello everyone, >> >> I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. >> >> As it was discussed, I prepared fix for the issue: http://cr.openjdk.java.net/~anazarov/8022203/webrev.01/ >> >> The failure caused by slippage in IO operation due to file system performance. To avoid this situation we will use an unique file name for profiling dump. In this case we will have zero probability that tests would overlapped by output file. By default the file name for dump output builds from library name plus .java. prefix and .txt suffix. Hprof tool supports "file" option that used for providing the output file name. Therefore we can just add unique file name to options string for each individual tests that used hprof. >> >> Testing done: >> - single run of tests >> - Stability run of all modified tests >> - Modified stability run. I did some test modification that helped me to increase reproducibility rating. It was 500-1000 iteration instead 10,000 in original case. Test with modified options string ran 10,000 iteration. >> >> Could you please approve fix? >> >> -- >> With best regards, >> Sergei >> -- With best regards, Sergei From staffan.larsen at oracle.com Wed Feb 19 23:45:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Feb 2014 08:45:57 +0100 Subject: JDK-8022203 - Intermittent test failures in demo/jvmti/hprof In-Reply-To: <5305AC54.2010102@oracle.com> References: <5302016A.1020906@oracle.com> <6A4175A3-DAEC-42D2-99E6-42960B6122E1@oracle.com> <5305AC54.2010102@oracle.com> Message-ID: <27761889-3A44-4A4B-932C-91D25EEE94B5@oracle.com> This change is in the jdk, not in hotspot. Only one Reviewer is required for jdk changes. However, the review request should have been sent to serviceability-dev at openjdk.java.net instead of hotspot-dev, sorry I missed that. Also, the changes need to go first into jdk9 and then backported to jdk8 (if needed). So the correct repo for the push is jdk9-dev. Thanks, /Staffan On 20 feb 2014, at 08:18, Sergei Kovalev wrote: > Hello Team, > > Could somebody else take a look? I need one more approval. > > 18.02.2014 14:04, Staffan Larsen ?????: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 17 feb 2014, at 13:32, Sergei Kovalev wrote: >> >>> Hello everyone, >>> >>> I'm working for https://bugs.openjdk.java.net/browse/JDK-8022203. >>> >>> As it was discussed, I prepared fix for the issue: http://cr.openjdk.java.net/~anazarov/8022203/webrev.01/ >>> >>> The failure caused by slippage in IO operation due to file system performance. To avoid this situation we will use an unique file name for profiling dump. In this case we will have zero probability that tests would overlapped by output file. By default the file name for dump output builds from library name plus .java. prefix and .txt suffix. Hprof tool supports "file" option that used for providing the output file name. Therefore we can just add unique file name to options string for each individual tests that used hprof. >>> >>> Testing done: >>> - single run of tests >>> - Stability run of all modified tests >>> - Modified stability run. I did some test modification that helped me to increase reproducibility rating. It was 500-1000 iteration instead 10,000 in original case. Test with modified options string ran 10,000 iteration. >>> >>> Could you please approve fix? >>> >>> -- >>> With best regards, >>> Sergei >>> > > -- > With best regards, > Sergei > From stefan.karlsson at oracle.com Thu Feb 20 01:59:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 10:59:41 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do Message-ID: <5305D20D.50308@oracle.com> Hi all, Please, review this patch to change the closure type used in frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is an abstract base class of CLDToOopClosure. We need this for the G1 Class Unloading project, to be able to specialize the CLD scanning code during the Initial Mark phase. http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ thanks, StefanK From goetz.lindenmaier at sap.com Thu Feb 20 02:13:17 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 10:13:17 +0000 Subject: RFR(XS): 8035392: cppInterpreter: fix message of NPE Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA3738@DEWDFEMB12A.global.corp.sap> Hi, we fixed an issue with the cpp interpreter. It generates a NullPointerException with "" as message. Jck test api/java_util/Objects/index.html#RequireNonNullMessageSupplier expects NULL. This is also what the template interpreter uses. Fix: change "" to NULL. http://cr.openjdk.java.net/~goetz/webrevs/8035392-1-nullMsg/ Please review and test this change. It also needs to go to jdk8u via ppc-aix-port/stage. Best regards, Goetz. From goetz.lindenmaier at sap.com Thu Feb 20 02:22:15 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 10:22:15 +0000 Subject: RFR(XS): 8035394: PPC64: Make usage of intrinsic dsqrt depend on processor recognition. Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA374A@DEWDFEMB12A.global.corp.sap> Hi, Only some PPC processors have a sqrt instruction. Currently, intrinsic for dsqrt is used if a corresponding rule is implemented in the .ad file (has_match_rule()). Instead, call match_ruole_supported(), which allows to check processor properties. Also adapt PPC64 .ad file to this. Please review and test this change http://cr.openjdk.java.net/~goetz/webrevs/8035394-1-fltRck/ It also needs to go to jdk8u via ppc-aix-port/stage. Best regards, Goetz. From goetz.lindenmaier at sap.com Thu Feb 20 02:58:41 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 10:58:41 +0000 Subject: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> Hi, Access to the tmp_oop in a frame is done with several #ifdefs distinguishing the platforms and interpreters. The PPC64 template interpreter would introduce another one. This change avoids the #ifs by introducing the accessor function interpreter_frame_temp_oop_addr() as for many other fields in the frame. Unfortunately this will require to implement interpreter_frame_temp_oop_addr() in the closed sources I can not do. As the platform file for frame.hpp has to be changed anyways, I propose to also move #ifdef PPC32 oop* interpreter_frame_mirror_addr() const; #endif from frame.hpp into frame_ppc.hpp in the closed port. Please review and test this change. http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ This change should also go to jdk8u. It's fine if this happens some later if the path via ppc-aix-port/stage is not possible due to the closed change. Best regards, Goetz. From mikael.gerdin at oracle.com Thu Feb 20 03:35:29 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 20 Feb 2014 12:35:29 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <5305D20D.50308@oracle.com> References: <5305D20D.50308@oracle.com> Message-ID: <2966614.5Y5BsdS6a9@mgerdin03> Stefan, On Thursday 20 February 2014 10.59.41 Stefan Karlsson wrote: > Hi all, > > Please, review this patch to change the closure type used in > frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is > an abstract base class of CLDToOopClosure. > > We need this for the G1 Class Unloading project, to be able to > specialize the CLD scanning code during the Initial Mark phase. > > http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ Looks good. /Mikael > > thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 20 05:12:11 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 14:12:11 +0100 Subject: RFR: 8035412: Cleanup ClassLoaderData::is_alive Message-ID: <5305FF2B.5050701@oracle.com> Hi all, Please, review this patch to allow ClassLoaderData::is_alive to be used with all ClassLoaderData objects, including incomplete anonymous klasses. http://cr.openjdk.java.net/~stefank/8035412 thanks, StefanK From volker.simonis at gmail.com Thu Feb 20 05:53:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Feb 2014 14:53:46 +0100 Subject: RFR(XS): 8035423: AIX: Fix os::get_default_process_handle() in os_aix.cpp after 8031968 Message-ID: Hi, change https://bugs.openjdk.java.net/browse/JDK-8031968 moved os::get_default_process_handle() from os_posix.cpp back to the various platform files but didn't do this for AIX. The fix is trivial - just insert the implementation of os::get_default_process_handle() into os_aix.cpp as well: http://cr.openjdk.java.net/~simonis/webrevs/8035423/ https://bugs.openjdk.java.net/browse/JDK-8035423 This change is currently for jdk9/hs-comp but if 8031968 will be backported to 8u-dev (which seems to be planned according to the bug description) we also need this fix in ppc-aix-port/stage (which will finally go into 8u-dev). @Vladimir: could you please push this to jdk9/hs-comp/hotspot once it is reviewed. Thank you and best regards, Volker From thomas.schatzl at oracle.com Thu Feb 20 06:02:55 2014 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 20 Feb 2014 15:02:55 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <5305D20D.50308@oracle.com> References: <5305D20D.50308@oracle.com> Message-ID: <1392904975.2689.66.camel@cirrus> Hi, On Thu, 2014-02-20 at 10:59 +0100, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to change the closure type used in > frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is > an abstract base class of CLDToOopClosure. > > We need this for the G1 Class Unloading project, to be able to > specialize the CLD scanning code during the Initial Mark phase. > > http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ Looks good. Thomas From stefan.karlsson at oracle.com Thu Feb 20 06:27:46 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 15:27:46 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <1392904975.2689.66.camel@cirrus> References: <5305D20D.50308@oracle.com> <1392904975.2689.66.camel@cirrus> Message-ID: <530610E2.5090105@oracle.com> On 2014-02-20 15:02, Thomas Schatzl wrote: > Hi, > > On Thu, 2014-02-20 at 10:59 +0100, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to change the closure type used in >> frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is >> an abstract base class of CLDToOopClosure. >> >> We need this for the G1 Class Unloading project, to be able to >> specialize the CLD scanning code during the Initial Mark phase. >> >> http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ > Looks good. Thanks for the review. StefanK > > Thomas > > From stefan.karlsson at oracle.com Thu Feb 20 06:28:00 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 15:28:00 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <2966614.5Y5BsdS6a9@mgerdin03> References: <5305D20D.50308@oracle.com> <2966614.5Y5BsdS6a9@mgerdin03> Message-ID: <530610F0.4020401@oracle.com> On 2014-02-20 12:35, Mikael Gerdin wrote: > Stefan, > > On Thursday 20 February 2014 10.59.41 Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to change the closure type used in >> frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is >> an abstract base class of CLDToOopClosure. >> >> We need this for the G1 Class Unloading project, to be able to >> specialize the CLD scanning code during the Initial Mark phase. >> >> http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ > Looks good. Thanks for the review. StefanK > /Mikael > >> thanks, >> StefanK From goetz.lindenmaier at sap.com Thu Feb 20 07:15:36 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 15:15:36 +0000 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> Hi, I request to backport 8030875: Macros for checking and returning on exceptions to jdk8u. This is needed, as 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup was downported, that introduces the macros in jni_util.h, while 8030875 removed them in various other files. Parts of this were already fixed in 8034912: backport of 8031737 to jdk8u breaks linux buld. but that fix is not complete. Currently, the aix build is broken because of that. Also on linux a warning is issued. For the traces see below. The change does not apply completely, as parts were done by the other two mentioned. The remaining parts are here: http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ The individual patches in this change are unchanged. The original change: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 The bugid: https://bugs.openjdk.java.net/browse/JDK-8030875 The change on top of this: http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da In jdk8u: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would propose to push it to jdk8u-dev. Best regards, Goetz. The build error on aix: jni.cpp includes both, defines.h and jni_util.h. And both headers define CHECK_NULL. /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include -I.../jdk/include/aix -I.../jdk/src/share/javavm/export -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined with a different definition. ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 (I) "CHECK_NULL" is defined on line 286 of ".../jdk/src/share/native/common/jni_util.h". The warning on linux: In file included from .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: warning: "CHECK_NULL" redefined In file included from .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is the location of the previous definition echo "Compiling utils.cpp (for libunpack.so)" From volker.simonis at gmail.com Thu Feb 20 08:52:00 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Feb 2014 17:52:00 +0100 Subject: Sync jdk9/hs-comp and jdk9/hs (ppc-aix changes) In-Reply-To: <53053D2A.20304@oracle.com> References: <53053D2A.20304@oracle.com> Message-ID: Hi Vladimir, thanks for doing the the testing and merging. There's one small issue we found on AIX: Change https://bugs.openjdk.java.net/browse/JDK-8031968 moved os::get_default_process_handle() from os_posix.cpp back to the various platform files but didn't do this for AIX. The fix is trivial - just sent out a RFR. So if you could please push that fix first, everything is ready for merging the port into jdk9/hs. Any idea when this will finally arrive in jdk9/dev? As far as I understand, you'll push the whole jdk9/hs-comp forest to jdk9/hs right? I'm just asking, because we have a jdk change in jdk9/hs-comp/jdk which is needed for AIX. So this must be pushed into jdk9/hs/jdk as well. Also the whole jdk9/hs forest will have to be pushed to jdk9/dev for the same reason. Regards, Volker On Thu, Feb 20, 2014 at 12:24 AM, Vladimir Kozlov wrote: > The testing of PPC-AIX changes in jdk9/hs-comp is finished. > I pulled all hotspot changes from jdk9/hs/hotspot to jdk9/hs-comp/hotspot > today. And I am pushing additional ppc fix for 8034797. > I merged jdk from jdk9/hs/jdk yesterday. Now jdk9/hs-comp forest has all > changes from jdk9/hs. > > I ran jdk control build of whole jdk9/hs-comp forest in JPRT and it passed. > > Volker and Goetz, please, verify that jdk9/hs-comp does not have any > problems for you. I will merge it into jdk9/hs tomorrow if it is good. > > Thanks, > Vladimir From sean.coffey at oracle.com Thu Feb 20 09:06:57 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 20 Feb 2014 17:06:57 +0000 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> Message-ID: <53063631.4060401@oracle.com> Goetz, I'm going to run the remainder of this backport patch thru JPRT to ensure it's not breaking anything (else!) Since the 8030875 fix appears to be coming back in two different fixes, I'm cc'ing Roger Riggs who was original author. Roger - can you review this request also ? Thanks, Sean. On 20/02/2014 15:15, Lindenmaier, Goetz wrote: > Hi, > > I request to backport > 8030875: Macros for checking and returning on exceptions > to jdk8u. > > This is needed, as > 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup > was downported, that introduces the macros in jni_util.h, > while 8030875 removed them in various other files. > > Parts of this were already fixed in > 8034912: backport of 8031737 to jdk8u breaks linux buld. > but that fix is not complete. > Currently, the aix build is broken because of that. Also > on linux a warning is issued. For the traces see below. > > The change does not apply completely, as parts were done by > the other two mentioned. The remaining parts are here: > http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ > The individual patches in this change are unchanged. > > The original change: > http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 > The bugid: > https://bugs.openjdk.java.net/browse/JDK-8030875 > The change on top of this: > http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da > In jdk8u: > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 > > The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would > propose to push it to jdk8u-dev. > > Best regards, > Goetz. > > > The build error on aix: > > jni.cpp includes both, defines.h and jni_util.h. And both headers define CHECK_NULL. > > /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include -I.../jdk/include/aix -I.../jdk/src/share/javavm/export -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp > ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined with a different definition. > ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 (I) "CHECK_NULL" is defined on line 286 of ".../jdk/src/share/native/common/jni_util.h". > > > The warning on linux: > > In file included from .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: > .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: warning: "CHECK_NULL" redefined > In file included from .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: > .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is the location of the previous definition > echo "Compiling utils.cpp (for libunpack.so)" From alejandro.murillo at oracle.com Thu Feb 20 09:56:42 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 20 Feb 2014 17:56:42 +0000 Subject: hg: hsx/jdk7u/hotspot: 8024648: 7141246 & 8016131 break Zero port Message-ID: <20140220175645.4F48D62DD9@hg.openjdk.java.net> Changeset: ff18bcebe294 Author: andrew Date: 2014-02-20 08:30 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/ff18bcebe294 8024648: 7141246 & 8016131 break Zero port Reviewed-by: dholmes, coleenp ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/vm.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/vm.make ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp From vladimir.kozlov at oracle.com Thu Feb 20 11:08:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 11:08:52 -0800 Subject: RFR(XS): 8035392: cppInterpreter: fix message of NPE In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA3738@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA3738@DEWDFEMB12A.global.corp.sap> Message-ID: <530652C4.1030808@oracle.com> Looks good. Thanks, Vladimir On 2/20/14 2:13 AM, Lindenmaier, Goetz wrote: > Hi, > > we fixed an issue with the cpp interpreter. > > It generates a NullPointerException with "" as message. Jck test > api/java_util/Objects/index.html#RequireNonNullMessageSupplier expects > NULL. This is also what the template interpreter uses. > > Fix: change "" to NULL. > http://cr.openjdk.java.net/~goetz/webrevs/8035392-1-nullMsg/ > > Please review and test this change. It also needs to go to > jdk8u via ppc-aix-port/stage. > > Best regards, > Goetz. > From vladimir.kozlov at oracle.com Thu Feb 20 11:12:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 11:12:56 -0800 Subject: RFR(XS): 8035394: PPC64: Make usage of intrinsic dsqrt depend on processor recognition. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA374A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA374A@DEWDFEMB12A.global.corp.sap> Message-ID: <530653B8.2090800@oracle.com> Good. Vladimir On 2/20/14 2:22 AM, Lindenmaier, Goetz wrote: > Hi, > > Only some PPC processors have a sqrt instruction. > > Currently, intrinsic for dsqrt is used if a corresponding rule is implemented in the .ad file (has_match_rule()). > Instead, call match_ruole_supported(), which allows to check processor properties. > > Also adapt PPC64 .ad file to this. > > Please review and test this change > http://cr.openjdk.java.net/~goetz/webrevs/8035394-1-fltRck/ > > It also needs to go to jdk8u via ppc-aix-port/stage. > > Best regards, > Goetz. > > > From vladimir.kozlov at oracle.com Thu Feb 20 11:19:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 11:19:14 -0800 Subject: RFR(XS): 8035423: AIX: Fix os::get_default_process_handle() in os_aix.cpp after 8031968 In-Reply-To: References: Message-ID: <53065532.5070402@oracle.com> Looks good. I will push it before merge into main. thanks, Vladimir On 2/20/14 5:53 AM, Volker Simonis wrote: > Hi, > > change https://bugs.openjdk.java.net/browse/JDK-8031968 moved > os::get_default_process_handle() from os_posix.cpp back to the various > platform files but didn't do this for AIX. The fix is trivial - just > insert the implementation of os::get_default_process_handle() into > os_aix.cpp as well: > > http://cr.openjdk.java.net/~simonis/webrevs/8035423/ > https://bugs.openjdk.java.net/browse/JDK-8035423 > > This change is currently for jdk9/hs-comp but if 8031968 will be > backported to 8u-dev (which seems to be planned according to the bug > description) we also need this fix in ppc-aix-port/stage (which will > finally go into 8u-dev). > > @Vladimir: could you please push this to jdk9/hs-comp/hotspot once it > is reviewed. > > Thank you and best regards, > Volker > From sean.coffey at oracle.com Thu Feb 20 11:35:54 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 20 Feb 2014 19:35:54 +0000 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <53064445.8050407@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> Message-ID: <5306591A.70208@oracle.com> JPRT results are good. I just wanted to be sure given that this code is sensitive for builds. Approved for jdk8u-dev. Thanks for handling this Goetz. regards, Sean. On 20/02/2014 18:07, roger riggs wrote: > Hi Sean, > > Yes, these changes match the changes in JDK 9. > > Roger > > On 2/20/2014 12:06 PM, Se?n Coffey wrote: >> Goetz, >> >> I'm going to run the remainder of this backport patch thru JPRT to >> ensure it's not breaking anything (else!) >> Since the 8030875 fix appears to be coming back in two different >> fixes, I'm cc'ing Roger Riggs who was original author. >> >> Roger - can you review this request also ? >> >> Thanks, >> Sean. >> >> On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I request to backport >>> 8030875: Macros for checking and returning on exceptions >>> to jdk8u. >>> >>> This is needed, as >>> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >>> was downported, that introduces the macros in jni_util.h, >>> while 8030875 removed them in various other files. >>> >>> Parts of this were already fixed in >>> 8034912: backport of 8031737 to jdk8u breaks linux buld. >>> but that fix is not complete. >>> Currently, the aix build is broken because of that. Also >>> on linux a warning is issued. For the traces see below. >>> >>> The change does not apply completely, as parts were done by >>> the other two mentioned. The remaining parts are here: >>> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >>> The individual patches in this change are unchanged. >>> >>> The original change: >>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >>> The bugid: >>> https://bugs.openjdk.java.net/browse/JDK-8030875 >>> The change on top of this: >>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >>> In jdk8u: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >>> >>> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >>> propose to push it to jdk8u-dev. >>> >>> Best regards, >>> Goetz. >>> >>> >>> The build error on aix: >>> >>> jni.cpp includes both, defines.h and jni_util.h. And both headers >>> define CHECK_NULL. >>> >>> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >>> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >>> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >>> -I.../jdk/src/solaris/javavm/export >>> -I.../jdk/src/share/native/common >>> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >>> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >>> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI -DFULL >>> -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >>> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >>> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", >>> line 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already >>> defined with a different definition. >>> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >>> (I) "CHECK_NULL" is defined on line 286 of >>> ".../jdk/src/share/native/common/jni_util.h". >>> >>> >>> The warning on linux: >>> >>> In file included from >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >>> warning: "CHECK_NULL" redefined >>> In file included from >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >>> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >>> the location of the previous definition >>> echo "Compiling utils.cpp (for libunpack.so)" >> > From vladimir.kozlov at oracle.com Thu Feb 20 11:55:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 11:55:54 -0800 Subject: Sync jdk9/hs-comp and jdk9/hs (ppc-aix changes) In-Reply-To: References: <53053D2A.20304@oracle.com> Message-ID: <53065DCA.6000406@oracle.com> On 2/20/14 8:52 AM, Volker Simonis wrote: > Hi Vladimir, > > thanks for doing the the testing and merging. > > There's one small issue we found on AIX: > > Change https://bugs.openjdk.java.net/browse/JDK-8031968 moved > os::get_default_process_handle() from os_posix.cpp back to the various > platform files but didn't do this for AIX. The fix is trivial - just > sent out a RFR. > > So if you could please push that fix first, everything is ready for > merging the port into jdk9/hs. I am pushing this and 2 fixes from Goetz. I will push into jdk9/hs after that. > > Any idea when this will finally arrive in jdk9/dev? I assume it will be next week after PIT testing on code in jdk9/hs is done. But it is not guaranteed, could be week after next. > > As far as I understand, you'll push the whole jdk9/hs-comp forest to > jdk9/hs right? I'm just asking, because we have a jdk change in > jdk9/hs-comp/jdk which is needed for AIX. So this must be pushed into > jdk9/hs/jdk as well. Also the whole jdk9/hs forest will have to be > pushed to jdk9/dev for the same reason. I see only 8033154 fix in jdk which I need to push into main. I will push it together with hotspot and ask Alejandro to push it into dev after testing is done. Thanks, Vladimir > > Regards, > Volker > > > On Thu, Feb 20, 2014 at 12:24 AM, Vladimir Kozlov > wrote: >> The testing of PPC-AIX changes in jdk9/hs-comp is finished. >> I pulled all hotspot changes from jdk9/hs/hotspot to jdk9/hs-comp/hotspot >> today. And I am pushing additional ppc fix for 8034797. >> I merged jdk from jdk9/hs/jdk yesterday. Now jdk9/hs-comp forest has all >> changes from jdk9/hs. >> >> I ran jdk control build of whole jdk9/hs-comp forest in JPRT and it passed. >> >> Volker and Goetz, please, verify that jdk9/hs-comp does not have any >> problems for you. I will merge it into jdk9/hs tomorrow if it is good. >> >> Thanks, >> Vladimir From coleen.phillimore at oracle.com Thu Feb 20 12:04:04 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Feb 2014 15:04:04 -0500 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <530610F0.4020401@oracle.com> References: <5305D20D.50308@oracle.com> <2966614.5Y5BsdS6a9@mgerdin03> <530610F0.4020401@oracle.com> Message-ID: <53065FB4.5020607@oracle.com> Looks good. CLDClosure is a shorter name too. Coleen On 2/20/14 9:28 AM, Stefan Karlsson wrote: > > On 2014-02-20 12:35, Mikael Gerdin wrote: >> Stefan, >> >> On Thursday 20 February 2014 10.59.41 Stefan Karlsson wrote: >>> Hi all, >>> >>> Please, review this patch to change the closure type used in >>> frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, which is >>> an abstract base class of CLDToOopClosure. >>> >>> We need this for the G1 Class Unloading project, to be able to >>> specialize the CLD scanning code during the Initial Mark phase. >>> >>> http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ >> Looks good. > > Thanks for the review. > > StefanK > >> /Mikael >> >>> thanks, >>> StefanK > From coleen.phillimore at oracle.com Thu Feb 20 12:06:00 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Feb 2014 15:06:00 -0500 Subject: RFR: 8035412: Cleanup ClassLoaderData::is_alive In-Reply-To: <5305FF2B.5050701@oracle.com> References: <5305FF2B.5050701@oracle.com> Message-ID: <53066028.3040203@oracle.com> Looks fine. Coleen On 2/20/14 8:12 AM, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to allow ClassLoaderData::is_alive to be > used with all ClassLoaderData objects, including incomplete anonymous > klasses. > > http://cr.openjdk.java.net/~stefank/8035412 > > thanks, > StefanK From coleen.phillimore at oracle.com Thu Feb 20 12:06:58 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 20 Feb 2014 15:06:58 -0500 Subject: RFR(XS): 8035392: cppInterpreter: fix message of NPE In-Reply-To: <530652C4.1030808@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA3738@DEWDFEMB12A.global.corp.sap> <530652C4.1030808@oracle.com> Message-ID: <53066062.8040408@oracle.com> +1. Coleen On 2/20/14 2:08 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/20/14 2:13 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> we fixed an issue with the cpp interpreter. >> >> It generates a NullPointerException with "" as message. Jck test >> api/java_util/Objects/index.html#RequireNonNullMessageSupplier expects >> NULL. This is also what the template interpreter uses. >> >> Fix: change "" to NULL. >> http://cr.openjdk.java.net/~goetz/webrevs/8035392-1-nullMsg/ >> >> Please review and test this change. It also needs to go to >> jdk8u via ppc-aix-port/stage. >> >> Best regards, >> Goetz. >> From stefan.karlsson at oracle.com Thu Feb 20 12:15:54 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 21:15:54 +0100 Subject: RFR: 8035412: Cleanup ClassLoaderData::is_alive In-Reply-To: <53066028.3040203@oracle.com> References: <5305FF2B.5050701@oracle.com> <53066028.3040203@oracle.com> Message-ID: <5306627A.7050407@oracle.com> On 2014-02-20 21:06, Coleen Phillimore wrote: > > Looks fine. Thanks, Coleen. StefanK > Coleen > > On 2/20/14 8:12 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to allow ClassLoaderData::is_alive to be >> used with all ClassLoaderData objects, including incomplete anonymous >> klasses. >> >> http://cr.openjdk.java.net/~stefank/8035412 >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Thu Feb 20 12:16:10 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 20 Feb 2014 21:16:10 +0100 Subject: RFR: 8035393: Use CLDClosure instead of CLDToOopClosure in frame::oops_interpreted_do In-Reply-To: <53065FB4.5020607@oracle.com> References: <5305D20D.50308@oracle.com> <2966614.5Y5BsdS6a9@mgerdin03> <530610F0.4020401@oracle.com> <53065FB4.5020607@oracle.com> Message-ID: <5306628A.10709@oracle.com> On 2014-02-20 21:04, Coleen Phillimore wrote: > > Looks good. CLDClosure is a shorter name too. Thanks, Coleen. StefanK > Coleen > > On 2/20/14 9:28 AM, Stefan Karlsson wrote: >> >> On 2014-02-20 12:35, Mikael Gerdin wrote: >>> Stefan, >>> >>> On Thursday 20 February 2014 10.59.41 Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please, review this patch to change the closure type used in >>>> frame::oops_interpreted_do from CLDToOopClosure to CLDClosure, >>>> which is >>>> an abstract base class of CLDToOopClosure. >>>> >>>> We need this for the G1 Class Unloading project, to be able to >>>> specialize the CLD scanning code during the Initial Mark phase. >>>> >>>> http://cr.openjdk.java.net/~stefank/8035393/webrev.00/ >>> Looks good. >> >> Thanks for the review. >> >> StefanK >> >>> /Mikael >>> >>>> thanks, >>>> StefanK >> > From roger.riggs at oracle.com Thu Feb 20 10:07:01 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 20 Feb 2014 13:07:01 -0500 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <53063631.4060401@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> Message-ID: <53064445.8050407@oracle.com> Hi Sean, Yes, these changes match the changes in JDK 9. Roger On 2/20/2014 12:06 PM, Se?n Coffey wrote: > Goetz, > > I'm going to run the remainder of this backport patch thru JPRT to > ensure it's not breaking anything (else!) > Since the 8030875 fix appears to be coming back in two different > fixes, I'm cc'ing Roger Riggs who was original author. > > Roger - can you review this request also ? > > Thanks, > Sean. > > On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >> Hi, >> >> I request to backport >> 8030875: Macros for checking and returning on exceptions >> to jdk8u. >> >> This is needed, as >> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >> was downported, that introduces the macros in jni_util.h, >> while 8030875 removed them in various other files. >> >> Parts of this were already fixed in >> 8034912: backport of 8031737 to jdk8u breaks linux buld. >> but that fix is not complete. >> Currently, the aix build is broken because of that. Also >> on linux a warning is issued. For the traces see below. >> >> The change does not apply completely, as parts were done by >> the other two mentioned. The remaining parts are here: >> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >> The individual patches in this change are unchanged. >> >> The original change: >> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >> The bugid: >> https://bugs.openjdk.java.net/browse/JDK-8030875 >> The change on top of this: >> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >> In jdk8u: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >> >> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >> propose to push it to jdk8u-dev. >> >> Best regards, >> Goetz. >> >> >> The build error on aix: >> >> jni.cpp includes both, defines.h and jni_util.h. And both headers >> define CHECK_NULL. >> >> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >> with a different definition. >> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >> (I) "CHECK_NULL" is defined on line 286 of >> ".../jdk/src/share/native/common/jni_util.h". >> >> >> The warning on linux: >> >> In file included from >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >> warning: "CHECK_NULL" redefined >> In file included from >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >> the location of the previous definition >> echo "Compiling utils.cpp (for libunpack.so)" > From goetz.lindenmaier at sap.com Thu Feb 20 13:54:27 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 21:54:27 +0000 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <53064445.8050407@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> Sean, Roger, thanks for looking at this an testing it! It's good it's through JPRT, unfortunately I can't do that. Best regards, Goetz. -----Original Message----- From: roger riggs [mailto:roger.riggs at oracle.com] Sent: Thursday, February 20, 2014 7:07 PM To: Se?n Coffey; Lindenmaier, Goetz; jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Hi Sean, Yes, these changes match the changes in JDK 9. Roger On 2/20/2014 12:06 PM, Se?n Coffey wrote: > Goetz, > > I'm going to run the remainder of this backport patch thru JPRT to > ensure it's not breaking anything (else!) > Since the 8030875 fix appears to be coming back in two different > fixes, I'm cc'ing Roger Riggs who was original author. > > Roger - can you review this request also ? > > Thanks, > Sean. > > On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >> Hi, >> >> I request to backport >> 8030875: Macros for checking and returning on exceptions >> to jdk8u. >> >> This is needed, as >> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >> was downported, that introduces the macros in jni_util.h, >> while 8030875 removed them in various other files. >> >> Parts of this were already fixed in >> 8034912: backport of 8031737 to jdk8u breaks linux buld. >> but that fix is not complete. >> Currently, the aix build is broken because of that. Also >> on linux a warning is issued. For the traces see below. >> >> The change does not apply completely, as parts were done by >> the other two mentioned. The remaining parts are here: >> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >> The individual patches in this change are unchanged. >> >> The original change: >> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >> The bugid: >> https://bugs.openjdk.java.net/browse/JDK-8030875 >> The change on top of this: >> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >> In jdk8u: >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >> >> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >> propose to push it to jdk8u-dev. >> >> Best regards, >> Goetz. >> >> >> The build error on aix: >> >> jni.cpp includes both, defines.h and jni_util.h. And both headers >> define CHECK_NULL. >> >> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >> with a different definition. >> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >> (I) "CHECK_NULL" is defined on line 286 of >> ".../jdk/src/share/native/common/jni_util.h". >> >> >> The warning on linux: >> >> In file included from >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >> warning: "CHECK_NULL" redefined >> In file included from >> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >> the location of the previous definition >> echo "Compiling utils.cpp (for libunpack.so)" > From goetz.lindenmaier at sap.com Thu Feb 20 13:55:54 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 20 Feb 2014 21:55:54 +0000 Subject: RFR(XS): 8035392: cppInterpreter: fix message of NPE In-Reply-To: <53066062.8040408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA3738@DEWDFEMB12A.global.corp.sap> <530652C4.1030808@oracle.com> <53066062.8040408@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA3C9F@DEWDFEMB12A.global.corp.sap> Thanks for the review, Coleen and Vladimir! Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Thursday, February 20, 2014 9:07 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8035392: cppInterpreter: fix message of NPE +1. Coleen On 2/20/14 2:08 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 2/20/14 2:13 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> we fixed an issue with the cpp interpreter. >> >> It generates a NullPointerException with "" as message. Jck test >> api/java_util/Objects/index.html#RequireNonNullMessageSupplier expects >> NULL. This is also what the template interpreter uses. >> >> Fix: change "" to NULL. >> http://cr.openjdk.java.net/~goetz/webrevs/8035392-1-nullMsg/ >> >> Please review and test this change. It also needs to go to >> jdk8u via ppc-aix-port/stage. >> >> Best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Thu Feb 20 14:10:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 14:10:59 -0800 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> Message-ID: <53067D73.1010307@oracle.com> Goetz, I can push it for you. We need official reviewer for changes. Roger is not Reviewer yet. Sean, can I put you or myself as reviewer in changeset info? Thanks, Vladimir On 2/20/14 1:54 PM, Lindenmaier, Goetz wrote: > Sean, Roger, > > thanks for looking at this an testing it! > It's good it's through JPRT, unfortunately I can't do that. > > Best regards, > Goetz. > > -----Original Message----- > From: roger riggs [mailto:roger.riggs at oracle.com] > Sent: Thursday, February 20, 2014 7:07 PM > To: Se?n Coffey; Lindenmaier, Goetz; jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup > > Hi Sean, > > Yes, these changes match the changes in JDK 9. > > Roger > > On 2/20/2014 12:06 PM, Se?n Coffey wrote: >> Goetz, >> >> I'm going to run the remainder of this backport patch thru JPRT to >> ensure it's not breaking anything (else!) >> Since the 8030875 fix appears to be coming back in two different >> fixes, I'm cc'ing Roger Riggs who was original author. >> >> Roger - can you review this request also ? >> >> Thanks, >> Sean. >> >> On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I request to backport >>> 8030875: Macros for checking and returning on exceptions >>> to jdk8u. >>> >>> This is needed, as >>> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >>> was downported, that introduces the macros in jni_util.h, >>> while 8030875 removed them in various other files. >>> >>> Parts of this were already fixed in >>> 8034912: backport of 8031737 to jdk8u breaks linux buld. >>> but that fix is not complete. >>> Currently, the aix build is broken because of that. Also >>> on linux a warning is issued. For the traces see below. >>> >>> The change does not apply completely, as parts were done by >>> the other two mentioned. The remaining parts are here: >>> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >>> The individual patches in this change are unchanged. >>> >>> The original change: >>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >>> The bugid: >>> https://bugs.openjdk.java.net/browse/JDK-8030875 >>> The change on top of this: >>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >>> In jdk8u: >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >>> >>> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >>> propose to push it to jdk8u-dev. >>> >>> Best regards, >>> Goetz. >>> >>> >>> The build error on aix: >>> >>> jni.cpp includes both, defines.h and jni_util.h. And both headers >>> define CHECK_NULL. >>> >>> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >>> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >>> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >>> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >>> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >>> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >>> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >>> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >>> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >>> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >>> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >>> with a different definition. >>> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >>> (I) "CHECK_NULL" is defined on line 286 of >>> ".../jdk/src/share/native/common/jni_util.h". >>> >>> >>> The warning on linux: >>> >>> In file included from >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >>> warning: "CHECK_NULL" redefined >>> In file included from >>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >>> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >>> the location of the previous definition >>> echo "Compiling utils.cpp (for libunpack.so)" >> > From alejandro.murillo at oracle.com Thu Feb 20 14:25:49 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Thu, 20 Feb 2014 22:25:49 +0000 Subject: hg: hsx/jdk7u/hotspot: Added tag hs24.80-b03 for changeset ff18bcebe294 Message-ID: <20140220222552.50E8062DE6@hg.openjdk.java.net> Changeset: c0fe72510a8c Author: amurillo Date: 2014-02-20 12:59 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/c0fe72510a8c Added tag hs24.80-b03 for changeset ff18bcebe294 ! .hgtags From mandy.chung at oracle.com Thu Feb 20 15:53:07 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Feb 2014 15:53:07 -0800 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <53067D73.1010307@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> <53067D73.1010307@oracle.com> Message-ID: <53069563.8030900@oracle.com> You can put me as a reviewer if needed. Mandy On 2/20/2014 2:10 PM, Vladimir Kozlov wrote: > Goetz, > > I can push it for you. We need official reviewer for changes. Roger is > not Reviewer yet. Sean, can I put you or myself as reviewer in > changeset info? > > Thanks, > Vladimir > > On 2/20/14 1:54 PM, Lindenmaier, Goetz wrote: >> Sean, Roger, >> >> thanks for looking at this an testing it! >> It's good it's through JPRT, unfortunately I can't do that. >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: roger riggs [mailto:roger.riggs at oracle.com] >> Sent: Thursday, February 20, 2014 7:07 PM >> To: Se?n Coffey; Lindenmaier, Goetz; jdk8u-dev at openjdk.java.net; >> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL >> and CHECK_EXCEPTION macros cleanup >> >> Hi Sean, >> >> Yes, these changes match the changes in JDK 9. >> >> Roger >> >> On 2/20/2014 12:06 PM, Se?n Coffey wrote: >>> Goetz, >>> >>> I'm going to run the remainder of this backport patch thru JPRT to >>> ensure it's not breaking anything (else!) >>> Since the 8030875 fix appears to be coming back in two different >>> fixes, I'm cc'ing Roger Riggs who was original author. >>> >>> Roger - can you review this request also ? >>> >>> Thanks, >>> Sean. >>> >>> On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I request to backport >>>> 8030875: Macros for checking and returning on exceptions >>>> to jdk8u. >>>> >>>> This is needed, as >>>> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >>>> was downported, that introduces the macros in jni_util.h, >>>> while 8030875 removed them in various other files. >>>> >>>> Parts of this were already fixed in >>>> 8034912: backport of 8031737 to jdk8u breaks linux buld. >>>> but that fix is not complete. >>>> Currently, the aix build is broken because of that. Also >>>> on linux a warning is issued. For the traces see below. >>>> >>>> The change does not apply completely, as parts were done by >>>> the other two mentioned. The remaining parts are here: >>>> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >>>> The individual patches in this change are unchanged. >>>> >>>> The original change: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >>>> The bugid: >>>> https://bugs.openjdk.java.net/browse/JDK-8030875 >>>> The change on top of this: >>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >>>> In jdk8u: >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >>>> >>>> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >>>> propose to push it to jdk8u-dev. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>> The build error on aix: >>>> >>>> jni.cpp includes both, defines.h and jni_util.h. And both headers >>>> define CHECK_NULL. >>>> >>>> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >>>> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >>>> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >>>> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >>>> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >>>> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >>>> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >>>> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >>>> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >>>> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >>>> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >>>> with a different definition. >>>> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >>>> (I) "CHECK_NULL" is defined on line 286 of >>>> ".../jdk/src/share/native/common/jni_util.h". >>>> >>>> >>>> The warning on linux: >>>> >>>> In file included from >>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >>>> warning: "CHECK_NULL" redefined >>>> In file included from >>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >>>> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >>>> the location of the previous definition >>>> echo "Compiling utils.cpp (for libunpack.so)" >>> >> From alejandro.murillo at oracle.com Thu Feb 20 16:07:42 2014 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 21 Feb 2014 00:07:42 +0000 Subject: hg: hsx/jdk7u/hotspot: 8035435: new hotspot build - hs24.80-b04 Message-ID: <20140221000747.3860F62DEA@hg.openjdk.java.net> Changeset: 29db46e4b5b4 Author: amurillo Date: 2014-02-20 13:07 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/29db46e4b5b4 8035435: new hotspot build - hs24.80-b04 Reviewed-by: jcoomes ! make/hotspot_version From vladimir.kozlov at oracle.com Thu Feb 20 16:53:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Feb 2014 16:53:24 -0800 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <53069563.8030900@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> <53067D73.1010307@oracle.com> <53069563.8030900@oracle.com> Message-ID: <5306A384.2070703@oracle.com> Thank you, Mandy I pushed changes into jdk8u/jdk8u-dev/jdk and ppc-aix-port/stage/jdk Regards, Vladimir On 2/20/14 3:53 PM, Mandy Chung wrote: > You can put me as a reviewer if needed. > > Mandy > > On 2/20/2014 2:10 PM, Vladimir Kozlov wrote: >> Goetz, >> >> I can push it for you. We need official reviewer for changes. Roger is >> not Reviewer yet. Sean, can I put you or myself as reviewer in >> changeset info? >> >> Thanks, >> Vladimir >> >> On 2/20/14 1:54 PM, Lindenmaier, Goetz wrote: >>> Sean, Roger, >>> >>> thanks for looking at this an testing it! >>> It's good it's through JPRT, unfortunately I can't do that. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: roger riggs [mailto:roger.riggs at oracle.com] >>> Sent: Thursday, February 20, 2014 7:07 PM >>> To: Se?n Coffey; Lindenmaier, Goetz; jdk8u-dev at openjdk.java.net; >>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL >>> and CHECK_EXCEPTION macros cleanup >>> >>> Hi Sean, >>> >>> Yes, these changes match the changes in JDK 9. >>> >>> Roger >>> >>> On 2/20/2014 12:06 PM, Se?n Coffey wrote: >>>> Goetz, >>>> >>>> I'm going to run the remainder of this backport patch thru JPRT to >>>> ensure it's not breaking anything (else!) >>>> Since the 8030875 fix appears to be coming back in two different >>>> fixes, I'm cc'ing Roger Riggs who was original author. >>>> >>>> Roger - can you review this request also ? >>>> >>>> Thanks, >>>> Sean. >>>> >>>> On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I request to backport >>>>> 8030875: Macros for checking and returning on exceptions >>>>> to jdk8u. >>>>> >>>>> This is needed, as >>>>> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >>>>> was downported, that introduces the macros in jni_util.h, >>>>> while 8030875 removed them in various other files. >>>>> >>>>> Parts of this were already fixed in >>>>> 8034912: backport of 8031737 to jdk8u breaks linux buld. >>>>> but that fix is not complete. >>>>> Currently, the aix build is broken because of that. Also >>>>> on linux a warning is issued. For the traces see below. >>>>> >>>>> The change does not apply completely, as parts were done by >>>>> the other two mentioned. The remaining parts are here: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >>>>> The individual patches in this change are unchanged. >>>>> >>>>> The original change: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >>>>> The bugid: >>>>> https://bugs.openjdk.java.net/browse/JDK-8030875 >>>>> The change on top of this: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >>>>> In jdk8u: >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >>>>> >>>>> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >>>>> propose to push it to jdk8u-dev. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> The build error on aix: >>>>> >>>>> jni.cpp includes both, defines.h and jni_util.h. And both headers >>>>> define CHECK_NULL. >>>>> >>>>> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >>>>> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >>>>> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >>>>> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >>>>> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >>>>> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >>>>> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >>>>> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >>>>> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >>>>> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >>>>> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >>>>> with a different definition. >>>>> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >>>>> (I) "CHECK_NULL" is defined on line 286 of >>>>> ".../jdk/src/share/native/common/jni_util.h". >>>>> >>>>> >>>>> The warning on linux: >>>>> >>>>> In file included from >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >>>>> warning: "CHECK_NULL" redefined >>>>> In file included from >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >>>>> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >>>>> the location of the previous definition >>>>> echo "Compiling utils.cpp (for libunpack.so)" >>>> >>> > From mikael.gerdin at oracle.com Fri Feb 21 01:19:22 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Fri, 21 Feb 2014 10:19:22 +0100 Subject: RFR: 8035412: Cleanup ClassLoaderData::is_alive In-Reply-To: <5305FF2B.5050701@oracle.com> References: <5305FF2B.5050701@oracle.com> Message-ID: <2305442.odcRoQuDCB@mgerdin03> Stefan, On Thursday 20 February 2014 14.12.11 Stefan Karlsson wrote: > Hi all, > > Please, review this patch to allow ClassLoaderData::is_alive to be used > with all ClassLoaderData objects, including incomplete anonymous klasses. > > http://cr.openjdk.java.net/~stefank/8035412 classLoaderData.cpp: 325 assert(!keep_alive(), "Don't used with CLDs that are artificially kept alive"); Typo: "Don't use ..." Otherwise the change looks good. /Mikael > > thanks, > StefanK From vladimir.kozlov at oracle.com Fri Feb 21 11:27:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Feb 2014 11:27:49 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530708A7.1030700@oracle.com> References: <530708A7.1030700@oracle.com> Message-ID: <5307A8B5.2050307@oracle.com> Lets discuss it on hotspot-dev. Note the current hashtable allocates only in c_heap. Albert added hashtable which can allocate in thread local resource area for temporary table and c_heap for long live table. Albert, So you restored code in dependencies.?pp to one before 7194669 fix. Right? I think you need to follow GrowableArray example to name parameter "bool C_heap = false" instead of "bool resource_mark". It should be saved in a field because you need to free c_heap in destructor if C-heap is used: ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } Also I think you should avoid call to contains(item) in add() to avoid doing the same thing twice. You should implement remove(). Thanks, Vladimir On 2/21/14 12:04 AM, Albert wrote: > Hi, > > could I get reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 > > Problem: The problem is that the patch (7194669) - which was supposed to > speed-up dependency checking > causes a performance regression. The reason for the > performance regression is that most dependencies > are unique, so we have the overhead of determining if > the dependency is already checked plus the > overhead of dependency checking. The overhead of > searching is significant, since we perform > a linear search on 6000+ items each time. > > Solution: Use a hashtable instead of linear search to lookup already > checked dependencies. The new hashtable > is very rudimentary. It provides only the required > functionality to solve this bug. However, the functionality > can be easily extended as needed. > > Testing: jprt, failing test case, nashorn. The failing test case > completes in approx. the same time as before 7194669. > For nashorn + Octane, this patch yields the following > times spent for dependency checking: > > with this patch: 844s > 7194669: 1080s > before 7194669: 5223s > > webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ > > Thanks, > Albert > From goetz.lindenmaier at sap.com Fri Feb 21 13:47:57 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 21 Feb 2014 21:47:57 +0000 Subject: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup In-Reply-To: <5306A384.2070703@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA394D@DEWDFEMB12A.global.corp.sap> <53063631.4060401@oracle.com> <53064445.8050407@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA3C91@DEWDFEMB12A.global.corp.sap> <53067D73.1010307@oracle.com> <53069563.8030900@oracle.com> <5306A384.2070703@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA4075@DEWDFEMB12A.global.corp.sap> Hi, thanks for the review, Mandy. And thanks for pushing it right on to stage, Vladimir. The build is green again! Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, February 21, 2014 1:53 AM To: Mandy Chung; Lindenmaier, Goetz; 'roger riggs'; Se?n Coffey; jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup Thank you, Mandy I pushed changes into jdk8u/jdk8u-dev/jdk and ppc-aix-port/stage/jdk Regards, Vladimir On 2/20/14 3:53 PM, Mandy Chung wrote: > You can put me as a reviewer if needed. > > Mandy > > On 2/20/2014 2:10 PM, Vladimir Kozlov wrote: >> Goetz, >> >> I can push it for you. We need official reviewer for changes. Roger is >> not Reviewer yet. Sean, can I put you or myself as reviewer in >> changeset info? >> >> Thanks, >> Vladimir >> >> On 2/20/14 1:54 PM, Lindenmaier, Goetz wrote: >>> Sean, Roger, >>> >>> thanks for looking at this an testing it! >>> It's good it's through JPRT, unfortunately I can't do that. >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: roger riggs [mailto:roger.riggs at oracle.com] >>> Sent: Thursday, February 20, 2014 7:07 PM >>> To: Se?n Coffey; Lindenmaier, Goetz; jdk8u-dev at openjdk.java.net; >>> ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: [8u20] Request for approval for CR 8031737: CHECK_NULL >>> and CHECK_EXCEPTION macros cleanup >>> >>> Hi Sean, >>> >>> Yes, these changes match the changes in JDK 9. >>> >>> Roger >>> >>> On 2/20/2014 12:06 PM, Se?n Coffey wrote: >>>> Goetz, >>>> >>>> I'm going to run the remainder of this backport patch thru JPRT to >>>> ensure it's not breaking anything (else!) >>>> Since the 8030875 fix appears to be coming back in two different >>>> fixes, I'm cc'ing Roger Riggs who was original author. >>>> >>>> Roger - can you review this request also ? >>>> >>>> Thanks, >>>> Sean. >>>> >>>> On 20/02/2014 15:15, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I request to backport >>>>> 8030875: Macros for checking and returning on exceptions >>>>> to jdk8u. >>>>> >>>>> This is needed, as >>>>> 8031737: CHECK_NULL and CHECK_EXCEPTION macros cleanup >>>>> was downported, that introduces the macros in jni_util.h, >>>>> while 8030875 removed them in various other files. >>>>> >>>>> Parts of this were already fixed in >>>>> 8034912: backport of 8031737 to jdk8u breaks linux buld. >>>>> but that fix is not complete. >>>>> Currently, the aix build is broken because of that. Also >>>>> on linux a warning is issued. For the traces see below. >>>>> >>>>> The change does not apply completely, as parts were done by >>>>> the other two mentioned. The remaining parts are here: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8030875-backport/ >>>>> The individual patches in this change are unchanged. >>>>> >>>>> The original change: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/c58c6b0fbe34 >>>>> The bugid: >>>>> https://bugs.openjdk.java.net/browse/JDK-8030875 >>>>> The change on top of this: >>>>> http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/fb89dc4fe8da >>>>> In jdk8u: >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/49f1903a21c1 >>>>> >>>>> The change applies to both, jdk8u-dev and ppc-aix-port/stage. I would >>>>> propose to push it to jdk8u-dev. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> The build error on aix: >>>>> >>>>> jni.cpp includes both, defines.h and jni_util.h. And both headers >>>>> define CHECK_NULL. >>>>> >>>>> /bin/xlC_r -D_BIG_ENDIAN -DAIX -DPPC64 -DDEBUG -DARCH='"ppc64"' >>>>> -Dppc64 -DRELEASE='"1.8.0-internal-fastdebug"' -I.../jdk/include >>>>> -I.../jdk/include/aix -I.../jdk/src/share/javavm/export >>>>> -I.../jdk/src/solaris/javavm/export -I.../jdk/src/share/native/common >>>>> -I.../jdk/src/solaris/native/common -qchars=signed -q64 -qfullpath >>>>> -qsaveopt -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -DSTDC -g >>>>> -qpic=large -I.../jdk/gensrc_headers -DNO_ZLIB -DUNPACK_JNI >>>>> -DFULL -O2 -DTHIS_FILE='"jni.cpp"' -c -qmakedep=gcc -MF >>>>> .../jdk/objs/libunpack/jni.d -o .../jdk/objs/libunpack/jni.o >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp >>>>> ".../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h", line >>>>> 161.9: 1540-0848 (S) The macro name "CHECK_NULL" is already defined >>>>> with a different definition. >>>>> ".../jdk/src/share/native/common/jni_util.h", line 286.9: 1540-0425 >>>>> (I) "CHECK_NULL" is defined on line 286 of >>>>> ".../jdk/src/share/native/common/jni_util.h". >>>>> >>>>> >>>>> The warning on linux: >>>>> >>>>> In file included from >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:39: >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/defines.h:161:1: >>>>> warning: "CHECK_NULL" redefined >>>>> In file included from >>>>> .../jdk/src/share/native/com/sun/java/util/jar/pack/jni.cpp:37: >>>>> .../jdk/src/share/native/common/jni_util.h:286:1: warning: this is >>>>> the location of the previous definition >>>>> echo "Compiling utils.cpp (for libunpack.so)" >>>> >>> > From christian.thalinger at oracle.com Fri Feb 21 14:54:21 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 21 Feb 2014 14:54:21 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <5307A8B5.2050307@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> Message-ID: On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov wrote: > Lets discuss it on hotspot-dev. > > Note the current hashtable allocates only in c_heap. Albert added hashtable which can allocate in thread local resource area for temporary table and c_heap for long live table. > > Albert, > > So you restored code in dependencies.?pp to one before 7194669 fix. Right? > > I think you need to follow GrowableArray example to name parameter "bool C_heap = false" instead of "bool resource_mark". It should be saved in a field because you need to free c_heap in destructor if C-heap is used: > > ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } > > Also I think you should avoid call to contains(item) in add() to avoid doing the same thing twice. ?and you should stick to either item or element: + template bool GenericHashtable::add(T* item) { + template bool GenericHashtable::contains(T* element) { > > You should implement remove(). > > Thanks, > Vladimir > > On 2/21/14 12:04 AM, Albert wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >> >> Problem: The problem is that the patch (7194669) - which was supposed to >> speed-up dependency checking >> causes a performance regression. The reason for the >> performance regression is that most dependencies >> are unique, so we have the overhead of determining if >> the dependency is already checked plus the >> overhead of dependency checking. The overhead of >> searching is significant, since we perform >> a linear search on 6000+ items each time. >> >> Solution: Use a hashtable instead of linear search to lookup already >> checked dependencies. The new hashtable >> is very rudimentary. It provides only the required >> functionality to solve this bug. However, the functionality >> can be easily extended as needed. >> >> Testing: jprt, failing test case, nashorn. The failing test case >> completes in approx. the same time as before 7194669. >> For nashorn + Octane, this patch yields the following >> times spent for dependency checking: >> >> with this patch: 844s >> 7194669: 1080s >> before 7194669: 5223s >> >> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >> >> Thanks, >> Albert >> From vladimir.kozlov at oracle.com Fri Feb 21 17:39:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 21 Feb 2014 17:39:27 -0800 Subject: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> Message-ID: <5307FFCF.1040500@oracle.com> Hi, Goetz Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? I know that ppc use C++ Interpreter in our sources but you will need it anyway later. The code in frame.inline.hpp should be also guarded with !PPC32: #if defined(CC_INTERP) && !defined(PPC32) Changes look reasonable. I did closed changes and it is working. I am testing it in JPRT now. Thanks, Vladimir On 2/20/14 2:58 AM, Lindenmaier, Goetz wrote: > Hi, > > Access to the tmp_oop in a frame is done with several #ifdefs > distinguishing the platforms and interpreters. The PPC64 template > interpreter would introduce another one. > > This change avoids the #ifs by introducing the accessor function > interpreter_frame_temp_oop_addr() as for many other fields in the frame. > > Unfortunately this will require to implement interpreter_frame_temp_oop_addr() > in the closed sources I can not do. As the platform file for frame.hpp has > to be changed anyways, I propose to also move > #ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > #endif > from frame.hpp into frame_ppc.hpp in the closed port. > > Please review and test this change. > > http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ > > This change should also go to jdk8u. It?s fine if this happens some > later if the path via ppc-aix-port/stage is not possible due > to the closed change. > > Best regards, > > Goetz. > From goetz.lindenmaier at sap.com Sat Feb 22 09:24:39 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 22 Feb 2014 17:24:39 +0000 Subject: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. In-Reply-To: <5307FFCF.1040500@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> <5307FFCF.1040500@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA4145@DEWDFEMB12A.global.corp.sap> Hi Vladimir, > Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? I will add that to the ppc64 frames file with all the changes required for the template interpreter. > #if defined(CC_INTERP) && !defined(PPC32) If we need another test for platform here, shouldn't we put it into the platform files, too? Is there a ppc32 with cc_interp? Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Saturday, February 22, 2014 2:39 AM To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. Hi, Goetz Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? I know that ppc use C++ Interpreter in our sources but you will need it anyway later. The code in frame.inline.hpp should be also guarded with !PPC32: #if defined(CC_INTERP) && !defined(PPC32) Changes look reasonable. I did closed changes and it is working. I am testing it in JPRT now. Thanks, Vladimir On 2/20/14 2:58 AM, Lindenmaier, Goetz wrote: > Hi, > > Access to the tmp_oop in a frame is done with several #ifdefs > distinguishing the platforms and interpreters. The PPC64 template > interpreter would introduce another one. > > This change avoids the #ifs by introducing the accessor function > interpreter_frame_temp_oop_addr() as for many other fields in the frame. > > Unfortunately this will require to implement interpreter_frame_temp_oop_addr() > in the closed sources I can not do. As the platform file for frame.hpp has > to be changed anyways, I propose to also move > #ifdef PPC32 > oop* interpreter_frame_mirror_addr() const; > #endif > from frame.hpp into frame_ppc.hpp in the closed port. > > Please review and test this change. > > http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ > > This change should also go to jdk8u. It's fine if this happens some > later if the path via ppc-aix-port/stage is not possible due > to the closed change. > > Best regards, > > Goetz. > From stefan.karlsson at oracle.com Mon Feb 24 01:44:48 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 24 Feb 2014 10:44:48 +0100 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print Message-ID: <530B1490.3030304@oracle.com> Hi all, Please, review this change to let java_lang_String::print take a raw String oop instead of a Handle to a String oop. This change makes java_lang_String::print callable from code that has no HandleMark setup. E.g. when calling from a debugger. Webrev: http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8035648 thanks, StefanK From neugens at redhat.com Mon Feb 24 03:00:25 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2014 12:00:25 +0100 Subject: Bring Zero to llvm 3.4 Message-ID: <1393239625.3873.13.camel@galactica.localdomain> Hi all! I have a small patch to be able to compile Zero with llvm 3.4: http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/ The patch is relative to OpenJDK 8 only for the moment, I'll work next on an OpenJDK 9 patch. Can someone please help me get this reviewed and pushed? Thanks, Mario From david.holmes at oracle.com Mon Feb 24 04:11:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Feb 2014 22:11:56 +1000 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530B1490.3030304@oracle.com> References: <530B1490.3030304@oracle.com> Message-ID: <530B370C.6090808@oracle.com> Stefan, On 24/02/2014 7:44 PM, Stefan Karlsson wrote: > Hi all, > > Please, review this change to let java_lang_String::print take a raw > String oop instead of a Handle to a String oop. This change makes > java_lang_String::print callable from code that has no HandleMark setup. I don't think you can do that. The printing code can encounter a safepoint and block thus allowing a raw oop to be exposed over a potential GC point. David > E.g. when calling from a debugger. > > Webrev: > http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8035648 > > thanks, > StefanK From mikael.gerdin at oracle.com Mon Feb 24 05:08:01 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 24 Feb 2014 14:08:01 +0100 Subject: Bring Zero to llvm 3.4 In-Reply-To: <1393239625.3873.13.camel@galactica.localdomain> References: <1393239625.3873.13.camel@galactica.localdomain> Message-ID: <1489929.lba08dEc0C@mgerdin03> Hi Mario, On Monday 24 February 2014 12.00.25 Mario Torre wrote: > Hi all! > > I have a small patch to be able to compile Zero with llvm 3.4: > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/ http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/hotspot.changeset is empty so it's hard to download the change in its entirety. > > The patch is relative to OpenJDK 8 only for the moment, I'll work next > on an OpenJDK 9 patch. The hotspot development repos are based on 9 now, so the change should be pushed to 9 and then backported to 8. /Mikael > > Can someone please help me get this reviewed and pushed? > > Thanks, > Mario From stefan.karlsson at oracle.com Mon Feb 24 05:08:41 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 24 Feb 2014 14:08:41 +0100 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530B370C.6090808@oracle.com> References: <530B1490.3030304@oracle.com> <530B370C.6090808@oracle.com> Message-ID: <530B4459.1060106@oracle.com> On 2014-02-24 13:11, David Holmes wrote: > Stefan, > > On 24/02/2014 7:44 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this change to let java_lang_String::print take a raw >> String oop instead of a Handle to a String oop. This change makes >> java_lang_String::print callable from code that has no HandleMark setup. > > I don't think you can do that. The printing code can encounter a > safepoint and block thus allowing a raw oop to be exposed over a > potential GC point. If that's the case, then the code was already buggy before my change: 1) Before the patch the first thing we did was to convert the Handle to a raw oop. IMHO, there's no difference in safepoint safeness here. void java_lang_String::print(Handle java_string, outputStream* st) { oop obj = java_string(); 2) the 'value' object would also be susceptible to this kind of bug: for (int index = 0; index < length; index++) { st->print("%c", value->char_at(index + offset)); } Do you know of an implementation of outputStream that allows us to block for a safepoint? If not, would you be fine with the change if I add a No_Safepoint_Verifier? thanks, StefanK > > > David > >> E.g. when calling from a debugger. >> >> Webrev: >> http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ >> >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8035648 >> >> thanks, >> StefanK From neugens at redhat.com Mon Feb 24 06:06:06 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2014 15:06:06 +0100 Subject: Bring Zero to llvm 3.4 In-Reply-To: <1489929.lba08dEc0C@mgerdin03> References: <1393239625.3873.13.camel@galactica.localdomain> <1489929.lba08dEc0C@mgerdin03> Message-ID: <1393250766.3873.16.camel@galactica.localdomain> On Mon, 2014-02-24 at 14:08 +0100, Mikael Gerdin wrote: > Hi Mario, Hello Mikael, Thanks for the quick answer. > On Monday 24 February 2014 12.00.25 Mario Torre wrote: > > Hi all! > > > > I have a small patch to be able to compile Zero with llvm 3.4: > > > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/ > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/hotspot.changeset > is empty so it's hard to download the change in its entirety. Interesting... Here's another link to the patch itself: http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/shark-patches.patch > > > > The patch is relative to OpenJDK 8 only for the moment, I'll work next > > on an OpenJDK 9 patch. > > The hotspot development repos are based on 9 now, so the change should be > pushed to 9 and then backported to 8. Ok then, I'll make the 9 fix and get back at you again! Cheers, Mario From mikael.gerdin at oracle.com Mon Feb 24 06:50:19 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 24 Feb 2014 15:50:19 +0100 Subject: Bring Zero to llvm 3.4 In-Reply-To: <1393250766.3873.16.camel@galactica.localdomain> References: <1393239625.3873.13.camel@galactica.localdomain> <1489929.lba08dEc0C@mgerdin03> <1393250766.3873.16.camel@galactica.localdomain> Message-ID: <1445297.1Zhykx3zvx@mgerdin03> Hi, On Monday 24 February 2014 15.06.06 Mario Torre wrote: > On Mon, 2014-02-24 at 14:08 +0100, Mikael Gerdin wrote: > > Hi Mario, > > Hello Mikael, > > Thanks for the quick answer. > > > On Monday 24 February 2014 12.00.25 Mario Torre wrote: > > > Hi all! > > > > > > I have a small patch to be able to compile Zero with llvm 3.4: > > > > > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/ > > > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/hotspot.chan > > geset is empty so it's hard to download the change in its entirety. > > Interesting... Indeed, what version of webrev are you using? The .changeset file created by recent versions of webrev has the advantage that it contains HG meta-information about which change the patch was created from. > > Here's another link to the patch itself: > > http://cr.openjdk.java.net/~neugens/zero-2014-02-24/webrev.01/shark-patches. > patch > > > The patch is relative to OpenJDK 8 only for the moment, I'll work next > > > on an OpenJDK 9 patch. > > > > The hotspot development repos are based on 9 now, so the change should be > > pushed to 9 and then backported to 8. > > Ok then, I'll make the 9 fix and get back at you again! Great! /Mikael > > Cheers, > Mario From neugens at redhat.com Mon Feb 24 07:39:34 2014 From: neugens at redhat.com (Mario Torre) Date: Mon, 24 Feb 2014 16:39:34 +0100 Subject: Bring Zero to llvm 3.4 In-Reply-To: <1445297.1Zhykx3zvx@mgerdin03> References: <1393239625.3873.13.camel@galactica.localdomain> <1489929.lba08dEc0C@mgerdin03> <1393250766.3873.16.camel@galactica.localdomain> <1445297.1Zhykx3zvx@mgerdin03> Message-ID: <1393256374.11941.3.camel@galactica.localdomain> On Mon, 2014-02-24 at 15:50 +0100, Mikael Gerdin wrote: > > Interesting... > > Indeed, what version of webrev are you using? > The .changeset file created by recent versions of webrev has the advantage > that it contains HG meta-information about which change the patch was created > from. I used the one that comes from within the JDK8 repository (cloned sometime on Friday). I run webrev from a mercurial patch queue with the applied patch, which should be visible as a committed changeset I think. Cheers, Mario From cnewland at chrisnewland.com Thu Feb 20 13:46:14 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Thu, 20 Feb 2014 21:46:14 -0000 Subject: hotspot.log overlapping log statements (JITWatch) Message-ID: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> Hi all, I've written a visualiser/analyser for the hotspot.log JIT compilation log called JITWatch[1] and I'm encountering problems with log statements from various parts of the VM/HotSpot overlapping and producing garbled output in hotspot.log[2]. For example, if I combine the VM switches -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly then I get overlap between classloading statements, log compilation XML, and disassembled native code: Decoding compiled method 0x009dfec8: Code: [Entry Point] [Constants] # {method} 'hashCode' '()I' in 'java/lang/String' # [sp+0x20] (sp of caller) 0x009dffc0: nop 0x009dffc1: nop 0x009dffc2: nop <-- assembly interrupted by XML [Loaded java.lang.Enum <-- assembly interrupted by classloader 0x009dffc3: nop 0x009dffc4: nop 0x009dffc5: from shared objects file] nop 0x009dffc6: nop I couldn't find this in the Oracle or OpenJDK bug trackers and was wondering if this is a known problem and if it is fixable? It seems to happen fairly infrequently but means that JITWatch can't parse the compilation information when the garbling occurs. Thanks for any pointers you can give me. Kind regards, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch/wiki [2] https://github.com/AdoptOpenJDK/jitwatch/issues/3 From vladimir.kozlov at oracle.com Mon Feb 24 12:11:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Feb 2014 12:11:53 -0800 Subject: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA4145@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> <5307FFCF.1040500@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA4145@DEWDFEMB12A.global.corp.sap> Message-ID: <530BA789.2090707@oracle.com> On 2/22/14 9:24 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > >> Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? > I will add that to the ppc64 frames file with all the > changes required for the template interpreter. Okay > >> #if defined(CC_INTERP) && !defined(PPC32) > If we need another test for platform here, shouldn't > we put it into the platform files, too? > Is there a ppc32 with cc_interp? I can't say but if you look on the original code in frame.cpp the code for ppc32 executed for both C++ and template interpreter. It is different from interpreter_frame_temp_oop_addr() defined now in frame.inline.hpp. And we can't redefine it in platform specific file since it is the same scope. Thanks, Vladimir > > Best regards, > Goetz. > > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Saturday, February 22, 2014 2:39 AM > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. > > Hi, Goetz > > Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? > I know that ppc use C++ Interpreter in our sources but you will need it > anyway later. > > The code in frame.inline.hpp should be also guarded with !PPC32: > > #if defined(CC_INTERP) && !defined(PPC32) > > Changes look reasonable. I did closed changes and it is working. I am > testing it in JPRT now. > > Thanks, > Vladimir > > On 2/20/14 2:58 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> Access to the tmp_oop in a frame is done with several #ifdefs >> distinguishing the platforms and interpreters. The PPC64 template >> interpreter would introduce another one. >> >> This change avoids the #ifs by introducing the accessor function >> interpreter_frame_temp_oop_addr() as for many other fields in the frame. >> >> Unfortunately this will require to implement interpreter_frame_temp_oop_addr() >> in the closed sources I can not do. As the platform file for frame.hpp has >> to be changed anyways, I propose to also move >> #ifdef PPC32 >> oop* interpreter_frame_mirror_addr() const; >> #endif >> from frame.hpp into frame_ppc.hpp in the closed port. >> >> Please review and test this change. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ >> >> This change should also go to jdk8u. It's fine if this happens some >> later if the path via ppc-aix-port/stage is not possible due >> to the closed change. >> >> Best regards, >> >> Goetz. >> From vladimir.kozlov at oracle.com Mon Feb 24 15:31:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 24 Feb 2014 15:31:25 -0800 Subject: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. In-Reply-To: <530BA789.2090707@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA3762@DEWDFEMB12A.global.corp.sap> <5307FFCF.1040500@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA4145@DEWDFEMB12A.global.corp.sap> <530BA789.2090707@oracle.com> Message-ID: <530BD64D.5040907@oracle.com> If you are suggesting to move all definitions (for C++ and template interpreter) of interpreter_frame_temp_oop_addr() into platform specific files, I agree with that. Thanks, Vladimir On 2/24/14 12:11 PM, Vladimir Kozlov wrote: > On 2/22/14 9:24 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >>> Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? >> I will add that to the ppc64 frames file with all the >> changes required for the template interpreter. > > Okay > >> >>> #if defined(CC_INTERP) && !defined(PPC32) >> If we need another test for platform here, shouldn't >> we put it into the platform files, too? >> Is there a ppc32 with cc_interp? > > I can't say but if you look on the original code in frame.cpp the code > for ppc32 executed for both C++ and template interpreter. It is > different from interpreter_frame_temp_oop_addr() defined now in > frame.inline.hpp. And we can't redefine it in platform specific file > since it is the same scope. > > Thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Saturday, February 22, 2014 2:39 AM >> To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; >> ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR(S): 8035396: Introduce accessor for tmp_oop in frame. >> >> Hi, Goetz >> >> Why you did not add it to src/cpu/ppc/vm/frame_ppc.inline.hpp? >> I know that ppc use C++ Interpreter in our sources but you will need it >> anyway later. >> >> The code in frame.inline.hpp should be also guarded with !PPC32: >> >> #if defined(CC_INTERP) && !defined(PPC32) >> >> Changes look reasonable. I did closed changes and it is working. I am >> testing it in JPRT now. >> >> Thanks, >> Vladimir >> >> On 2/20/14 2:58 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> Access to the tmp_oop in a frame is done with several #ifdefs >>> distinguishing the platforms and interpreters. The PPC64 template >>> interpreter would introduce another one. >>> >>> This change avoids the #ifs by introducing the accessor function >>> interpreter_frame_temp_oop_addr() as for many other fields in the frame. >>> >>> Unfortunately this will require to implement >>> interpreter_frame_temp_oop_addr() >>> in the closed sources I can not do. As the platform file for >>> frame.hpp has >>> to be changed anyways, I propose to also move >>> #ifdef PPC32 >>> oop* interpreter_frame_mirror_addr() const; >>> #endif >>> from frame.hpp into frame_ppc.hpp in the closed port. >>> >>> Please review and test this change. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8035396-1-tmpOop/ >>> >>> This change should also go to jdk8u. It's fine if this happens some >>> later if the path via ppc-aix-port/stage is not possible due >>> to the closed change. >>> >>> Best regards, >>> >>> Goetz. >>> From david.holmes at oracle.com Mon Feb 24 18:37:39 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Feb 2014 12:37:39 +1000 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530B4459.1060106@oracle.com> References: <530B1490.3030304@oracle.com> <530B370C.6090808@oracle.com> <530B4459.1060106@oracle.com> Message-ID: <530C01F3.4000101@oracle.com> On 24/02/2014 11:08 PM, Stefan Karlsson wrote: > > On 2014-02-24 13:11, David Holmes wrote: >> Stefan, >> >> On 24/02/2014 7:44 PM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please, review this change to let java_lang_String::print take a raw >>> String oop instead of a Handle to a String oop. This change makes >>> java_lang_String::print callable from code that has no HandleMark setup. >> >> I don't think you can do that. The printing code can encounter a >> safepoint and block thus allowing a raw oop to be exposed over a >> potential GC point. > > If that's the case, then the code was already buggy before my change: > > 1) Before the patch the first thing we did was to convert the Handle to > a raw oop. IMHO, there's no difference in safepoint safeness here. > void java_lang_String::print(Handle java_string, outputStream* st) { > oop obj = java_string(); > > 2) the 'value' object would also be susceptible to this kind of bug: > for (int index = 0; index < length; index++) { > st->print("%c", value->char_at(index + offset)); > } > > Do you know of an implementation of outputStream that allows us to block > for a safepoint? If not, would you be fine with the change if I add a > No_Safepoint_Verifier? Sorry for the noise - I was misremembering how outputstream locking was performed. David ----- > thanks, > StefanK > >> >> >> David >> >>> E.g. when calling from a debugger. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ >>> >>> RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8035648 >>> >>> thanks, >>> StefanK > From david.holmes at oracle.com Mon Feb 24 22:54:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Feb 2014 16:54:12 +1000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> Message-ID: <530C3E14.6030308@oracle.com> Hi Chris, If all the trace/logging output is directed to the default output stream (or the same file) then they will be intermixed. Fixing this would be non-trivial due to the need for explicit locking around compound trace/logging statements; and locking in tracing/log output can itself be problematic. Using different log files where possible would assist, but then you have no temporal relationship between the different entries. David On 21/02/2014 7:46 AM, Chris Newland wrote: > Hi all, > > I've written a visualiser/analyser for the hotspot.log JIT compilation log > called JITWatch[1] and I'm encountering problems with log statements from > various parts of the VM/HotSpot overlapping and producing garbled output > in hotspot.log[2]. > > For example, if I combine the VM switches > > -XX:+UnlockDiagnosticVMOptions > -XX:+TraceClassLoading > -XX:+LogCompilation > -XX:+PrintAssembly > > then I get overlap between classloading statements, log compilation XML, > and disassembled native code: > > Decoding compiled method 0x009dfec8: > Code: > [Entry Point] > [Constants] > # {method} 'hashCode' '()I' in 'java/lang/String' > # [sp+0x20] (sp of caller) > 0x009dffc0: nop > 0x009dffc1: nop > 0x009dffc2: nop > <-- assembly interrupted by XML > [Loaded java.lang.Enum <-- assembly interrupted by classloader > > > 0x009dffc3: nop > 0x009dffc4: nop > 0x009dffc5: > > from shared objects file] > > nop > 0x009dffc6: nop > > I couldn't find this in the Oracle or OpenJDK bug trackers and was > wondering if this is a known problem and if it is fixable? > > It seems to happen fairly infrequently but means that JITWatch can't parse > the compilation information when the garbling occurs. > > Thanks for any pointers you can give me. > > Kind regards, > > Chris > @chriswhocodes > > [1] https://github.com/AdoptOpenJDK/jitwatch/wiki > [2] https://github.com/AdoptOpenJDK/jitwatch/issues/3 > > > > From goetz.lindenmaier at sap.com Tue Feb 25 03:42:21 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Feb 2014 11:42:21 +0000 Subject: 8030350 breaks build with older gccs. Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> Hi Mike, your change breaks the build with older gccs as they don't know the option "-Wno-error=format-nonliteral" I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. Gcc 4.3.4 works. In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected this issue already, or there is a bug to fix this? I would propose to fix this by either adapting hotspot code not to issue these warnings: http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ or to adapt the makefiles not to use the warning on older gccs: http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ If you give me advice what you would prefer, I will open a bug and send a RFR. Best regards, Goetz. From david.holmes at oracle.com Tue Feb 25 04:54:56 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 25 Feb 2014 22:54:56 +1000 Subject: 8030350 breaks build with older gccs. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> Message-ID: <530C92A0.6070407@oracle.com> On 25/02/2014 9:42 PM, Lindenmaier, Goetz wrote: > Hi Mike, > > your change breaks the build with older gccs as they don't know the option "-Wno-error=format-nonliteral" > > I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. > Gcc 4.3.4 works. > > In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected > this issue already, or there is a bug to fix this? > > I would propose to fix this by either adapting hotspot code not to issue these warnings: I think Mike already did this for hotspot. > http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ > or to adapt the makefiles not to use the warning on older gccs: > http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ Or accept that there is a minimum gcc level expected as the build tool. David ----- > If you give me advice what you would prefer, I will open a bug and send > a RFR. > > Best regards, > Goetz. > > From albert.noll at oracle.com Tue Feb 25 05:04:11 2014 From: albert.noll at oracle.com (Albert) Date: Tue, 25 Feb 2014 14:04:11 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> Message-ID: <530C94CB.3030800@oracle.com> Hi, Vladimir, Christian, Vitaly, thanks for looking at this and your feedback. @Vladimir: No, this change is based on the version of 7194669. However, the diff to before 7194669 are mainly code refactorings, which make the code more readable (for me). I have changed the parameter name, (bool C_heap = false), adapted the 'add' function according to your suggestion, and implemented the hashtable destructor as well as the remove function. @Christian: This for noticing this inconsistency. I fixed the parameter names @Vitaly: I would prefer to leave the size parameter as it is now. While we would save some instructions, I think that specifying the size of the hashtable where it is used makes the code more readable. Shouldn't we, in general, try to avoid hash table sizes that are an exact power of 2? Here is the new webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ Best, Albert On 02/21/2014 11:54 PM, Christian Thalinger wrote: > On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov wrote: > >> Lets discuss it on hotspot-dev. >> >> Note the current hashtable allocates only in c_heap. Albert added hashtable which can allocate in thread local resource area for temporary table and c_heap for long live table. >> >> Albert, >> >> So you restored code in dependencies.?pp to one before 7194669 fix. Right? >> >> I think you need to follow GrowableArray example to name parameter "bool C_heap = false" instead of "bool resource_mark". It should be saved in a field because you need to free c_heap in destructor if C-heap is used: >> >> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >> >> Also I think you should avoid call to contains(item) in add() to avoid doing the same thing twice. > ?and you should stick to either item or element: > > + template bool GenericHashtable::add(T* item) { > + template bool GenericHashtable::contains(T* element) { > >> You should implement remove(). >> >> Thanks, >> Vladimir >> >> On 2/21/14 12:04 AM, Albert wrote: >>> Hi, >>> >>> could I get reviews for this small patch? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>> >>> Problem: The problem is that the patch (7194669) - which was supposed to >>> speed-up dependency checking >>> causes a performance regression. The reason for the >>> performance regression is that most dependencies >>> are unique, so we have the overhead of determining if >>> the dependency is already checked plus the >>> overhead of dependency checking. The overhead of >>> searching is significant, since we perform >>> a linear search on 6000+ items each time. >>> >>> Solution: Use a hashtable instead of linear search to lookup already >>> checked dependencies. The new hashtable >>> is very rudimentary. It provides only the required >>> functionality to solve this bug. However, the functionality >>> can be easily extended as needed. >>> >>> Testing: jprt, failing test case, nashorn. The failing test case >>> completes in approx. the same time as before 7194669. >>> For nashorn + Octane, this patch yields the following >>> times spent for dependency checking: >>> >>> with this patch: 844s >>> 7194669: 1080s >>> before 7194669: 5223s >>> >>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>> >>> Thanks, >>> Albert >>> From stefan.karlsson at oracle.com Tue Feb 25 05:43:49 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 25 Feb 2014 14:43:49 +0100 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function Message-ID: <530C9E15.8030305@oracle.com> Hi all, Please, review this small patch to add Klass::oop_is_instanceClassLoader(). Webrev: http://cr.openjdk.java.net/~stefank/8035746/webrev.00 RFE: https://bugs.openjdk.java.net/browse/JDK-8035746 thanks, StefanK From aph at redhat.com Tue Feb 25 06:11:21 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Feb 2014 14:11:21 +0000 Subject: Memory ordering in C2 Message-ID: <530CA489.5060805@redhat.com> This is related to the discussion about memory ordering raised by the PPC team, but it's not the same. Aarch64 has a weakly-ordered memory system, so needs memory barriers. It also has load acquire and store release instructions, and I would quite like to use these for volatile fields. I have already made sure that these instructions have the correct semantics. However, I can't do that in the obvious way (by generating ld.acq and st.rel and) defining empty versions of MemBarAcquire and MemBarRelease in the ADfile because MemBarRelease isn't used only for volatile fields. It's also used for constructor barriers, and I need those. A related problem is that C2 sprinkles these quite expensive barriers in a number of other places, particularly around locks and atomic operations. This is painful because the atomic operations already have a standard efficient sequence of instructions that has the required semantics. It seems to me that the back end needs to have far more control over what barriers are emitted, and when. I would like to be able to control all of the explicit barriers in a machine-dependent way. A good start would be if I could disable barriers around locks without affecting other places that really need them. I don't want to have to scribble #ifdef AARCH64 all over the machine-independent code. I suppose the easiest way to do this would be to add a few new barrier types. Thoughts? Thank you, Andrew. From vitalyd at gmail.com Tue Feb 25 06:13:15 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 25 Feb 2014 09:13:15 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530C94CB.3030800@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> Message-ID: Hi Albert, There's currently one instantiation of the hashtable that looks like this: new GenericHashtable(11027); With size as template, it would be: new GenericHashtable(); So the size is specified in the same place (in terms of reading the code). Your call though, this was just a suggestion. Power of 2 hashtable sizes are an issue with poor quality hash functions (I.e. ones that don't differ in low order bits), but if the hash function is decent it shouldn't be an issue. Prime size is used to mitigate that, but there are other techniques that allow 2^n sizing (e.g. supplementary hash function applied on top of hash code coming from original key object). FWIW, JDK's HashMap is 2^n sized with supplementary hashing. Again, just a suggestion - it probably won't make a substantial difference here. Thanks Sent from my phone On Feb 25, 2014 8:06 AM, "Albert" wrote: > Hi, > > Vladimir, Christian, Vitaly, thanks for looking at this and your feedback. > > @Vladimir: > No, this change is based on the version of 7194669. However, > the diff to before 7194669 are mainly code refactorings, which make the > code more readable (for me). > > I have changed the parameter name, (bool C_heap = false), adapted the > 'add' function > according to your suggestion, and implemented the hashtable destructor as > well as the > remove function. > > @Christian: > This for noticing this inconsistency. I fixed the parameter names > > @Vitaly: > I would prefer to leave the size parameter as it is now. While we would > save some instructions, > I think that specifying the size of the hashtable where it is used makes > the code more readable. > > Shouldn't we, in general, try to avoid hash table sizes that are an exact > power of 2? > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ > > Best, > Albert > > > On 02/21/2014 11:54 PM, Christian Thalinger wrote: > >> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >> wrote: >> >> Lets discuss it on hotspot-dev. >>> >>> Note the current hashtable allocates only in c_heap. Albert added >>> hashtable which can allocate in thread local resource area for temporary >>> table and c_heap for long live table. >>> >>> Albert, >>> >>> So you restored code in dependencies.?pp to one before 7194669 fix. >>> Right? >>> >>> I think you need to follow GrowableArray example to name parameter "bool >>> C_heap = false" instead of "bool resource_mark". It should be saved in a >>> field because you need to free c_heap in destructor if C-heap is used: >>> >>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>> >>> Also I think you should avoid call to contains(item) in add() to avoid >>> doing the same thing twice. >>> >> ...and you should stick to either item or element: >> >> + template bool GenericHashtable::add(T* item) { >> + template bool GenericHashtable::contains(T* >> element) { >> >> You should implement remove(). >>> >>> Thanks, >>> Vladimir >>> >>> On 2/21/14 12:04 AM, Albert wrote: >>> >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>> >>>> Problem: The problem is that the patch (7194669) - which was supposed to >>>> speed-up dependency checking >>>> causes a performance regression. The reason for the >>>> performance regression is that most dependencies >>>> are unique, so we have the overhead of determining if >>>> the dependency is already checked plus the >>>> overhead of dependency checking. The overhead of >>>> searching is significant, since we perform >>>> a linear search on 6000+ items each time. >>>> >>>> Solution: Use a hashtable instead of linear search to lookup already >>>> checked dependencies. The new hashtable >>>> is very rudimentary. It provides only the required >>>> functionality to solve this bug. However, the functionality >>>> can be easily extended as needed. >>>> >>>> Testing: jprt, failing test case, nashorn. The failing test case >>>> completes in approx. the same time as before 7194669. >>>> For nashorn + Octane, this patch yields the following >>>> times spent for dependency checking: >>>> >>>> with this patch: 844s >>>> 7194669: 1080s >>>> before 7194669: 5223s >>>> >>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>> >>>> Thanks, >>>> Albert >>>> >>>> > From mikael.gerdin at oracle.com Tue Feb 25 06:15:32 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 25 Feb 2014 15:15:32 +0100 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <530C9E15.8030305@oracle.com> References: <530C9E15.8030305@oracle.com> Message-ID: <3863846.75HEyYHLZJ@mgerdin03> Hi Stefan, On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: > Hi all, > > Please, review this small patch to add Klass::oop_is_instanceClassLoader(). > > Webrev: > http://cr.openjdk.java.net/~stefank/8035746/webrev.00 Code change looks good. There are a couple of places where we check whether or not a Klass is a ClassLoader, something like: if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) These places could now be changed to klass->oop_is_ClassLoader(), saving a possibly expensive subtype check. Should we file an RFE to change these or do you want to change them straight away? /Mikael > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8035746 > > thanks, > StefanK From goetz.lindenmaier at sap.com Tue Feb 25 07:20:25 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Feb 2014 15:20:25 +0000 Subject: Memory ordering in C2 In-Reply-To: <530CA489.5060805@redhat.com> References: <530CA489.5060805@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> Hi, We added a a few new node types in this change: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/50fdb38839eb This solved the issue that we implement MemBarAcquire empty. But yes, we would appreciate further modularization in this direction. We proposed similar stuff in this mail: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013384.html Actually, we would like more barrier nodes in some places (around CompareAndSwap) because we issue sync instructions in those nodes. If they are extra nodes, we can optimize them. At other places, we would like less ... ;) And I guess x86 & friends, that always use empty nodes could profit, too. Further we would like to have explicit specification of the required barriers in the nodes (Only one node, but listing the barriers required (StoreStore | StoreLoad etc)). Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Dienstag, 25. Februar 2014 15:11 To: hotspot-dev Source Developers Subject: Memory ordering in C2 This is related to the discussion about memory ordering raised by the PPC team, but it's not the same. Aarch64 has a weakly-ordered memory system, so needs memory barriers. It also has load acquire and store release instructions, and I would quite like to use these for volatile fields. I have already made sure that these instructions have the correct semantics. However, I can't do that in the obvious way (by generating ld.acq and st.rel and) defining empty versions of MemBarAcquire and MemBarRelease in the ADfile because MemBarRelease isn't used only for volatile fields. It's also used for constructor barriers, and I need those. A related problem is that C2 sprinkles these quite expensive barriers in a number of other places, particularly around locks and atomic operations. This is painful because the atomic operations already have a standard efficient sequence of instructions that has the required semantics. It seems to me that the back end needs to have far more control over what barriers are emitted, and when. I would like to be able to control all of the explicit barriers in a machine-dependent way. A good start would be if I could disable barriers around locks without affecting other places that really need them. I don't want to have to scribble #ifdef AARCH64 all over the machine-independent code. I suppose the easiest way to do this would be to add a few new barrier types. Thoughts? Thank you, Andrew. From aph at redhat.com Tue Feb 25 07:30:17 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Feb 2014 15:30:17 +0000 Subject: Memory ordering in C2 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> References: <530CA489.5060805@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> Message-ID: <530CB709.1040205@redhat.com> Hi, On 02/25/2014 03:20 PM, Lindenmaier, Goetz wrote: > We added a a few new node types in this change: > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/50fdb38839eb > This solved the issue that we implement MemBarAcquire empty. Ah yes. Good, I can use that too. > But yes, we would appreciate further modularization in this direction. > We proposed similar stuff in this mail: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013384.html Thanks. I saw that at the time but didn't quite realize how similar it was to my own issues. > Actually, we would like more barrier nodes in some places (around > CompareAndSwap) because we issue sync instructions in those nodes. > If they are extra nodes, we can optimize them. At other places, we > would like less ... ;) >From what I've seen, C2 is enthusiastically emitting barrier nodes around CompareAndSwap, so I'm not quite sure what this means. > And I guess x86 & friends, that always use empty nodes could profit, too. > > Further we would like to have explicit specification of the required > barriers in the nodes (Only one node, but listing the barriers > required (StoreStore | StoreLoad etc)). That would indeed be nice, but difficult. Andrew. From goetz.lindenmaier at sap.com Tue Feb 25 07:41:12 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 25 Feb 2014 15:41:12 +0000 Subject: Memory ordering in C2 In-Reply-To: <530CB709.1040205@redhat.com> References: <530CA489.5060805@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> <530CB709.1040205@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA46C6@DEWDFEMB12A.global.corp.sap> Hi, > From what I've seen, C2 is enthusiastically emitting barrier nodes > around CompareAndSwap, so I'm not quite sure what this means. Yes, you are right ... that's again because we implement MemBArAcquire empty, but after the CompareAndSwap we need one, so we had to add it in the node ;) So same issue, distinguishing nodes would help! The bad thing is that MemBarAcquire is implemented empty, that spoils the other uses. If there is a way to avoid MemBarAcquire where it needs to be empty (after volatile load), then it can be implemented properly ... Best regards, Goetz. -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Dienstag, 25. Februar 2014 16:30 To: Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: Memory ordering in C2 Hi, On 02/25/2014 03:20 PM, Lindenmaier, Goetz wrote: > We added a a few new node types in this change: > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/50fdb38839eb > This solved the issue that we implement MemBarAcquire empty. Ah yes. Good, I can use that too. > But yes, we would appreciate further modularization in this direction. > We proposed similar stuff in this mail: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013384.html Thanks. I saw that at the time but didn't quite realize how similar it was to my own issues. > Actually, we would like more barrier nodes in some places (around > CompareAndSwap) because we issue sync instructions in those nodes. > If they are extra nodes, we can optimize them. At other places, we > would like less ... ;) >From what I've seen, C2 is enthusiastically emitting barrier nodes around CompareAndSwap, so I'm not quite sure what this means. > And I guess x86 & friends, that always use empty nodes could profit, too. > > Further we would like to have explicit specification of the required > barriers in the nodes (Only one node, but listing the barriers > required (StoreStore | StoreLoad etc)). That would indeed be nice, but difficult. Andrew. From stefan.karlsson at oracle.com Tue Feb 25 09:50:43 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 25 Feb 2014 18:50:43 +0100 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <3863846.75HEyYHLZJ@mgerdin03> References: <530C9E15.8030305@oracle.com> <3863846.75HEyYHLZJ@mgerdin03> Message-ID: <530CD7F3.5090708@oracle.com> On 2014-02-25 15:15, Mikael Gerdin wrote: > Hi Stefan, > > On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: >> Hi all, >> >> Please, review this small patch to add Klass::oop_is_instanceClassLoader(). >> >> Webrev: >> http://cr.openjdk.java.net/~stefank/8035746/webrev.00 > Code change looks good. Thanks. > > There are a couple of places where we check whether or not a Klass is a > ClassLoader, something like: > if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) > > These places could now be changed to > klass->oop_is_ClassLoader(), saving a possibly expensive subtype check. > > Should we file an RFE to change these or do you want to change them straight > away? I'd prefer a separate RFE. thanks, StefanK > > /Mikael > >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8035746 >> >> thanks, >> StefanK From john.r.rose at oracle.com Tue Feb 25 10:01:04 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 25 Feb 2014 10:01:04 -0800 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530C3E14.6030308@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> Message-ID: <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> On Feb 24, 2014, at 10:54 PM, David Holmes wrote: > If all the trace/logging output is directed to the default output stream (or the same file) then they will be intermixed. Fixing this would be non-trivial due to the need for explicit locking around compound trace/logging statements; and locking in tracing/log output can itself be problematic. > > Using different log files where possible would assist, but then you have no temporal relationship between the different entries. Yes, that is the essential trade-off between logging global order and capturing separate streams of information. The JVM's internal "tty" mechanism is designed to serialize reported output into one order, which (arguably) is a logging function. When large blocks of output appear, we don't want to cause other components to hang until the output is all out. That would disturb timing more than we want. (At least, that's the current theory.) So the compromise is to allow output to be broken up the way Chris points out. In the log format, newlines and tags are used to separate the output from different threads. On 21/02/2014 7:46 AM, Chris Newland wrote: > Hi all, > > I've written a visualiser/analyser for the hotspot.log JIT compilation log > called JITWatch[1] and I'm encountering problems with log statements from > various parts of the VM/HotSpot overlapping and producing garbled output > in hotspot.log[2]. What would help you to reconnect the output blocks? There's not much we can do about the tags and interleaving, but is there a problem reassembling the information? Should we emit a tag when a line is split? ? John From zhengyu.gu at oracle.com Tue Feb 25 09:43:46 2014 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Tue, 25 Feb 2014 12:43:46 -0500 Subject: RFR (XS) 8025550 valgrind: Conditional jump depends on uninitialised value in Arena::set_size_in_bytes() Message-ID: This is a simple fix to NMT, which can mis-count arena size due to uninitialized value. In rare case, if uninitialized size happens to be the same value as arena's initial size, NMT will mis-count the size, since NMT only updates size when the new size does not equal to the old one. Bug: https://bugs.openjdk.java.net/browse/JDK-8025550 Webrev: http://cr.openjdk.java.net/~zgu/8025550/webrev.00/ Thanks, -Zhengyu From vladimir.kozlov at oracle.com Tue Feb 25 11:41:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Feb 2014 11:41:58 -0800 Subject: Sync jdk9/hs-comp and jdk9/hs (ppc-aix changes) In-Reply-To: <53065DCA.6000406@oracle.com> References: <53053D2A.20304@oracle.com> <53065DCA.6000406@oracle.com> Message-ID: <530CF206.6070100@oracle.com> Alejandro sent note that all jdk9 ppc-aix changes are integrated into jdk9/dev. Regards, Vladimir On 2/20/14 11:55 AM, Vladimir Kozlov wrote: > On 2/20/14 8:52 AM, Volker Simonis wrote: >> Hi Vladimir, >> >> thanks for doing the the testing and merging. >> >> There's one small issue we found on AIX: >> >> Change https://bugs.openjdk.java.net/browse/JDK-8031968 moved >> os::get_default_process_handle() from os_posix.cpp back to the various >> platform files but didn't do this for AIX. The fix is trivial - just >> sent out a RFR. >> >> So if you could please push that fix first, everything is ready for >> merging the port into jdk9/hs. > > I am pushing this and 2 fixes from Goetz. I will push into jdk9/hs after > that. > >> >> Any idea when this will finally arrive in jdk9/dev? > > I assume it will be next week after PIT testing on code in jdk9/hs is > done. But it is not guaranteed, could be week after next. > >> >> As far as I understand, you'll push the whole jdk9/hs-comp forest to >> jdk9/hs right? I'm just asking, because we have a jdk change in >> jdk9/hs-comp/jdk which is needed for AIX. So this must be pushed into >> jdk9/hs/jdk as well. Also the whole jdk9/hs forest will have to be >> pushed to jdk9/dev for the same reason. > > I see only 8033154 fix in jdk which I need to push into main. I will > push it together with hotspot and ask Alejandro to push it into dev > after testing is done. > > Thanks, > Vladimir > >> >> Regards, >> Volker >> >> >> On Thu, Feb 20, 2014 at 12:24 AM, Vladimir Kozlov >> wrote: >>> The testing of PPC-AIX changes in jdk9/hs-comp is finished. >>> I pulled all hotspot changes from jdk9/hs/hotspot to >>> jdk9/hs-comp/hotspot >>> today. And I am pushing additional ppc fix for 8034797. >>> I merged jdk from jdk9/hs/jdk yesterday. Now jdk9/hs-comp forest has all >>> changes from jdk9/hs. >>> >>> I ran jdk control build of whole jdk9/hs-comp forest in JPRT and it >>> passed. >>> >>> Volker and Goetz, please, verify that jdk9/hs-comp does not have any >>> problems for you. I will merge it into jdk9/hs tomorrow if it is good. >>> >>> Thanks, >>> Vladimir From vladimir.kozlov at oracle.com Tue Feb 25 12:17:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Feb 2014 12:17:06 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530C94CB.3030800@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> Message-ID: <530CFA42.1090307@oracle.com> Can you align methods bodies?: + T* next() const { return _next; } + T* prev() const { return _prev; } + void set_next(T* item) { _next = item; } + void set_prev(T* item) { _prev = item; } I am not sure that your methods factoring will produce better code with all C++ compilers. You added switch which you assume will constant-fold but it is not guarantee. When I asked about refactoring I meant something a little simpler. To have inlined index(item) method in GenericHashtable: int index(T* item)) { assert(item != NULL, "missing null check"); return item->key() % size(); } and have only your contains_impl() as common method template T* GenericHashtable::contains(T* item) { if (item != NULL) { int idx = index(item); return contains_impl(item, idx); } return NULL; } template bool GenericHashtable::add(T* item) { if (item != NULL) { int idx = index(item); T* found_item = contains_impl(item, idx); if (found_item == NULL) { ... // code from add_impl() after (!contains) check return true; } } return false; } template T* GenericHashtable::remove(T* item) { if (item != NULL) { int idx = index(item); T* found_item = contains_impl(item, idx); if (found_item != NULL) { ... // code from remove_impl() after (contains) check return found_item; } } return NULL; } I think it is more clear. Thanks, Vladimir On 2/25/14 5:04 AM, Albert wrote: > Hi, > > Vladimir, Christian, Vitaly, thanks for looking at this and your feedback. > > @Vladimir: > No, this change is based on the version of 7194669. However, > the diff to before 7194669 are mainly code refactorings, which make the > code more readable (for me). > > I have changed the parameter name, (bool C_heap = false), adapted the > 'add' function > according to your suggestion, and implemented the hashtable destructor > as well as the > remove function. > > @Christian: > This for noticing this inconsistency. I fixed the parameter names > > @Vitaly: > I would prefer to leave the size parameter as it is now. While we would > save some instructions, > I think that specifying the size of the hashtable where it is used makes > the code more readable. > > Shouldn't we, in general, try to avoid hash table sizes that are an > exact power of 2? > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ > > Best, > Albert > > > On 02/21/2014 11:54 PM, Christian Thalinger wrote: >> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >> wrote: >> >>> Lets discuss it on hotspot-dev. >>> >>> Note the current hashtable allocates only in c_heap. Albert added >>> hashtable which can allocate in thread local resource area for >>> temporary table and c_heap for long live table. >>> >>> Albert, >>> >>> So you restored code in dependencies.?pp to one before 7194669 fix. >>> Right? >>> >>> I think you need to follow GrowableArray example to name parameter >>> "bool C_heap = false" instead of "bool resource_mark". It should be >>> saved in a field because you need to free c_heap in destructor if >>> C-heap is used: >>> >>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>> >>> Also I think you should avoid call to contains(item) in add() to >>> avoid doing the same thing twice. >> ?and you should stick to either item or element: >> >> + template bool GenericHashtable::add(T* item) { >> + template bool GenericHashtable::contains(T* >> element) { >> >>> You should implement remove(). >>> >>> Thanks, >>> Vladimir >>> >>> On 2/21/14 12:04 AM, Albert wrote: >>>> Hi, >>>> >>>> could I get reviews for this small patch? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>> >>>> Problem: The problem is that the patch (7194669) - which was >>>> supposed to >>>> speed-up dependency checking >>>> causes a performance regression. The reason for the >>>> performance regression is that most dependencies >>>> are unique, so we have the overhead of determining if >>>> the dependency is already checked plus the >>>> overhead of dependency checking. The overhead of >>>> searching is significant, since we perform >>>> a linear search on 6000+ items each time. >>>> >>>> Solution: Use a hashtable instead of linear search to lookup already >>>> checked dependencies. The new hashtable >>>> is very rudimentary. It provides only the required >>>> functionality to solve this bug. However, the functionality >>>> can be easily extended as needed. >>>> >>>> Testing: jprt, failing test case, nashorn. The failing test case >>>> completes in approx. the same time as before 7194669. >>>> For nashorn + Octane, this patch yields the following >>>> times spent for dependency checking: >>>> >>>> with this patch: 844s >>>> 7194669: 1080s >>>> before 7194669: 5223s >>>> >>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>> >>>> Thanks, >>>> Albert >>>> > From serguei.spitsyn at oracle.com Tue Feb 25 12:43:41 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Feb 2014 12:43:41 -0800 Subject: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") Message-ID: <530D007D.4040602@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 Summary: This is another Test Stabilization issue. The fix is very similar to other JVMTI stabilization fixes. It is to use safepoints for updating the PopFrame data instead of relying on the suspend equivalent condition mechanism (JvmtiEnv::is_thread_fully_suspended()) which is not adequate from the reliability point of view. Testing: In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi Thanks, Serguei From daniel.daugherty at oracle.com Tue Feb 25 14:57:20 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 25 Feb 2014 15:57:20 -0700 Subject: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530D007D.4040602@oracle.com> References: <530D007D.4040602@oracle.com> Message-ID: <530D1FD0.8070308@oracle.com> On 2/25/14 1:43 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 > src/share/vm/runtime/vm_operations.hpp No comments. src/share/vm/prims/jvmtiEnvBase.hpp No comments. src/share/vm/prims/jvmtiEnv.cpp No comments. src/share/vm/prims/jvmtiEnvThreadState.cpp No comments. src/share/vm/prims/jvmtiThreadState.cpp line 66: _cur_stack_depth = UNKNOWN_STACK_DEPTH; This looks like the key piece of this fix with respect to the assert() in the bug report. I suspect that the first call to JvmtiThreadState::cur_stack_depth() is racing with another thread that happens to do something else that inits or sets _cur_stack_depth to an acceptable value. line 251: "must be current thread or at safepont"); line 284: "must be current thread or at safepont"); typo: 'safepont' -> 'safepoint' Thumbs up! No need to re-review the typo fixes. Dan > > Summary: > > This is another Test Stabilization issue. > The fix is very similar to other JVMTI stabilization fixes. > It is to use safepoints for updating the PopFrame data instead of > relying on the > suspend equivalent condition mechanism > (JvmtiEnv::is_thread_fully_suspended()) > which is not adequate from the reliability point of view. > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Tue Feb 25 15:35:54 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Feb 2014 15:35:54 -0800 Subject: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530D1FD0.8070308@oracle.com> References: <530D007D.4040602@oracle.com> <530D1FD0.8070308@oracle.com> Message-ID: <530D28DA.1070308@oracle.com> On 2/25/14 2:57 PM, Daniel D. Daugherty wrote: > On 2/25/14 1:43 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >> > > src/share/vm/runtime/vm_operations.hpp > No comments. > > src/share/vm/prims/jvmtiEnvBase.hpp > No comments. > > src/share/vm/prims/jvmtiEnv.cpp > No comments. > > src/share/vm/prims/jvmtiEnvThreadState.cpp > No comments. > > src/share/vm/prims/jvmtiThreadState.cpp > line 66: _cur_stack_depth = UNKNOWN_STACK_DEPTH; > This looks like the key piece of this fix with respect to the > assert() in the bug report. I suspect that the first call to > JvmtiThreadState::cur_stack_depth() is racing with another > thread that happens to do something else that inits or sets > _cur_stack_depth to an acceptable value. Another potential cause of the issue is that the cur_stack_depth() is called from the update_for_pop_top_frame() which used to be called under suspend equivalent condition. The update_for_pop_top_frame() has been changed to be called at a safepoint now. > > line 251: "must be current thread or at safepont"); > line 284: "must be current thread or at safepont"); > typo: 'safepont' -> 'safepoint' > > Thumbs up! No need to re-review the typo fixes. Sure. I'll fix it before pushing. Thanks, Dan! Serguei > > Dan > > >> >> Summary: >> >> This is another Test Stabilization issue. >> The fix is very similar to other JVMTI stabilization fixes. >> It is to use safepoints for updating the PopFrame data instead of >> relying on the >> suspend equivalent condition mechanism >> (JvmtiEnv::is_thread_fully_suspended()) >> which is not adequate from the reliability point of view. >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> > From christian.thalinger at oracle.com Tue Feb 25 17:55:20 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 25 Feb 2014 17:55:20 -0800 Subject: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530D007D.4040602@oracle.com> References: <530D007D.4040602@oracle.com> Message-ID: <254DB943-0858-49A3-8BF3-3323F9BA4722@oracle.com> Looks good. On Feb 25, 2014, at 12:43 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 > > Summary: > > This is another Test Stabilization issue. > The fix is very similar to other JVMTI stabilization fixes. > It is to use safepoints for updating the PopFrame data instead of relying on the > suspend equivalent condition mechanism (JvmtiEnv::is_thread_fully_suspended()) > which is not adequate from the reliability point of view. > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Tue Feb 25 18:11:10 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 25 Feb 2014 18:11:10 -0800 Subject: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <254DB943-0858-49A3-8BF3-3323F9BA4722@oracle.com> References: <530D007D.4040602@oracle.com> <254DB943-0858-49A3-8BF3-3323F9BA4722@oracle.com> Message-ID: <530D4D3E.3030707@oracle.com> Thanks, Christian! Serguei On 2/25/14 5:55 PM, Christian Thalinger wrote: > Looks good. > > On Feb 25, 2014, at 12:43 PM, serguei.spitsyn at oracle.com wrote: > >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >> >> Summary: >> >> This is another Test Stabilization issue. >> The fix is very similar to other JVMTI stabilization fixes. >> It is to use safepoints for updating the PopFrame data instead of relying on the >> suspend equivalent condition mechanism (JvmtiEnv::is_thread_fully_suspended()) >> which is not adequate from the reliability point of view. >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> From david.holmes at oracle.com Tue Feb 25 20:26:35 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Feb 2014 14:26:35 +1000 Subject: 8030350 breaks build with older gccs. In-Reply-To: <530C92A0.6070407@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> <530C92A0.6070407@oracle.com> Message-ID: <530D6CFB.5030504@oracle.com> On 25/02/2014 10:54 PM, David Holmes wrote: > On 25/02/2014 9:42 PM, Lindenmaier, Goetz wrote: >> Hi Mike, >> >> your change breaks the build with older gccs as they don't know the >> option "-Wno-error=format-nonliteral" >> >> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc >> 3.3.3 on linuxx86_64. >> Gcc 4.3.4 works. >> >> In the mail thread I saw that you opened some bugs to fix further >> warnings, maybe you detected >> this issue already, or there is a bug to fix this? >> >> I would propose to fix this by either adapting hotspot code not to >> issue these warnings: > > I think Mike already did this for hotspot. Sorry got myself confused - forgot where Mike ended up on this one. David >> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ >> or to adapt the makefiles not to use the warning on older gccs: >> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ > > Or accept that there is a minimum gcc level expected as the build tool. > > David > ----- > >> If you give me advice what you would prefer, I will open a bug and send >> a RFR. >> >> Best regards, >> Goetz. >> >> From david.holmes at oracle.com Tue Feb 25 20:32:48 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Feb 2014 14:32:48 +1000 Subject: Memory ordering in C2 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA46C6@DEWDFEMB12A.global.corp.sap> References: <530CA489.5060805@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> <530CB709.1040205@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA46C6@DEWDFEMB12A.global.corp.sap> Message-ID: <530D6E70.20206@oracle.com> On 26/02/2014 1:41 AM, Lindenmaier, Goetz wrote: > Hi, > >> From what I've seen, C2 is enthusiastically emitting barrier nodes >> around CompareAndSwap, so I'm not quite sure what this means. > Yes, you are right ... that's again because we implement MemBArAcquire empty, > but after the CompareAndSwap we need one, so we had to add it in the node ;) > So same issue, distinguishing nodes would help! The bad thing is that MemBarAcquire > is implemented empty, that spoils the other uses. If there is a way to avoid MemBarAcquire > where it needs to be empty (after volatile load), then it can be implemented > properly ... I'm unclear what you mean by "needs to be empty" ?? David > Best regards, > Goetz. > > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Dienstag, 25. Februar 2014 16:30 > To: Lindenmaier, Goetz; hotspot-dev Source Developers > Subject: Re: Memory ordering in C2 > > Hi, > > On 02/25/2014 03:20 PM, Lindenmaier, Goetz wrote: > >> We added a a few new node types in this change: >> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/50fdb38839eb >> This solved the issue that we implement MemBarAcquire empty. > > Ah yes. Good, I can use that too. > >> But yes, we would appreciate further modularization in this direction. >> We proposed similar stuff in this mail: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-February/013384.html > > Thanks. I saw that at the time but didn't quite realize how similar > it was to my own issues. > >> Actually, we would like more barrier nodes in some places (around >> CompareAndSwap) because we issue sync instructions in those nodes. >> If they are extra nodes, we can optimize them. At other places, we >> would like less ... ;) > >>From what I've seen, C2 is enthusiastically emitting barrier nodes > around CompareAndSwap, so I'm not quite sure what this means. > >> And I guess x86 & friends, that always use empty nodes could profit, too. >> >> Further we would like to have explicit specification of the required >> barriers in the nodes (Only one node, but listing the barriers >> required (StoreStore | StoreLoad etc)). > > That would indeed be nice, but difficult. > > Andrew. > From mike.duigou at oracle.com Tue Feb 25 22:29:23 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 25 Feb 2014 22:29:23 -0800 Subject: 8030350 breaks build with older gccs. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> Message-ID: <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> Hello Goetz; The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included. David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9. Unfortunately, I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions? Mike On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" wrote: > Hi Mike, > > your change breaks the build with older gccs as they don?t know the option ?-Wno-error=format-nonliteral" > > I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. > Gcc 4.3.4 works. > > In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected > this issue already, or there is a bug to fix this? > > I would propose to fix this by either adapting hotspot code not to issue these warnings: > http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ > or to adapt the makefiles not to use the warning on older gccs: > http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ > > If you give me advice what you would prefer, I will open a bug and send > a RFR. > > Best regards, > Goetz. > > From cnewland at chrisnewland.com Mon Feb 24 18:32:16 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 25 Feb 2014 02:32:16 -0000 Subject: hotspot.log overlapping log statements (JITWatch) Message-ID: Hi all, I've written a visualiser/analyser for the hotspot.log JIT compilation log called JITWatch[1] and I'm encountering problems with log statements from various parts of the VM/HotSpot overlapping and producing garbled output in hotspot.log[2]. For example, if I combine the VM switches -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly then I get overlap between classloading statements, log compilation XML, and disassembled native code: Decoding compiled method 0x009dfec8: Code: [Entry Point] [Constants] # {method} 'hashCode' '()I' in 'java/lang/String' # [sp+0x20] (sp of caller) 0x009dffc0: nop 0x009dffc1: nop 0x009dffc2: nop <-- assembly interrupted by XML [Loaded java.lang.Enum <-- assembly interrupted by classloader 0x009dffc3: nop 0x009dffc4: nop 0x009dffc5: from shared objects file] nop 0x009dffc6: nop I couldn't find this in the Oracle or OpenJDK bug trackers and was wondering if this is a known problem and if it is fixable? It seems to happen fairly infrequently but means that JITWatch can't parse the compilation information when the garbling occurs. Thanks for any pointers you can give me. Kind regards, Chris @chriswhocodes [1] https://github.com/AdoptOpenJDK/jitwatch/wiki [2] https://github.com/AdoptOpenJDK/jitwatch/issues/3 From albert.noll at oracle.com Tue Feb 25 22:56:53 2014 From: albert.noll at oracle.com (Albert) Date: Wed, 26 Feb 2014 07:56:53 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530CFA42.1090307@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> Message-ID: <530D9035.3080709@oracle.com> Hi Vladimir, I agree that your version is more clear. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ Best, Albert On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: > Can you align methods bodies?: > > + T* next() const { return _next; } > + T* prev() const { return _prev; } > + void set_next(T* item) { _next = item; } > + void set_prev(T* item) { _prev = item; } > > I am not sure that your methods factoring will produce better code > with all C++ compilers. You added switch which you assume will > constant-fold but it is not guarantee. > > When I asked about refactoring I meant something a little simpler. > To have inlined index(item) method in GenericHashtable: > > int index(T* item)) { assert(item != NULL, "missing null check"); > return item->key() % size(); } > > and have only your contains_impl() as common method > > template T* GenericHashtable::contains(T* item) { > if (item != NULL) { > int idx = index(item); > return contains_impl(item, idx); > } > return NULL; > } > > template bool GenericHashtable::add(T* item) { > if (item != NULL) { > int idx = index(item); > T* found_item = contains_impl(item, idx); > if (found_item == NULL) { > ... // code from add_impl() after (!contains) check > return true; > } > } > return false; > } > > template T* GenericHashtable::remove(T* item) { > if (item != NULL) { > int idx = index(item); > T* found_item = contains_impl(item, idx); > if (found_item != NULL) { > ... // code from remove_impl() after (contains) check > return found_item; > } > } > return NULL; > } > > I think it is more clear. > > Thanks, > Vladimir > > On 2/25/14 5:04 AM, Albert wrote: >> Hi, >> >> Vladimir, Christian, Vitaly, thanks for looking at this and your >> feedback. >> >> @Vladimir: >> No, this change is based on the version of 7194669. However, >> the diff to before 7194669 are mainly code refactorings, which make the >> code more readable (for me). >> >> I have changed the parameter name, (bool C_heap = false), adapted the >> 'add' function >> according to your suggestion, and implemented the hashtable destructor >> as well as the >> remove function. >> >> @Christian: >> This for noticing this inconsistency. I fixed the parameter names >> >> @Vitaly: >> I would prefer to leave the size parameter as it is now. While we would >> save some instructions, >> I think that specifying the size of the hashtable where it is used makes >> the code more readable. >> >> Shouldn't we, in general, try to avoid hash table sizes that are an >> exact power of 2? >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >> >> Best, >> Albert >> >> >> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>> wrote: >>> >>>> Lets discuss it on hotspot-dev. >>>> >>>> Note the current hashtable allocates only in c_heap. Albert added >>>> hashtable which can allocate in thread local resource area for >>>> temporary table and c_heap for long live table. >>>> >>>> Albert, >>>> >>>> So you restored code in dependencies.?pp to one before 7194669 fix. >>>> Right? >>>> >>>> I think you need to follow GrowableArray example to name parameter >>>> "bool C_heap = false" instead of "bool resource_mark". It should be >>>> saved in a field because you need to free c_heap in destructor if >>>> C-heap is used: >>>> >>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>> >>>> Also I think you should avoid call to contains(item) in add() to >>>> avoid doing the same thing twice. >>> ?and you should stick to either item or element: >>> >>> + template bool GenericHashtable::add(T* >>> item) { >>> + template bool GenericHashtable::contains(T* >>> element) { >>> >>>> You should implement remove(). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/21/14 12:04 AM, Albert wrote: >>>>> Hi, >>>>> >>>>> could I get reviews for this small patch? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>> >>>>> Problem: The problem is that the patch (7194669) - which was >>>>> supposed to >>>>> speed-up dependency checking >>>>> causes a performance regression. The reason for the >>>>> performance regression is that most dependencies >>>>> are unique, so we have the overhead of determining if >>>>> the dependency is already checked plus the >>>>> overhead of dependency checking. The overhead of >>>>> searching is significant, since we perform >>>>> a linear search on 6000+ items each time. >>>>> >>>>> Solution: Use a hashtable instead of linear search to lookup already >>>>> checked dependencies. The new hashtable >>>>> is very rudimentary. It provides only the required >>>>> functionality to solve this bug. However, the functionality >>>>> can be easily extended as needed. >>>>> >>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>> completes in approx. the same time as before 7194669. >>>>> For nashorn + Octane, this patch yields the following >>>>> times spent for dependency checking: >>>>> >>>>> with this patch: 844s >>>>> 7194669: 1080s >>>>> before 7194669: 5223s >>>>> >>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>> >>>>> Thanks, >>>>> Albert >>>>> >> From vladimir.kozlov at oracle.com Tue Feb 25 23:53:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Feb 2014 23:53:13 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530D9035.3080709@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> Message-ID: <530D9D69.3070502@oracle.com> Albert, It looks good to me. Thanks, Vladimir On 2/25/14 10:56 PM, Albert wrote: > Hi Vladimir, > > I agree that your version is more clear. Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ > > Best, > Albert > > On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >> Can you align methods bodies?: >> >> + T* next() const { return _next; } >> + T* prev() const { return _prev; } >> + void set_next(T* item) { _next = item; } >> + void set_prev(T* item) { _prev = item; } >> >> I am not sure that your methods factoring will produce better code with all C++ compilers. You added switch which you >> assume will constant-fold but it is not guarantee. >> >> When I asked about refactoring I meant something a little simpler. >> To have inlined index(item) method in GenericHashtable: >> >> int index(T* item)) { assert(item != NULL, "missing null check"); return item->key() % size(); } >> >> and have only your contains_impl() as common method >> >> template T* GenericHashtable::contains(T* item) { >> if (item != NULL) { >> int idx = index(item); >> return contains_impl(item, idx); >> } >> return NULL; >> } >> >> template bool GenericHashtable::add(T* item) { >> if (item != NULL) { >> int idx = index(item); >> T* found_item = contains_impl(item, idx); >> if (found_item == NULL) { >> ... // code from add_impl() after (!contains) check >> return true; >> } >> } >> return false; >> } >> >> template T* GenericHashtable::remove(T* item) { >> if (item != NULL) { >> int idx = index(item); >> T* found_item = contains_impl(item, idx); >> if (found_item != NULL) { >> ... // code from remove_impl() after (contains) check >> return found_item; >> } >> } >> return NULL; >> } >> >> I think it is more clear. >> >> Thanks, >> Vladimir >> >> On 2/25/14 5:04 AM, Albert wrote: >>> Hi, >>> >>> Vladimir, Christian, Vitaly, thanks for looking at this and your feedback. >>> >>> @Vladimir: >>> No, this change is based on the version of 7194669. However, >>> the diff to before 7194669 are mainly code refactorings, which make the >>> code more readable (for me). >>> >>> I have changed the parameter name, (bool C_heap = false), adapted the >>> 'add' function >>> according to your suggestion, and implemented the hashtable destructor >>> as well as the >>> remove function. >>> >>> @Christian: >>> This for noticing this inconsistency. I fixed the parameter names >>> >>> @Vitaly: >>> I would prefer to leave the size parameter as it is now. While we would >>> save some instructions, >>> I think that specifying the size of the hashtable where it is used makes >>> the code more readable. >>> >>> Shouldn't we, in general, try to avoid hash table sizes that are an >>> exact power of 2? >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>> >>> Best, >>> Albert >>> >>> >>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> Lets discuss it on hotspot-dev. >>>>> >>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>> hashtable which can allocate in thread local resource area for >>>>> temporary table and c_heap for long live table. >>>>> >>>>> Albert, >>>>> >>>>> So you restored code in dependencies.?pp to one before 7194669 fix. >>>>> Right? >>>>> >>>>> I think you need to follow GrowableArray example to name parameter >>>>> "bool C_heap = false" instead of "bool resource_mark". It should be >>>>> saved in a field because you need to free c_heap in destructor if >>>>> C-heap is used: >>>>> >>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>> >>>>> Also I think you should avoid call to contains(item) in add() to >>>>> avoid doing the same thing twice. >>>> ?and you should stick to either item or element: >>>> >>>> + template bool GenericHashtable::add(T* item) { >>>> + template bool GenericHashtable::contains(T* >>>> element) { >>>> >>>>> You should implement remove(). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>> Hi, >>>>>> >>>>>> could I get reviews for this small patch? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>> >>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>> supposed to >>>>>> speed-up dependency checking >>>>>> causes a performance regression. The reason for the >>>>>> performance regression is that most dependencies >>>>>> are unique, so we have the overhead of determining if >>>>>> the dependency is already checked plus the >>>>>> overhead of dependency checking. The overhead of >>>>>> searching is significant, since we perform >>>>>> a linear search on 6000+ items each time. >>>>>> >>>>>> Solution: Use a hashtable instead of linear search to lookup already >>>>>> checked dependencies. The new hashtable >>>>>> is very rudimentary. It provides only the required >>>>>> functionality to solve this bug. However, the functionality >>>>>> can be easily extended as needed. >>>>>> >>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>> completes in approx. the same time as before 7194669. >>>>>> For nashorn + Octane, this patch yields the following >>>>>> times spent for dependency checking: >>>>>> >>>>>> with this patch: 844s >>>>>> 7194669: 1080s >>>>>> before 7194669: 5223s >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Albert >>>>>> >>> > From henry.jen at oracle.com Wed Feb 26 00:08:17 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 26 Feb 2014 00:08:17 -0800 Subject: JDK9: RFR: 8033898: undefined symbol when build hotspot with Xcode5 Message-ID: <530DA0F1.9060809@oracle.com> Hi, Please review a simple webrev that ensure we link with libstdc++ when using clang instead of libc++, libc++ is default for Xcode5. Per clang man page, > -stdlib=library > Specify the C++ standard library to use; supported options are > libstdc++ and libc++. Bug: https://bugs.openjdk.java.net/browse/JDK-8033898 Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8033898/1/webrev/ Cheers, Henry From david.holmes at oracle.com Tue Feb 25 22:25:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Feb 2014 16:25:20 +1000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> Message-ID: <530D88D0.5030001@oracle.com> On 26/02/2014 6:20 AM, Chris Newland wrote: > Hi John, David, > > Thank you for this information. > > I think the knowledge that a single line will only ever contain one > flavour of log output will allow me perform reordering as I parse the log. I don't have John's confidence that this is indeed the case. A print_cr obviously ends a line and every print call is processed atomically (in most cases) due to the underlying ttyLock acquired by the hold() method. However, unless the content of every individual print is indeed delimited, as suggested by John: >> In the log format, newlines and tags are used to separate the output >> from different threads. then things will still be interleaved. Here's an example where this does not hold in classFileParser.cpp (the first file I looked at): if (TraceClassLoadingPreorder) { tty->print("[Loading %s", (name != NULL) ? name->as_klass_external_name() : "NoName"); if (cfs->source() != NULL) tty->print(" from %s", cfs->source()); tty->print_cr("]"); } If you know [ and ] are delimiters then that helps but the "from %s" is not delimited. David ----- David > Another example I found was: > > [Entry Point] > [Constants] > # {method} 'ind > > [Loaded sun.nio.cs.ThreadLocalCoders from C:\Program > Files\Java\jre7\lib\rt.jar] > > exOf' '(II)I' in 'java/lang/String' > # this: ecx = 'java/lang/String' > # parm0: edx = int > # parm1: [sp+0x20] = int (sp of caller) > 0x009e07e0: nop > > but even here the XML and classloader logs can be identified and I can > reform the assembly without too much hassle. > > Kind regards, > > Chris > >> On Feb 24, 2014, at 10:54 PM, David Holmes >> wrote: >> >>> If all the trace/logging output is directed to the default output stream >>> (or the same file) then they will be intermixed. Fixing this would be >>> non-trivial due to the need for explicit locking around compound >>> trace/logging statements; and locking in tracing/log output can itself >>> be problematic. >>> >>> Using different log files where possible would assist, but then you have >>> no temporal relationship between the different entries. >> >> Yes, that is the essential trade-off between logging global order and >> capturing separate streams of information. >> >> The JVM's internal "tty" mechanism is designed to serialize reported >> output into one order, which (arguably) is a logging function. >> >> When large blocks of output appear, we don't want to cause other >> components to hang until the output is all out. That would disturb timing >> more than we want. (At least, that's the current theory.) >> >> So the compromise is to allow output to be broken up the way Chris points >> out. >> >> In the log format, newlines and tags are used to separate the output from >> different threads. >> >> On 21/02/2014 7:46 AM, Chris Newland wrote: >>> Hi all, >>> >>> I've written a visualiser/analyser for the hotspot.log JIT compilation >>> log >>> called JITWatch[1] and I'm encountering problems with log statements >>> from >>> various parts of the VM/HotSpot overlapping and producing garbled output >>> in hotspot.log[2]. >> >> What would help you to reconnect the output blocks? There's not much we >> can do about the tags and interleaving, but is there a problem >> reassembling the information? Should we emit a tag when a line is split? >> >> ? John > > From staffan.larsen at oracle.com Wed Feb 26 00:24:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 26 Feb 2014 09:24:32 +0100 Subject: JDK9: RFR: 8033898: undefined symbol when build hotspot with Xcode5 In-Reply-To: <530DA0F1.9060809@oracle.com> References: <530DA0F1.9060809@oracle.com> Message-ID: <5FF125ED-33FC-4F28-91C0-1D9A185F85EE@oracle.com> Looks good! Thanks, /Staffan On 26 feb 2014, at 09:08, Henry Jen wrote: > Hi, > > Please review a simple webrev that ensure we link with libstdc++ when using clang instead of libc++, libc++ is default for Xcode5. > > Per clang man page, > >> -stdlib=library >> Specify the C++ standard library to use; supported options are >> libstdc++ and libc++. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8033898 > Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8033898/1/webrev/ > > Cheers, > Henry From staffan.larsen at oracle.com Wed Feb 26 00:26:27 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 26 Feb 2014 09:26:27 +0100 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530D88D0.5030001@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> Message-ID: <88B5AEF9-4577-4EE9-B133-CCB3FFA12284@oracle.com> Just for reference I?d like to throw in a link to JEP 158: Unified JVM Logging: http://openjdk.java.net/jeps/158. Things like this would be good to fix as part of that project. /Staffan On 26 feb 2014, at 07:25, David Holmes wrote: > On 26/02/2014 6:20 AM, Chris Newland wrote: >> Hi John, David, >> >> Thank you for this information. >> >> I think the knowledge that a single line will only ever contain one >> flavour of log output will allow me perform reordering as I parse the log. > > I don't have John's confidence that this is indeed the case. A print_cr obviously ends a line and every print call is processed atomically (in most cases) due to the underlying ttyLock acquired by the hold() method. > > However, unless the content of every individual print is indeed delimited, as suggested by John: > > >> In the log format, newlines and tags are used to separate the output > >> from different threads. > > then things will still be interleaved. Here's an example where this does not hold in classFileParser.cpp (the first file I looked at): > > if (TraceClassLoadingPreorder) { > tty->print("[Loading %s", (name != NULL) ? name->as_klass_external_name() : "NoName"); > if (cfs->source() != NULL) tty->print(" from %s", cfs->source()); > tty->print_cr("]"); > } > > If you know [ and ] are delimiters then that helps but the "from %s" is not delimited. > > David > ----- > > David > >> Another example I found was: >> >> [Entry Point] >> [Constants] >> # {method} 'ind >> >> [Loaded sun.nio.cs.ThreadLocalCoders from C:\Program >> Files\Java\jre7\lib\rt.jar] >> >> exOf' '(II)I' in 'java/lang/String' >> # this: ecx = 'java/lang/String' >> # parm0: edx = int >> # parm1: [sp+0x20] = int (sp of caller) >> 0x009e07e0: nop >> >> but even here the XML and classloader logs can be identified and I can >> reform the assembly without too much hassle. >> >> Kind regards, >> >> Chris >> >>> On Feb 24, 2014, at 10:54 PM, David Holmes >>> wrote: >>> >>>> If all the trace/logging output is directed to the default output stream >>>> (or the same file) then they will be intermixed. Fixing this would be >>>> non-trivial due to the need for explicit locking around compound >>>> trace/logging statements; and locking in tracing/log output can itself >>>> be problematic. >>>> >>>> Using different log files where possible would assist, but then you have >>>> no temporal relationship between the different entries. >>> >>> Yes, that is the essential trade-off between logging global order and >>> capturing separate streams of information. >>> >>> The JVM's internal "tty" mechanism is designed to serialize reported >>> output into one order, which (arguably) is a logging function. >>> >>> When large blocks of output appear, we don't want to cause other >>> components to hang until the output is all out. That would disturb timing >>> more than we want. (At least, that's the current theory.) >>> >>> So the compromise is to allow output to be broken up the way Chris points >>> out. >>> >>> In the log format, newlines and tags are used to separate the output from >>> different threads. >>> >>> On 21/02/2014 7:46 AM, Chris Newland wrote: >>>> Hi all, >>>> >>>> I've written a visualiser/analyser for the hotspot.log JIT compilation >>>> log >>>> called JITWatch[1] and I'm encountering problems with log statements >>>> from >>>> various parts of the VM/HotSpot overlapping and producing garbled output >>>> in hotspot.log[2]. >>> >>> What would help you to reconnect the output blocks? There's not much we >>> can do about the tags and interleaving, but is there a problem >>> reassembling the information? Should we emit a tag when a line is split? >>> >>> ? John >> >> From john.r.rose at oracle.com Wed Feb 26 00:32:40 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 26 Feb 2014 00:32:40 -0800 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530D88D0.5030001@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> Message-ID: On Feb 25, 2014, at 10:25 PM, David Holmes wrote: > On 26/02/2014 6:20 AM, Chris Newland wrote: >> Hi John, David, >> >> Thank you for this information. >> >> I think the knowledge that a single line will only ever contain one >> flavour of log output will allow me perform reordering as I parse the log. > > I don't have John's confidence that this is indeed the case. A print_cr obviously ends a line and every print call is processed atomically (in most cases) due to the underlying ttyLock acquired by the hold() method. > > However, unless the content of every individual print is indeed delimited, as suggested by John: > > >> In the log format, newlines and tags are used to separate the output > >> from different threads. > > then things will still be interleaved. Here's an example where this does not hold in classFileParser.cpp (the first file I looked at): > > if (TraceClassLoadingPreorder) { > tty->print("[Loading %s", (name != NULL) ? name->as_klass_external_name() : "NoName"); > if (cfs->source() != NULL) tty->print(" from %s", cfs->source()); > tty->print_cr("]"); > } > > If you know [ and ] are delimiters then that helps but the "from %s" is not delimited. Output might look like: ... [Loading bauxite la la la la la da from the open pit. la da da la la da ] ... After untangling the different writer streams, you get: [Loading bauxite from the open pit. ] and then la la la la la da la da da la la da The code of thread 6 got three lines due to output switching, but expected to log a single line: [Loading bauxite from the open pit.] We could emit a little more info around the output switch markers like this: [Loading bauxite la la la la la da from the open pit. la da da la la da ] The untangled output from thread 6 would be: [Loading bauxite from the open pit. ] It would be easy to process the tokens suitably. ? John From roland.westrelin at oracle.com Wed Feb 26 00:41:51 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 26 Feb 2014 09:41:51 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530D9035.3080709@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> Message-ID: > http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ That looks good to me. Roland. From albert.noll at oracle.com Wed Feb 26 00:43:49 2014 From: albert.noll at oracle.com (Albert) Date: Wed, 26 Feb 2014 09:43:49 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> Message-ID: <530DA945.3000004@oracle.com> Roland, Vladimir, thanks for reviewing. Best, Albert On 02/26/2014 09:41 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ > That looks good to me. > > Roland. From volker.simonis at gmail.com Wed Feb 26 01:37:16 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 26 Feb 2014 10:37:16 +0100 Subject: 8030350 breaks build with older gccs. In-Reply-To: <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> Message-ID: On Wed, Feb 26, 2014 at 7:29 AM, Mike Duigou wrote: > Hello Goetz; > > The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included. > > David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9. > > Unfortunately, I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions? > I think we should look at the Linux distributions that we want to support. For example gcc 3.3.3 was shipped with SLES 9 and gcc 4.1 with SLES 10. It is part of our (i.e. SAP's) business that we support older releases for a long time, that's why we're interested in keeping the source base buildable with older releases as well. I don't think it is too complicated and I don't see any problem in adding new compiler options based on the compiler version. This was done before and it doesn't affect anybody who is using a newer compiler (if you look at the make files you'll even find checks for gcc 2). As long as we only speak of new warnings like in this case it is trivial to enable them only if they are supported. That's why I think that Goetz's change http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ which fixes the makefiles to only use "-Wno-error=format-nonliteral" if available is simple, effective and good. I'd only suggest to check for gcc >= 4.2 (instead of 4.3) after you wrote that the option already appeared in gcc 4.2. Regards, Volker > Mike > > On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" wrote: > >> Hi Mike, >> >> your change breaks the build with older gccs as they don?t know the option ?-Wno-error=format-nonliteral" >> >> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. >> Gcc 4.3.4 works. >> >> In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected >> this issue already, or there is a bug to fix this? >> >> I would propose to fix this by either adapting hotspot code not to issue these warnings: >> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ >> or to adapt the makefiles not to use the warning on older gccs: >> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ >> >> If you give me advice what you would prefer, I will open a bug and send >> a RFR. >> >> Best regards, >> Goetz. >> >> From aph at redhat.com Wed Feb 26 01:52:19 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Feb 2014 09:52:19 +0000 Subject: Memory ordering in C2 In-Reply-To: <530D6E70.20206@oracle.com> References: <530CA489.5060805@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> <530CB709.1040205@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA46C6@DEWDFEMB12A.global.corp.sap> <530D6E70.20206@oracle.com> Message-ID: <530DB953.3060703@redhat.com> On 02/26/2014 04:32 AM, David Holmes wrote: > On 26/02/2014 1:41 AM, Lindenmaier, Goetz wrote: >> Hi, >> >>> From what I've seen, C2 is enthusiastically emitting barrier nodes >>> around CompareAndSwap, so I'm not quite sure what this means. >> Yes, you are right ... that's again because we implement MemBArAcquire empty, >> but after the CompareAndSwap we need one, so we had to add it in the node ;) >> So same issue, distinguishing nodes would help! The bad thing is that MemBarAcquire >> is implemented empty, that spoils the other uses. If there is a way to avoid MemBarAcquire >> where it needs to be empty (after volatile load), then it can be implemented >> properly ... > > I'm unclear what you mean by "needs to be empty" ?? "Does not need to be emitted," I think. Andrew. From david.holmes at oracle.com Wed Feb 26 04:35:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Feb 2014 22:35:38 +1000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> Message-ID: <530DDF9A.6000505@oracle.com> Hi John, I really didn't follow how you could untangle arbitrary non-delimited text, but I think it will still require changes to the use of the print functions to fix it - right? Logically what we want is per-thread buffering so that we only do a write() of a full line of text. Cheers, David On 26/02/2014 6:32 PM, John Rose wrote: > On Feb 25, 2014, at 10:25 PM, David Holmes > wrote: > >> On 26/02/2014 6:20 AM, Chris Newland wrote: >>> Hi John, David, >>> >>> Thank you for this information. >>> >>> I think the knowledge that a single line will only ever contain one >>> flavour of log output will allow me perform reordering as I parse the >>> log. >> >> I don't have John's confidence that this is indeed the case. A >> print_cr obviously ends a line and every print call is processed >> atomically (in most cases) due to the underlying ttyLock acquired by >> the hold() method. >> >> However, unless the content of every individual print is indeed >> delimited, as suggested by John: >> >> >> In the log format, newlines and tags are used to separate the output >> >> from different threads. >> >> then things will still be interleaved. Here's an example where this >> does not hold in classFileParser.cpp (the first file I looked at): >> >> if (TraceClassLoadingPreorder) { >> tty->print("[Loading %s", (name != NULL) ? >> name->as_klass_external_name() : "NoName"); >> if (cfs->source() != NULL) tty->print(" from %s", cfs->source()); >> tty->print_cr("]"); >> } >> >> If you know [ and ] are delimiters then that helps but the "from %s" >> is not delimited. > > Output might look like: > > ... > > [Loading bauxite > > la la la la la da > > from the open pit. > > la da da la la da > > ] > ... > > > After untangling the different writer streams, you get: > > > [Loading bauxite > from the open pit. > ] > > and then > > > la la la la la da > la da da la la da > > The code of thread 6 got three lines due to output switching, but > expected to log a single line: > > [Loading bauxite from the open pit.] > > We could emit a little more info around the output switch markers like this: > > > [Loading bauxite > > > la la la la la da > > from the open pit. > > > la da da la la da > > ] > > The untangled output from thread 6 would be: > [Loading bauxite > > from the open pit. > > ] > > It would be easy to process the tokens suitably. > > ? John > From dmitry.samersoff at oracle.com Wed Feb 26 07:48:55 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 26 Feb 2014 19:48:55 +0400 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530DDF9A.6000505@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> Message-ID: <530E0CE7.2040003@oracle.com> David, Other option is to write to UDP rather than tty with an appropriate sequence number. UDP is much faster than tty and it allows customer to use whole bunch of UNIX tools that exists around syslog. -Dmitry On 2014-02-26 16:35, David Holmes wrote: > Hi John, > > I really didn't follow how you could untangle arbitrary non-delimited > text, but I think it will still require changes to the use of the print > functions to fix it - right? Logically what we want is per-thread > buffering so that we only do a write() of a full line of text. > > Cheers, > David > > On 26/02/2014 6:32 PM, John Rose wrote: >> On Feb 25, 2014, at 10:25 PM, David Holmes > > wrote: >> >>> On 26/02/2014 6:20 AM, Chris Newland wrote: >>>> Hi John, David, >>>> >>>> Thank you for this information. >>>> >>>> I think the knowledge that a single line will only ever contain one >>>> flavour of log output will allow me perform reordering as I parse the >>>> log. >>> >>> I don't have John's confidence that this is indeed the case. A >>> print_cr obviously ends a line and every print call is processed >>> atomically (in most cases) due to the underlying ttyLock acquired by >>> the hold() method. >>> >>> However, unless the content of every individual print is indeed >>> delimited, as suggested by John: >>> >>> >> In the log format, newlines and tags are used to separate the output >>> >> from different threads. >>> >>> then things will still be interleaved. Here's an example where this >>> does not hold in classFileParser.cpp (the first file I looked at): >>> >>> if (TraceClassLoadingPreorder) { >>> tty->print("[Loading %s", (name != NULL) ? >>> name->as_klass_external_name() : "NoName"); >>> if (cfs->source() != NULL) tty->print(" from %s", cfs->source()); >>> tty->print_cr("]"); >>> } >>> >>> If you know [ and ] are delimiters then that helps but the "from %s" >>> is not delimited. >> >> Output might look like: >> >> ... >> >> [Loading bauxite >> >> la la la la la da >> >> from the open pit. >> >> la da da la la da >> >> ] >> ... >> >> >> After untangling the different writer streams, you get: >> >> >> [Loading bauxite >> from the open pit. >> ] >> >> and then >> >> >> la la la la la da >> la da da la la da >> >> The code of thread 6 got three lines due to output switching, but >> expected to log a single line: >> >> [Loading bauxite from the open pit.] >> >> We could emit a little more info around the output switch markers like >> this: >> >> >> [Loading bauxite >> >> >> la la la la la da >> >> from the open pit. >> >> >> la da da la la da >> >> ] >> >> The untangled output from thread 6 would be: >> [Loading bauxite >> >> from the open pit. >> >> ] >> >> It would be easy to process the tokens suitably. >> >> ? John >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From john.r.rose at oracle.com Wed Feb 26 09:21:52 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 26 Feb 2014 09:21:52 -0800 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530DDF9A.6000505@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> Message-ID: <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> On Feb 26, 2014, at 4:35 AM, David Holmes wrote: > I really didn't follow how you could untangle arbitrary non-delimited text, but I think it will still require changes to the use of the print functions to fix it - right? Logically what we want is per-thread buffering so that we only do a write() of a full line of text. The log is line-oriented, so switching threads in the middle of a line requires that extra info. You could queue up threads until the writer has finished his line but I'd rather not, given that lines might require internal computation. It's better (IMO) to push the work to decode/reassemble after the JVM exits. Here's approximately what I had in mind: diff --git a/src/share/vm/utilities/ostream.cpp b/src/share/vm/utilities/ostream.cpp --- a/src/share/vm/utilities/ostream.cpp +++ b/src/share/vm/utilities/ostream.cpp @@ -961,7 +961,11 @@ // got the lock if (writer_id != _last_writer) { if (has_log) { - _log_file->bol(); + int pos = _log_file->position(); + if (pos > 0) { + _log_file->bol(); + _log_file->print_cr("", pos); + } // output a hint where this output is coming from: _log_file->print_cr("", writer_id); } The "pos" bit is redundant, an extra clue about trailing spaces. ? John From henry.jen at oracle.com Wed Feb 26 10:17:50 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 26 Feb 2014 10:17:50 -0800 Subject: JDK9: RFR: 8033898: undefined symbol when build hotspot with Xcode5 In-Reply-To: <5FF125ED-33FC-4F28-91C0-1D9A185F85EE@oracle.com> References: <530DA0F1.9060809@oracle.com> <5FF125ED-33FC-4F28-91C0-1D9A185F85EE@oracle.com> Message-ID: <530E2FCE.3030904@oracle.com> Thanks, Staffan. Need another review before push to hotspot. Would it be OK for hotspot team if we push this through jdk9/dev? As this is a build change only, and it would be nice to have 9dev build on Xcose once we have other pieces in instead of waiting for hostpot integration. Cheers, Henry On 02/26/2014 12:24 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 26 feb 2014, at 09:08, Henry Jen wrote: > >> Hi, >> >> Please review a simple webrev that ensure we link with libstdc++ when using clang instead of libc++, libc++ is default for Xcode5. >> >> Per clang man page, >> >>> -stdlib=library >>> Specify the C++ standard library to use; supported options are >>> libstdc++ and libc++. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8033898 >> Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8033898/1/webrev/ >> >> Cheers, >> Henry > From coleen.phillimore at oracle.com Wed Feb 26 10:32:16 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 13:32:16 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530D9035.3080709@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> Message-ID: <530E3330.9090809@oracle.com> Albert, This looks like nice work but it seems to add another completely different hashtable to the system. I was expecting this change to be generalizing BasicHashTable to allow resource allocation but it doesn't do that. It doesn't seem to make this easier to do either because it uses different names and doesn't have the hashing and other functionality that the general case needs. Was there a plan to do this? Keith McGuigan added a resource allocated hashtable also in src/share/vm/utilities/resourceHash.hpp. Can this not serve your needs? I think we shouldn't add a generalized class like this if it doesn't or can't support the general case - ie. the C_heap hashtable uses in the JVM, specificially for the symbol, string, and system dictionaries. It's just a lot of extra code and complex template parameters. Thanks, Coleen On 2/26/2014 1:56 AM, Albert wrote: > Hi Vladimir, > > I agree that your version is more clear. Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ > > Best, > Albert > > On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >> Can you align methods bodies?: >> >> + T* next() const { return _next; } >> + T* prev() const { return _prev; } >> + void set_next(T* item) { _next = item; } >> + void set_prev(T* item) { _prev = item; } >> >> I am not sure that your methods factoring will produce better code >> with all C++ compilers. You added switch which you assume will >> constant-fold but it is not guarantee. >> >> When I asked about refactoring I meant something a little simpler. >> To have inlined index(item) method in GenericHashtable: >> >> int index(T* item)) { assert(item != NULL, "missing null check"); >> return item->key() % size(); } >> >> and have only your contains_impl() as common method >> >> template T* GenericHashtable::contains(T* >> item) { >> if (item != NULL) { >> int idx = index(item); >> return contains_impl(item, idx); >> } >> return NULL; >> } >> >> template bool GenericHashtable::add(T* item) { >> if (item != NULL) { >> int idx = index(item); >> T* found_item = contains_impl(item, idx); >> if (found_item == NULL) { >> ... // code from add_impl() after (!contains) check >> return true; >> } >> } >> return false; >> } >> >> template T* GenericHashtable::remove(T* item) { >> if (item != NULL) { >> int idx = index(item); >> T* found_item = contains_impl(item, idx); >> if (found_item != NULL) { >> ... // code from remove_impl() after (contains) check >> return found_item; >> } >> } >> return NULL; >> } >> >> I think it is more clear. >> >> Thanks, >> Vladimir >> >> On 2/25/14 5:04 AM, Albert wrote: >>> Hi, >>> >>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>> feedback. >>> >>> @Vladimir: >>> No, this change is based on the version of 7194669. However, >>> the diff to before 7194669 are mainly code refactorings, which make the >>> code more readable (for me). >>> >>> I have changed the parameter name, (bool C_heap = false), adapted the >>> 'add' function >>> according to your suggestion, and implemented the hashtable destructor >>> as well as the >>> remove function. >>> >>> @Christian: >>> This for noticing this inconsistency. I fixed the parameter names >>> >>> @Vitaly: >>> I would prefer to leave the size parameter as it is now. While we would >>> save some instructions, >>> I think that specifying the size of the hashtable where it is used >>> makes >>> the code more readable. >>> >>> Shouldn't we, in general, try to avoid hash table sizes that are an >>> exact power of 2? >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>> >>> Best, >>> Albert >>> >>> >>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> Lets discuss it on hotspot-dev. >>>>> >>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>> hashtable which can allocate in thread local resource area for >>>>> temporary table and c_heap for long live table. >>>>> >>>>> Albert, >>>>> >>>>> So you restored code in dependencies.?pp to one before 7194669 fix. >>>>> Right? >>>>> >>>>> I think you need to follow GrowableArray example to name parameter >>>>> "bool C_heap = false" instead of "bool resource_mark". It should be >>>>> saved in a field because you need to free c_heap in destructor if >>>>> C-heap is used: >>>>> >>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>> >>>>> Also I think you should avoid call to contains(item) in add() to >>>>> avoid doing the same thing twice. >>>> ?and you should stick to either item or element: >>>> >>>> + template bool GenericHashtable::add(T* >>>> item) { >>>> + template bool GenericHashtable::contains(T* >>>> element) { >>>> >>>>> You should implement remove(). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>> Hi, >>>>>> >>>>>> could I get reviews for this small patch? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>> >>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>> supposed to >>>>>> speed-up dependency checking >>>>>> causes a performance regression. The reason for the >>>>>> performance regression is that most dependencies >>>>>> are unique, so we have the overhead of >>>>>> determining if >>>>>> the dependency is already checked plus the >>>>>> overhead of dependency checking. The overhead of >>>>>> searching is significant, since we perform >>>>>> a linear search on 6000+ items each time. >>>>>> >>>>>> Solution: Use a hashtable instead of linear search to lookup already >>>>>> checked dependencies. The new hashtable >>>>>> is very rudimentary. It provides only the required >>>>>> functionality to solve this bug. However, the functionality >>>>>> can be easily extended as needed. >>>>>> >>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>> completes in approx. the same time as before 7194669. >>>>>> For nashorn + Octane, this patch yields the following >>>>>> times spent for dependency checking: >>>>>> >>>>>> with this patch: 844s >>>>>> 7194669: 1080s >>>>>> before 7194669: 5223s >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Albert >>>>>> >>> > From vladimir.kozlov at oracle.com Wed Feb 26 11:14:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Feb 2014 11:14:40 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530E3330.9090809@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> Message-ID: <530E3D20.8070007@oracle.com> Too late Coleen, it is pushed already. It was on review on hotspot-dev since last week. I did not know about ResourceHashtable. Why it is in different file? I will let Albert investigate the possibility of use ResourceHashtable. Thanks, Vladimir On 2/26/14 10:32 AM, Coleen Phillimore wrote: > > Albert, > > This looks like nice work but it seems to add another completely > different hashtable to the system. I was expecting this change to be > generalizing BasicHashTable to allow resource allocation but it doesn't > do that. It doesn't seem to make this easier to do either because it > uses different names and doesn't have the hashing and other > functionality that the general case needs. Was there a plan to do this? > > Keith McGuigan added a resource allocated hashtable also in > src/share/vm/utilities/resourceHash.hpp. Can this not serve your needs? > > I think we shouldn't add a generalized class like this if it doesn't or > can't support the general case - ie. the C_heap hashtable uses in the > JVM, specificially for the symbol, string, and system dictionaries. It's > just a lot of extra code and complex template parameters. > > Thanks, > Coleen > > On 2/26/2014 1:56 AM, Albert wrote: >> Hi Vladimir, >> >> I agree that your version is more clear. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >> >> Best, >> Albert >> >> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>> Can you align methods bodies?: >>> >>> + T* next() const { return _next; } >>> + T* prev() const { return _prev; } >>> + void set_next(T* item) { _next = item; } >>> + void set_prev(T* item) { _prev = item; } >>> >>> I am not sure that your methods factoring will produce better code >>> with all C++ compilers. You added switch which you assume will >>> constant-fold but it is not guarantee. >>> >>> When I asked about refactoring I meant something a little simpler. >>> To have inlined index(item) method in GenericHashtable: >>> >>> int index(T* item)) { assert(item != NULL, "missing null check"); >>> return item->key() % size(); } >>> >>> and have only your contains_impl() as common method >>> >>> template T* GenericHashtable::contains(T* >>> item) { >>> if (item != NULL) { >>> int idx = index(item); >>> return contains_impl(item, idx); >>> } >>> return NULL; >>> } >>> >>> template bool GenericHashtable::add(T* item) { >>> if (item != NULL) { >>> int idx = index(item); >>> T* found_item = contains_impl(item, idx); >>> if (found_item == NULL) { >>> ... // code from add_impl() after (!contains) check >>> return true; >>> } >>> } >>> return false; >>> } >>> >>> template T* GenericHashtable::remove(T* item) { >>> if (item != NULL) { >>> int idx = index(item); >>> T* found_item = contains_impl(item, idx); >>> if (found_item != NULL) { >>> ... // code from remove_impl() after (contains) check >>> return found_item; >>> } >>> } >>> return NULL; >>> } >>> >>> I think it is more clear. >>> >>> Thanks, >>> Vladimir >>> >>> On 2/25/14 5:04 AM, Albert wrote: >>>> Hi, >>>> >>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>> feedback. >>>> >>>> @Vladimir: >>>> No, this change is based on the version of 7194669. However, >>>> the diff to before 7194669 are mainly code refactorings, which make the >>>> code more readable (for me). >>>> >>>> I have changed the parameter name, (bool C_heap = false), adapted the >>>> 'add' function >>>> according to your suggestion, and implemented the hashtable destructor >>>> as well as the >>>> remove function. >>>> >>>> @Christian: >>>> This for noticing this inconsistency. I fixed the parameter names >>>> >>>> @Vitaly: >>>> I would prefer to leave the size parameter as it is now. While we would >>>> save some instructions, >>>> I think that specifying the size of the hashtable where it is used >>>> makes >>>> the code more readable. >>>> >>>> Shouldn't we, in general, try to avoid hash table sizes that are an >>>> exact power of 2? >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> Lets discuss it on hotspot-dev. >>>>>> >>>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>>> hashtable which can allocate in thread local resource area for >>>>>> temporary table and c_heap for long live table. >>>>>> >>>>>> Albert, >>>>>> >>>>>> So you restored code in dependencies.?pp to one before 7194669 fix. >>>>>> Right? >>>>>> >>>>>> I think you need to follow GrowableArray example to name parameter >>>>>> "bool C_heap = false" instead of "bool resource_mark". It should be >>>>>> saved in a field because you need to free c_heap in destructor if >>>>>> C-heap is used: >>>>>> >>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>> >>>>>> Also I think you should avoid call to contains(item) in add() to >>>>>> avoid doing the same thing twice. >>>>> ?and you should stick to either item or element: >>>>> >>>>> + template bool GenericHashtable::add(T* >>>>> item) { >>>>> + template bool GenericHashtable::contains(T* >>>>> element) { >>>>> >>>>>> You should implement remove(). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I get reviews for this small patch? >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>> >>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>> supposed to >>>>>>> speed-up dependency checking >>>>>>> causes a performance regression. The reason for the >>>>>>> performance regression is that most dependencies >>>>>>> are unique, so we have the overhead of >>>>>>> determining if >>>>>>> the dependency is already checked plus the >>>>>>> overhead of dependency checking. The overhead of >>>>>>> searching is significant, since we perform >>>>>>> a linear search on 6000+ items each time. >>>>>>> >>>>>>> Solution: Use a hashtable instead of linear search to lookup already >>>>>>> checked dependencies. The new hashtable >>>>>>> is very rudimentary. It provides only the required >>>>>>> functionality to solve this bug. However, the functionality >>>>>>> can be easily extended as needed. >>>>>>> >>>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>>> completes in approx. the same time as before 7194669. >>>>>>> For nashorn + Octane, this patch yields the following >>>>>>> times spent for dependency checking: >>>>>>> >>>>>>> with this patch: 844s >>>>>>> 7194669: 1080s >>>>>>> before 7194669: 5223s >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Albert >>>>>>> >>>> >> > From coleen.phillimore at oracle.com Wed Feb 26 11:37:15 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 14:37:15 -0500 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530B1490.3030304@oracle.com> References: <530B1490.3030304@oracle.com> Message-ID: <530E426B.90401@oracle.com> This looks fine. It's a leaf function and it's pretty clear that there are no safepoints In the past, we converted all the calls to take Handles whenever possible because it saved a lot of re-handleizing and bugs with unhandled oops, and we prefer that unless there's a good reason. Here there is a good reason and it's obviously a leaf function, so this is fine. I don't think you should add No_Safepoint_Verifier. Thanks, Coleen On 2/24/2014 4:44 AM, Stefan Karlsson wrote: > Hi all, > > Please, review this change to let java_lang_String::print take a raw > String oop instead of a Handle to a String oop. This change makes > java_lang_String::print callable from code that has no HandleMark > setup. E.g. when calling from a debugger. > > Webrev: > http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8035648 > > thanks, > StefanK From coleen.phillimore at oracle.com Wed Feb 26 11:38:48 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 14:38:48 -0500 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <530CD7F3.5090708@oracle.com> References: <530C9E15.8030305@oracle.com> <3863846.75HEyYHLZJ@mgerdin03> <530CD7F3.5090708@oracle.com> Message-ID: <530E42C8.90608@oracle.com> On 2/25/2014 12:50 PM, Stefan Karlsson wrote: > On 2014-02-25 15:15, Mikael Gerdin wrote: >> Hi Stefan, >> >> On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: >>> Hi all, >>> >>> Please, review this small patch to add >>> Klass::oop_is_instanceClassLoader(). >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stefank/8035746/webrev.00 >> Code change looks good. > > Thanks. > >> >> There are a couple of places where we check whether or not a Klass is a >> ClassLoader, something like: >> if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) >> >> These places could now be changed to >> klass->oop_is_ClassLoader(), saving a possibly expensive subtype check. >> >> Should we file an RFE to change these or do you want to change them >> straight >> away? > > I'd prefer a separate RFE. This change looks good. I assume this is actually for G1 class unloading. Too bad though I wish you'd change it all in one pass. Thanks, Coleen > > thanks, > StefanK > >> >> /Mikael >> >>> RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8035746 >>> >>> thanks, >>> StefanK > From coleen.phillimore at oracle.com Wed Feb 26 11:46:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 14:46:56 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530E3D20.8070007@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> Message-ID: <530E44B0.7080805@oracle.com> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: > Too late Coleen, it is pushed already. It was on review on hotspot-dev > since last week. > I did not know about ResourceHashtable. Why it is in different file? > I will let Albert investigate the possibility of use ResourceHashtable. Bummer, I tagged it but didn't get to it. I was on vacation this week. There are a few more ad-hoc hashtables too in class file parser that I thought we could use Keith's hashtable for also. It's in the utilities directory... Thanks, Coleen > > Thanks, > Vladimir > > On 2/26/14 10:32 AM, Coleen Phillimore wrote: >> >> Albert, >> >> This looks like nice work but it seems to add another completely >> different hashtable to the system. I was expecting this change to be >> generalizing BasicHashTable to allow resource allocation but it doesn't >> do that. It doesn't seem to make this easier to do either because it >> uses different names and doesn't have the hashing and other >> functionality that the general case needs. Was there a plan to do >> this? >> >> Keith McGuigan added a resource allocated hashtable also in >> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >> needs? >> >> I think we shouldn't add a generalized class like this if it doesn't or >> can't support the general case - ie. the C_heap hashtable uses in the >> JVM, specificially for the symbol, string, and system dictionaries. It's >> just a lot of extra code and complex template parameters. >> >> Thanks, >> Coleen >> >> On 2/26/2014 1:56 AM, Albert wrote: >>> Hi Vladimir, >>> >>> I agree that your version is more clear. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>> >>> Best, >>> Albert >>> >>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>> Can you align methods bodies?: >>>> >>>> + T* next() const { return _next; } >>>> + T* prev() const { return _prev; } >>>> + void set_next(T* item) { _next = item; } >>>> + void set_prev(T* item) { _prev = item; } >>>> >>>> I am not sure that your methods factoring will produce better code >>>> with all C++ compilers. You added switch which you assume will >>>> constant-fold but it is not guarantee. >>>> >>>> When I asked about refactoring I meant something a little simpler. >>>> To have inlined index(item) method in GenericHashtable: >>>> >>>> int index(T* item)) { assert(item != NULL, "missing null check"); >>>> return item->key() % size(); } >>>> >>>> and have only your contains_impl() as common method >>>> >>>> template T* GenericHashtable::contains(T* >>>> item) { >>>> if (item != NULL) { >>>> int idx = index(item); >>>> return contains_impl(item, idx); >>>> } >>>> return NULL; >>>> } >>>> >>>> template bool GenericHashtable::add(T* item) { >>>> if (item != NULL) { >>>> int idx = index(item); >>>> T* found_item = contains_impl(item, idx); >>>> if (found_item == NULL) { >>>> ... // code from add_impl() after (!contains) check >>>> return true; >>>> } >>>> } >>>> return false; >>>> } >>>> >>>> template T* GenericHashtable::remove(T* >>>> item) { >>>> if (item != NULL) { >>>> int idx = index(item); >>>> T* found_item = contains_impl(item, idx); >>>> if (found_item != NULL) { >>>> ... // code from remove_impl() after (contains) check >>>> return found_item; >>>> } >>>> } >>>> return NULL; >>>> } >>>> >>>> I think it is more clear. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/25/14 5:04 AM, Albert wrote: >>>>> Hi, >>>>> >>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>> feedback. >>>>> >>>>> @Vladimir: >>>>> No, this change is based on the version of 7194669. However, >>>>> the diff to before 7194669 are mainly code refactorings, which >>>>> make the >>>>> code more readable (for me). >>>>> >>>>> I have changed the parameter name, (bool C_heap = false), adapted the >>>>> 'add' function >>>>> according to your suggestion, and implemented the hashtable >>>>> destructor >>>>> as well as the >>>>> remove function. >>>>> >>>>> @Christian: >>>>> This for noticing this inconsistency. I fixed the parameter names >>>>> >>>>> @Vitaly: >>>>> I would prefer to leave the size parameter as it is now. While we >>>>> would >>>>> save some instructions, >>>>> I think that specifying the size of the hashtable where it is used >>>>> makes >>>>> the code more readable. >>>>> >>>>> Shouldn't we, in general, try to avoid hash table sizes that are an >>>>> exact power of 2? >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> Lets discuss it on hotspot-dev. >>>>>>> >>>>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>>>> hashtable which can allocate in thread local resource area for >>>>>>> temporary table and c_heap for long live table. >>>>>>> >>>>>>> Albert, >>>>>>> >>>>>>> So you restored code in dependencies.?pp to one before 7194669 fix. >>>>>>> Right? >>>>>>> >>>>>>> I think you need to follow GrowableArray example to name parameter >>>>>>> "bool C_heap = false" instead of "bool resource_mark". It should be >>>>>>> saved in a field because you need to free c_heap in destructor if >>>>>>> C-heap is used: >>>>>>> >>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>> >>>>>>> Also I think you should avoid call to contains(item) in add() to >>>>>>> avoid doing the same thing twice. >>>>>> ?and you should stick to either item or element: >>>>>> >>>>>> + template bool GenericHashtable::add(T* >>>>>> item) { >>>>>> + template bool GenericHashtable>>>>> F>::contains(T* >>>>>> element) { >>>>>> >>>>>>> You should implement remove(). >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I get reviews for this small patch? >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>> >>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>> supposed to >>>>>>>> speed-up dependency checking >>>>>>>> causes a performance regression. The reason for >>>>>>>> the >>>>>>>> performance regression is that most dependencies >>>>>>>> are unique, so we have the overhead of >>>>>>>> determining if >>>>>>>> the dependency is already checked plus the >>>>>>>> overhead of dependency checking. The overhead of >>>>>>>> searching is significant, since we perform >>>>>>>> a linear search on 6000+ items each time. >>>>>>>> >>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>> already >>>>>>>> checked dependencies. The new hashtable >>>>>>>> is very rudimentary. It provides only the required >>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>> can be easily extended as needed. >>>>>>>> >>>>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>> following >>>>>>>> times spent for dependency checking: >>>>>>>> >>>>>>>> with this patch: 844s >>>>>>>> 7194669: 1080s >>>>>>>> before 7194669: 5223s >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Albert >>>>>>>> >>>>> >>> >> From coleen.phillimore at oracle.com Wed Feb 26 11:51:19 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 14:51:19 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530E44B0.7080805@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> Message-ID: <530E45B7.4060603@oracle.com> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: > On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >> Too late Coleen, it is pushed already. It was on review on >> hotspot-dev since last week. >> I did not know about ResourceHashtable. Why it is in different file? >> I will let Albert investigate the possibility of use ResourceHashtable. > > Bummer, I tagged it but didn't get to it. I was on vacation this > week. There are a few more ad-hoc hashtables too in class file > parser that I thought we could use Keith's hashtable for also. It's in > the utilities directory... Sorry, to be clear, I think the runtime group should do the classfile parser ones... Coleen > > Thanks, > Coleen > >> >> Thanks, >> Vladimir >> >> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>> >>> Albert, >>> >>> This looks like nice work but it seems to add another completely >>> different hashtable to the system. I was expecting this change to be >>> generalizing BasicHashTable to allow resource allocation but it doesn't >>> do that. It doesn't seem to make this easier to do either because it >>> uses different names and doesn't have the hashing and other >>> functionality that the general case needs. Was there a plan to do >>> this? >>> >>> Keith McGuigan added a resource allocated hashtable also in >>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>> needs? >>> >>> I think we shouldn't add a generalized class like this if it doesn't or >>> can't support the general case - ie. the C_heap hashtable uses in the >>> JVM, specificially for the symbol, string, and system dictionaries. >>> It's >>> just a lot of extra code and complex template parameters. >>> >>> Thanks, >>> Coleen >>> >>> On 2/26/2014 1:56 AM, Albert wrote: >>>> Hi Vladimir, >>>> >>>> I agree that your version is more clear. Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>> >>>> Best, >>>> Albert >>>> >>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>> Can you align methods bodies?: >>>>> >>>>> + T* next() const { return _next; } >>>>> + T* prev() const { return _prev; } >>>>> + void set_next(T* item) { _next = item; } >>>>> + void set_prev(T* item) { _prev = item; } >>>>> >>>>> I am not sure that your methods factoring will produce better code >>>>> with all C++ compilers. You added switch which you assume will >>>>> constant-fold but it is not guarantee. >>>>> >>>>> When I asked about refactoring I meant something a little simpler. >>>>> To have inlined index(item) method in GenericHashtable: >>>>> >>>>> int index(T* item)) { assert(item != NULL, "missing null check"); >>>>> return item->key() % size(); } >>>>> >>>>> and have only your contains_impl() as common method >>>>> >>>>> template T* GenericHashtable::contains(T* >>>>> item) { >>>>> if (item != NULL) { >>>>> int idx = index(item); >>>>> return contains_impl(item, idx); >>>>> } >>>>> return NULL; >>>>> } >>>>> >>>>> template bool GenericHashtable::add(T* >>>>> item) { >>>>> if (item != NULL) { >>>>> int idx = index(item); >>>>> T* found_item = contains_impl(item, idx); >>>>> if (found_item == NULL) { >>>>> ... // code from add_impl() after (!contains) check >>>>> return true; >>>>> } >>>>> } >>>>> return false; >>>>> } >>>>> >>>>> template T* GenericHashtable::remove(T* >>>>> item) { >>>>> if (item != NULL) { >>>>> int idx = index(item); >>>>> T* found_item = contains_impl(item, idx); >>>>> if (found_item != NULL) { >>>>> ... // code from remove_impl() after (contains) check >>>>> return found_item; >>>>> } >>>>> } >>>>> return NULL; >>>>> } >>>>> >>>>> I think it is more clear. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>> Hi, >>>>>> >>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>>> feedback. >>>>>> >>>>>> @Vladimir: >>>>>> No, this change is based on the version of 7194669. However, >>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>> make the >>>>>> code more readable (for me). >>>>>> >>>>>> I have changed the parameter name, (bool C_heap = false), adapted >>>>>> the >>>>>> 'add' function >>>>>> according to your suggestion, and implemented the hashtable >>>>>> destructor >>>>>> as well as the >>>>>> remove function. >>>>>> >>>>>> @Christian: >>>>>> This for noticing this inconsistency. I fixed the parameter names >>>>>> >>>>>> @Vitaly: >>>>>> I would prefer to leave the size parameter as it is now. While we >>>>>> would >>>>>> save some instructions, >>>>>> I think that specifying the size of the hashtable where it is used >>>>>> makes >>>>>> the code more readable. >>>>>> >>>>>> Shouldn't we, in general, try to avoid hash table sizes that are an >>>>>> exact power of 2? >>>>>> >>>>>> Here is the new webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>> >>>>>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>>>>> hashtable which can allocate in thread local resource area for >>>>>>>> temporary table and c_heap for long live table. >>>>>>>> >>>>>>>> Albert, >>>>>>>> >>>>>>>> So you restored code in dependencies.?pp to one before 7194669 >>>>>>>> fix. >>>>>>>> Right? >>>>>>>> >>>>>>>> I think you need to follow GrowableArray example to name parameter >>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>> should be >>>>>>>> saved in a field because you need to free c_heap in destructor if >>>>>>>> C-heap is used: >>>>>>>> >>>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>>> >>>>>>>> Also I think you should avoid call to contains(item) in add() to >>>>>>>> avoid doing the same thing twice. >>>>>>> ?and you should stick to either item or element: >>>>>>> >>>>>>> + template bool GenericHashtable::add(T* >>>>>>> item) { >>>>>>> + template bool GenericHashtable>>>>>> F>::contains(T* >>>>>>> element) { >>>>>>> >>>>>>>> You should implement remove(). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I get reviews for this small patch? >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>> >>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>> supposed to >>>>>>>>> speed-up dependency checking >>>>>>>>> causes a performance regression. The reason >>>>>>>>> for the >>>>>>>>> performance regression is that most dependencies >>>>>>>>> are unique, so we have the overhead of >>>>>>>>> determining if >>>>>>>>> the dependency is already checked plus the >>>>>>>>> overhead of dependency checking. The overhead of >>>>>>>>> searching is significant, since we perform >>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>> >>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>> already >>>>>>>>> checked dependencies. The new hashtable >>>>>>>>> is very rudimentary. It provides only the >>>>>>>>> required >>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>> can be easily extended as needed. >>>>>>>>> >>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>> following >>>>>>>>> times spent for dependency checking: >>>>>>>>> >>>>>>>>> with this patch: 844s >>>>>>>>> 7194669: 1080s >>>>>>>>> before 7194669: 5223s >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Albert >>>>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Wed Feb 26 11:57:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 26 Feb 2014 11:57:54 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530E45B7.4060603@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> Message-ID: <530E4742.20006@oracle.com> I have asked Albert to try ResourceHashtable and if it gives us the same results we may remove the new one. I think the confusion come from the fact that it is in a different file. We thought all hashtables are in hashtable.hpp. Regards, Vladimir On 2/26/14 11:51 AM, Coleen Phillimore wrote: > On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>> Too late Coleen, it is pushed already. It was on review on >>> hotspot-dev since last week. >>> I did not know about ResourceHashtable. Why it is in different file? >>> I will let Albert investigate the possibility of use ResourceHashtable. >> >> Bummer, I tagged it but didn't get to it. I was on vacation this >> week. There are a few more ad-hoc hashtables too in class file >> parser that I thought we could use Keith's hashtable for also. It's in >> the utilities directory... > > Sorry, to be clear, I think the runtime group should do the classfile > parser ones... > Coleen > >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> Vladimir >>> >>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>> >>>> Albert, >>>> >>>> This looks like nice work but it seems to add another completely >>>> different hashtable to the system. I was expecting this change to be >>>> generalizing BasicHashTable to allow resource allocation but it doesn't >>>> do that. It doesn't seem to make this easier to do either because it >>>> uses different names and doesn't have the hashing and other >>>> functionality that the general case needs. Was there a plan to do >>>> this? >>>> >>>> Keith McGuigan added a resource allocated hashtable also in >>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>>> needs? >>>> >>>> I think we shouldn't add a generalized class like this if it doesn't or >>>> can't support the general case - ie. the C_heap hashtable uses in the >>>> JVM, specificially for the symbol, string, and system dictionaries. >>>> It's >>>> just a lot of extra code and complex template parameters. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>> Hi Vladimir, >>>>> >>>>> I agree that your version is more clear. Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>> Can you align methods bodies?: >>>>>> >>>>>> + T* next() const { return _next; } >>>>>> + T* prev() const { return _prev; } >>>>>> + void set_next(T* item) { _next = item; } >>>>>> + void set_prev(T* item) { _prev = item; } >>>>>> >>>>>> I am not sure that your methods factoring will produce better code >>>>>> with all C++ compilers. You added switch which you assume will >>>>>> constant-fold but it is not guarantee. >>>>>> >>>>>> When I asked about refactoring I meant something a little simpler. >>>>>> To have inlined index(item) method in GenericHashtable: >>>>>> >>>>>> int index(T* item)) { assert(item != NULL, "missing null check"); >>>>>> return item->key() % size(); } >>>>>> >>>>>> and have only your contains_impl() as common method >>>>>> >>>>>> template T* GenericHashtable::contains(T* >>>>>> item) { >>>>>> if (item != NULL) { >>>>>> int idx = index(item); >>>>>> return contains_impl(item, idx); >>>>>> } >>>>>> return NULL; >>>>>> } >>>>>> >>>>>> template bool GenericHashtable::add(T* >>>>>> item) { >>>>>> if (item != NULL) { >>>>>> int idx = index(item); >>>>>> T* found_item = contains_impl(item, idx); >>>>>> if (found_item == NULL) { >>>>>> ... // code from add_impl() after (!contains) check >>>>>> return true; >>>>>> } >>>>>> } >>>>>> return false; >>>>>> } >>>>>> >>>>>> template T* GenericHashtable::remove(T* >>>>>> item) { >>>>>> if (item != NULL) { >>>>>> int idx = index(item); >>>>>> T* found_item = contains_impl(item, idx); >>>>>> if (found_item != NULL) { >>>>>> ... // code from remove_impl() after (contains) check >>>>>> return found_item; >>>>>> } >>>>>> } >>>>>> return NULL; >>>>>> } >>>>>> >>>>>> I think it is more clear. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>>>> feedback. >>>>>>> >>>>>>> @Vladimir: >>>>>>> No, this change is based on the version of 7194669. However, >>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>> make the >>>>>>> code more readable (for me). >>>>>>> >>>>>>> I have changed the parameter name, (bool C_heap = false), adapted >>>>>>> the >>>>>>> 'add' function >>>>>>> according to your suggestion, and implemented the hashtable >>>>>>> destructor >>>>>>> as well as the >>>>>>> remove function. >>>>>>> >>>>>>> @Christian: >>>>>>> This for noticing this inconsistency. I fixed the parameter names >>>>>>> >>>>>>> @Vitaly: >>>>>>> I would prefer to leave the size parameter as it is now. While we >>>>>>> would >>>>>>> save some instructions, >>>>>>> I think that specifying the size of the hashtable where it is used >>>>>>> makes >>>>>>> the code more readable. >>>>>>> >>>>>>> Shouldn't we, in general, try to avoid hash table sizes that are an >>>>>>> exact power of 2? >>>>>>> >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>> >>>>>>>>> Note the current hashtable allocates only in c_heap. Albert added >>>>>>>>> hashtable which can allocate in thread local resource area for >>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>> >>>>>>>>> Albert, >>>>>>>>> >>>>>>>>> So you restored code in dependencies.?pp to one before 7194669 >>>>>>>>> fix. >>>>>>>>> Right? >>>>>>>>> >>>>>>>>> I think you need to follow GrowableArray example to name parameter >>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>> should be >>>>>>>>> saved in a field because you need to free c_heap in destructor if >>>>>>>>> C-heap is used: >>>>>>>>> >>>>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>>>> >>>>>>>>> Also I think you should avoid call to contains(item) in add() to >>>>>>>>> avoid doing the same thing twice. >>>>>>>> ?and you should stick to either item or element: >>>>>>>> >>>>>>>> + template bool GenericHashtable::add(T* >>>>>>>> item) { >>>>>>>> + template bool GenericHashtable>>>>>>> F>::contains(T* >>>>>>>> element) { >>>>>>>> >>>>>>>>> You should implement remove(). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>> >>>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>>> supposed to >>>>>>>>>> speed-up dependency checking >>>>>>>>>> causes a performance regression. The reason >>>>>>>>>> for the >>>>>>>>>> performance regression is that most dependencies >>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>> determining if >>>>>>>>>> the dependency is already checked plus the >>>>>>>>>> overhead of dependency checking. The overhead of >>>>>>>>>> searching is significant, since we perform >>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>> >>>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>>> already >>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>> required >>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>> can be easily extended as needed. >>>>>>>>>> >>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test case >>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>> following >>>>>>>>>> times spent for dependency checking: >>>>>>>>>> >>>>>>>>>> with this patch: 844s >>>>>>>>>> 7194669: 1080s >>>>>>>>>> before 7194669: 5223s >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>> >>>>> >>>> >> > From stefan.karlsson at oracle.com Wed Feb 26 12:12:33 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 26 Feb 2014 21:12:33 +0100 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530E426B.90401@oracle.com> References: <530B1490.3030304@oracle.com> <530E426B.90401@oracle.com> Message-ID: <530E4AB1.9060801@oracle.com> On 2014-02-26 20:37, Coleen Phillimore wrote: > > This looks fine. It's a leaf function and it's pretty clear that > there are no safepoints In the past, we converted all the calls to > take Handles whenever possible because it saved a lot of > re-handleizing and bugs with unhandled oops, and we prefer that unless > there's a good reason. Here there is a good reason and it's > obviously a leaf function, so this is fine. I don't think you should > add No_Safepoint_Verifier. Thanks for reviewing! StefanK > > Thanks, > Coleen > > On 2/24/2014 4:44 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this change to let java_lang_String::print take a raw >> String oop instead of a Handle to a String oop. This change makes >> java_lang_String::print callable from code that has no HandleMark >> setup. E.g. when calling from a debugger. >> >> Webrev: >> http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ >> >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8035648 >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Feb 26 12:32:07 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 26 Feb 2014 21:32:07 +0100 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <530E42C8.90608@oracle.com> References: <530C9E15.8030305@oracle.com> <3863846.75HEyYHLZJ@mgerdin03> <530CD7F3.5090708@oracle.com> <530E42C8.90608@oracle.com> Message-ID: <530E4F47.5020206@oracle.com> On 2014-02-26 20:38, Coleen Phillimore wrote: > On 2/25/2014 12:50 PM, Stefan Karlsson wrote: >> On 2014-02-25 15:15, Mikael Gerdin wrote: >>> Hi Stefan, >>> >>> On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please, review this small patch to add >>>> Klass::oop_is_instanceClassLoader(). >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stefank/8035746/webrev.00 >>> Code change looks good. >> >> Thanks. >> >>> >>> There are a couple of places where we check whether or not a Klass is a >>> ClassLoader, something like: >>> if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) >>> >>> These places could now be changed to >>> klass->oop_is_ClassLoader(), saving a possibly expensive subtype check. >>> >>> Should we file an RFE to change these or do you want to change them >>> straight >>> away? >> >> I'd prefer a separate RFE. > > This change looks good. Thanks. > I assume this is actually for G1 class unloading. Yes. > Too bad though I wish you'd change it all in one pass. I just wanted to bring over this small change from the G1 Class Unloading repository and not have to argue whether changing the usages is_subclass_of to oop_is_instanceClassLoader was worth it or not. I did a quick search for this and found these three usages: 1) src//share/vm/classfile/javaClasses.hpp- static bool is_subclass(Klass* klass) { src//share/vm/classfile/javaClasses.hpp: return klass->is_subclass_of(SystemDictionary::ClassLoader_klass()); src//share/vm/classfile/javaClasses.hpp- } which is unused, AFAICT. 2) src//share/vm/prims/jvm.cpp: if (!vfst.method()->method_holder()->is_subclass_of(SystemDictionary::ClassLoader_klass())&& src//share/vm/prims/jvm.cpp- !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) && src//share/vm/prims/jvm.cpp- !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) { I don't think this helps the readability of the code if we change it. I don't know if this is performance critical. thanks, StefanK > Thanks, > Coleen > >> >> thanks, >> StefanK >> >>> >>> /Mikael >>> >>>> RFE: >>>> https://bugs.openjdk.java.net/browse/JDK-8035746 >>>> >>>> thanks, >>>> StefanK >> > From coleen.phillimore at oracle.com Wed Feb 26 13:16:22 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 26 Feb 2014 16:16:22 -0500 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <530E4F47.5020206@oracle.com> References: <530C9E15.8030305@oracle.com> <3863846.75HEyYHLZJ@mgerdin03> <530CD7F3.5090708@oracle.com> <530E42C8.90608@oracle.com> <530E4F47.5020206@oracle.com> Message-ID: <530E59A6.70408@oracle.com> Okay with below. Thanks for pointing out the code that could be changed - I agree, they are not really worth doing. Coleen On 2/26/2014 3:32 PM, Stefan Karlsson wrote: > On 2014-02-26 20:38, Coleen Phillimore wrote: >> On 2/25/2014 12:50 PM, Stefan Karlsson wrote: >>> On 2014-02-25 15:15, Mikael Gerdin wrote: >>>> Hi Stefan, >>>> >>>> On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please, review this small patch to add >>>>> Klass::oop_is_instanceClassLoader(). >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~stefank/8035746/webrev.00 >>>> Code change looks good. >>> >>> Thanks. >>> >>>> >>>> There are a couple of places where we check whether or not a Klass >>>> is a >>>> ClassLoader, something like: >>>> if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) >>>> >>>> These places could now be changed to >>>> klass->oop_is_ClassLoader(), saving a possibly expensive subtype >>>> check. >>>> >>>> Should we file an RFE to change these or do you want to change them >>>> straight >>>> away? >>> >>> I'd prefer a separate RFE. >> >> This change looks good. > > Thanks. > >> I assume this is actually for G1 class unloading. > > Yes. > >> Too bad though I wish you'd change it all in one pass. > > I just wanted to bring over this small change from the G1 Class > Unloading repository and not have to argue whether changing the usages > is_subclass_of to oop_is_instanceClassLoader was worth it or not. > > I did a quick search for this and found these three usages: > > 1) > src//share/vm/classfile/javaClasses.hpp- static bool > is_subclass(Klass* klass) { > src//share/vm/classfile/javaClasses.hpp: return > klass->is_subclass_of(SystemDictionary::ClassLoader_klass()); > src//share/vm/classfile/javaClasses.hpp- } > > which is unused, AFAICT. > > 2) > src//share/vm/prims/jvm.cpp: if > (!vfst.method()->method_holder()->is_subclass_of(SystemDictionary::ClassLoader_klass())&& > src//share/vm/prims/jvm.cpp- > !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) > && > src//share/vm/prims/jvm.cpp- > !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) > { > > I don't think this helps the readability of the code if we change it. > I don't know if this is performance critical. > > thanks, > StefanK > >> Thanks, >> Coleen >> >>> >>> thanks, >>> StefanK >>> >>>> >>>> /Mikael >>>> >>>>> RFE: >>>>> https://bugs.openjdk.java.net/browse/JDK-8035746 >>>>> >>>>> thanks, >>>>> StefanK >>> >> > From stefan.karlsson at oracle.com Wed Feb 26 13:17:31 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 26 Feb 2014 22:17:31 +0100 Subject: RFR: 8035746: Add missing Klass::oop_is_instanceClassLoader() function In-Reply-To: <530E59A6.70408@oracle.com> References: <530C9E15.8030305@oracle.com> <3863846.75HEyYHLZJ@mgerdin03> <530CD7F3.5090708@oracle.com> <530E42C8.90608@oracle.com> <530E4F47.5020206@oracle.com> <530E59A6.70408@oracle.com> Message-ID: <530E59EB.8090304@oracle.com> On 2014-02-26 22:16, Coleen Phillimore wrote: > > Okay with below. Thanks for pointing out the code that could be > changed - I agree, they are not really worth doing. Thanks again, Coleen. StefanK > Coleen > > > On 2/26/2014 3:32 PM, Stefan Karlsson wrote: >> On 2014-02-26 20:38, Coleen Phillimore wrote: >>> On 2/25/2014 12:50 PM, Stefan Karlsson wrote: >>>> On 2014-02-25 15:15, Mikael Gerdin wrote: >>>>> Hi Stefan, >>>>> >>>>> On Tuesday 25 February 2014 14.43.49 Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please, review this small patch to add >>>>>> Klass::oop_is_instanceClassLoader(). >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~stefank/8035746/webrev.00 >>>>> Code change looks good. >>>> >>>> Thanks. >>>> >>>>> >>>>> There are a couple of places where we check whether or not a Klass >>>>> is a >>>>> ClassLoader, something like: >>>>> if (klass->is_subclass_of(SystemDictionary::ClassLoader_klass())) >>>>> >>>>> These places could now be changed to >>>>> klass->oop_is_ClassLoader(), saving a possibly expensive subtype >>>>> check. >>>>> >>>>> Should we file an RFE to change these or do you want to change >>>>> them straight >>>>> away? >>>> >>>> I'd prefer a separate RFE. >>> >>> This change looks good. >> >> Thanks. >> >>> I assume this is actually for G1 class unloading. >> >> Yes. >> >>> Too bad though I wish you'd change it all in one pass. >> >> I just wanted to bring over this small change from the G1 Class >> Unloading repository and not have to argue whether changing the >> usages is_subclass_of to oop_is_instanceClassLoader was worth it or not. >> >> I did a quick search for this and found these three usages: >> >> 1) >> src//share/vm/classfile/javaClasses.hpp- static bool >> is_subclass(Klass* klass) { >> src//share/vm/classfile/javaClasses.hpp: return >> klass->is_subclass_of(SystemDictionary::ClassLoader_klass()); >> src//share/vm/classfile/javaClasses.hpp- } >> >> which is unused, AFAICT. >> >> 2) >> src//share/vm/prims/jvm.cpp: if >> (!vfst.method()->method_holder()->is_subclass_of(SystemDictionary::ClassLoader_klass())&& >> src//share/vm/prims/jvm.cpp- >> !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) >> && >> src//share/vm/prims/jvm.cpp- >> !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) >> { >> >> I don't think this helps the readability of the code if we change it. >> I don't know if this is performance critical. >> >> thanks, >> StefanK >> >>> Thanks, >>> Coleen >>> >>>> >>>> thanks, >>>> StefanK >>>> >>>>> >>>>> /Mikael >>>>> >>>>>> RFE: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8035746 >>>>>> >>>>>> thanks, >>>>>> StefanK >>>> >>> >> > From goetz.lindenmaier at sap.com Wed Feb 26 14:13:48 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Feb 2014 22:13:48 +0000 Subject: Memory ordering in C2 In-Reply-To: <530DB953.3060703@redhat.com> References: <530CA489.5060805@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA469C@DEWDFEMB12A.global.corp.sap> <530CB709.1040205@redhat.com> <4295855A5C1DE049A61835A1887419CC2CEA46C6@DEWDFEMB12A.global.corp.sap> <530D6E70.20206@oracle.com> <530DB953.3060703@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA4CB2@DEWDFEMB12A.global.corp.sap> Hi, We have a load that does the Acquire itself. So that we don't get a useless lwsync instruction after the load, the match rule for MemBarAcquire is empty, i.e., does not emit an instruction. Best regards, Goetz. -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Wednesday, February 26, 2014 10:52 AM To: David Holmes; Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: Memory ordering in C2 On 02/26/2014 04:32 AM, David Holmes wrote: > On 26/02/2014 1:41 AM, Lindenmaier, Goetz wrote: >> Hi, >> >>> From what I've seen, C2 is enthusiastically emitting barrier nodes >>> around CompareAndSwap, so I'm not quite sure what this means. >> Yes, you are right ... that's again because we implement MemBArAcquire empty, >> but after the CompareAndSwap we need one, so we had to add it in the node ;) >> So same issue, distinguishing nodes would help! The bad thing is that MemBarAcquire >> is implemented empty, that spoils the other uses. If there is a way to avoid MemBarAcquire >> where it needs to be empty (after volatile load), then it can be implemented >> properly ... > > I'm unclear what you mean by "needs to be empty" ?? "Does not need to be emitted," I think. Andrew. From goetz.lindenmaier at sap.com Wed Feb 26 14:22:53 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 26 Feb 2014 22:22:53 +0000 Subject: 8030350 breaks build with older gccs. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA4CDC@DEWDFEMB12A.global.corp.sap> Hi, currently, the build with 4.8 issues a warning. The flag just avoids that the warning is treated as error. So I thought removing the warning is the best way - as this is anyways the path currently followed, right? (Although the code looks better without my change). But if you don't like the special case for older compilers (which I just reuse, it's there anyways!), you can also switch off the warning for all compilers. By the way, 4.1.2 knows -Wno-error and -Wformat-nonliteral, but not the combination. Best regards, Goetz. -----Original Message----- From: Volker Simonis [mailto:volker.simonis at gmail.com] Sent: Wednesday, February 26, 2014 10:37 AM To: Mike Duigou Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net Subject: Re: 8030350 breaks build with older gccs. On Wed, Feb 26, 2014 at 7:29 AM, Mike Duigou wrote: > Hello Goetz; > > The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included. > > David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9. > > Unfortunately, I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions? > I think we should look at the Linux distributions that we want to support. For example gcc 3.3.3 was shipped with SLES 9 and gcc 4.1 with SLES 10. It is part of our (i.e. SAP's) business that we support older releases for a long time, that's why we're interested in keeping the source base buildable with older releases as well. I don't think it is too complicated and I don't see any problem in adding new compiler options based on the compiler version. This was done before and it doesn't affect anybody who is using a newer compiler (if you look at the make files you'll even find checks for gcc 2). As long as we only speak of new warnings like in this case it is trivial to enable them only if they are supported. That's why I think that Goetz's change http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ which fixes the makefiles to only use "-Wno-error=format-nonliteral" if available is simple, effective and good. I'd only suggest to check for gcc >= 4.2 (instead of 4.3) after you wrote that the option already appeared in gcc 4.2. Regards, Volker > Mike > > On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" wrote: > >> Hi Mike, >> >> your change breaks the build with older gccs as they don?t know the option ?-Wno-error=format-nonliteral" >> >> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. >> Gcc 4.3.4 works. >> >> In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected >> this issue already, or there is a bug to fix this? >> >> I would propose to fix this by either adapting hotspot code not to issue these warnings: >> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ >> or to adapt the makefiles not to use the warning on older gccs: >> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ >> >> If you give me advice what you would prefer, I will open a bug and send >> a RFR. >> >> Best regards, >> Goetz. >> >> From david.holmes at oracle.com Wed Feb 26 18:50:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Feb 2014 12:50:46 +1000 Subject: 8030350 breaks build with older gccs. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> Message-ID: <530EA806.4040203@oracle.com> Hi Volker, The set of valid platforms and compilers for the OpenJDK should always be a sliding window. For JDK 9 "we" want to ditch the "panaoramic window" we've been carrying around, move to more recent build platforms (which also dictates runtime platforms) and compilers, dropping all the old stuff we can. For example on Solaris anything related to the old T1 threads library; on linux anything to do with the old LinuxThreads implementation of pthreads. And cleaning up ancient compiler anachronisms in the build logic is also a "good thing". Now I don't know exactly how that lines up with your legacy support goals, but I do think gcc 3.3 is out of scope. There are some customization mechanisms in the build logic that should be used (and improved where needed) to add additional support for those community members that need it. Just my opinion. Cheers, David On 26/02/2014 7:37 PM, Volker Simonis wrote: > On Wed, Feb 26, 2014 at 7:29 AM, Mike Duigou wrote: >> Hello Goetz; >> >> The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included. >> >> David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9. >> >> Unfortunately, I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions? >> > > I think we should look at the Linux distributions that we want to > support. For example gcc 3.3.3 was shipped with SLES 9 and gcc 4.1 > with SLES 10. It is part of our (i.e. SAP's) business that we support > older releases for a long time, that's why we're interested in keeping > the source base buildable with older releases as well. > > I don't think it is too complicated and I don't see any problem in > adding new compiler options based on the compiler version. This was > done before and it doesn't affect anybody who is using a newer > compiler (if you look at the make files you'll even find checks for > gcc 2). As long as we only speak of new warnings like in this case it > is trivial to enable them only if they are supported. > > That's why I think that Goetz's change > http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ which fixes > the makefiles to only use "-Wno-error=format-nonliteral" if available > is simple, effective and good. I'd only suggest to check for gcc >= > 4.2 (instead of 4.3) after you wrote that the option already appeared > in gcc 4.2. > > Regards, > Volker > >> Mike >> >> On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Mike, >>> >>> your change breaks the build with older gccs as they don?t know the option ?-Wno-error=format-nonliteral" >>> >>> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. >>> Gcc 4.3.4 works. >>> >>> In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected >>> this issue already, or there is a bug to fix this? >>> >>> I would propose to fix this by either adapting hotspot code not to issue these warnings: >>> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ >>> or to adapt the makefiles not to use the warning on older gccs: >>> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ >>> >>> If you give me advice what you would prefer, I will open a bug and send >>> a RFR. >>> >>> Best regards, >>> Goetz. >>> >>> From david.holmes at oracle.com Wed Feb 26 18:54:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Feb 2014 12:54:46 +1000 Subject: JDK9: RFR: 8033898: undefined symbol when build hotspot with Xcode5 In-Reply-To: <530E2FCE.3030904@oracle.com> References: <530DA0F1.9060809@oracle.com> <5FF125ED-33FC-4F28-91C0-1D9A185F85EE@oracle.com> <530E2FCE.3030904@oracle.com> Message-ID: <530EA8F6.7030108@oracle.com> On 27/02/2014 4:17 AM, Henry Jen wrote: > Thanks, Staffan. > > Need another review before push to hotspot. Would it be OK for hotspot > team if we push this through jdk9/dev? Looks okay to me. Can't approve/not-approve the push to jdk9/dev though - but as long as it goes through JPRT I do not see an issue, as it only affects building with a compiler we don't officially use. David > As this is a build change only, and it would be nice to have 9dev build > on Xcose once we have other pieces in instead of waiting for hostpot > integration. > > Cheers, > Henry > > On 02/26/2014 12:24 AM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >> On 26 feb 2014, at 09:08, Henry Jen wrote: >> >>> Hi, >>> >>> Please review a simple webrev that ensure we link with libstdc++ when >>> using clang instead of libc++, libc++ is default for Xcode5. >>> >>> Per clang man page, >>> >>>> -stdlib=library >>>> Specify the C++ standard library to use; supported >>>> options are >>>> libstdc++ and libc++. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8033898 >>> Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8033898/1/webrev/ >>> >>> Cheers, >>> Henry >> From david.holmes at oracle.com Wed Feb 26 19:03:16 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Feb 2014 13:03:16 +1000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> Message-ID: <530EAAF4.20305@oracle.com> On 27/02/2014 3:21 AM, John Rose wrote: > On Feb 26, 2014, at 4:35 AM, David Holmes > wrote: > >> I really didn't follow how you could untangle arbitrary non-delimited >> text, but I think it will still require changes to the use of the >> print functions to fix it - right? Logically what we want is >> per-thread buffering so that we only do a write() of a full line of text. > > The log is line-oriented, so switching threads in the middle of a line > requires that extra info. Line-oriented in that we always start a new line when we switch threads - ok. Hadn't realized that. > You could queue up threads until the writer has finished his line but > I'd rather not, given that lines might require internal computation. That's why I said per-thread buffering (not that I see a way to implement it). No-one blocks but no thread starts to write a line until it has a full line to write. > It's better (IMO) to push the work to decode/reassemble after the JVM exits. > > Here's approximately what I had in mind: > > diff --git a/src/share/vm/utilities/ostream.cpp > b/src/share/vm/utilities/ostream.cpp > --- a/src/share/vm/utilities/ostream.cpp > +++ b/src/share/vm/utilities/ostream.cpp > @@ -961,7 +961,11 @@ > // got the lock > if (writer_id != _last_writer) { > if (has_log) { > - _log_file->bol(); > + int pos = _log_file->position(); > + if (pos > 0) { > + _log_file->bol(); > + _log_file->print_cr("", pos); > + } > // output a hint where this output is coming from: > _log_file->print_cr("", > writer_id); > } I see. David ----- > The "pos" bit is redundant, an extra clue about trailing spaces. > > ? John From henry.jen at oracle.com Wed Feb 26 21:33:25 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 26 Feb 2014 21:33:25 -0800 Subject: JDK9: RFR: 8033898: undefined symbol when build hotspot with Xcode5 In-Reply-To: <530EA8F6.7030108@oracle.com> References: <530DA0F1.9060809@oracle.com> <5FF125ED-33FC-4F28-91C0-1D9A185F85EE@oracle.com> <530E2FCE.3030904@oracle.com> <530EA8F6.7030108@oracle.com> Message-ID: <530ECE25.2040601@oracle.com> On 02/26/2014 06:54 PM, David Holmes wrote: > On 27/02/2014 4:17 AM, Henry Jen wrote: >> Thanks, Staffan. >> >> Need another review before push to hotspot. Would it be OK for hotspot >> team if we push this through jdk9/dev? > > Looks okay to me. Can't approve/not-approve the push to jdk9/dev though > - but as long as it goes through JPRT I do not see an issue, as it only > affects building with a compiler we don't officially use. > Thanks for reviewing, David. If no objection, it will go into jdk9/dev tomorrow(for another 12 hours or so to raise objection) via a JPRT submission. Cheers, Henry > David > >> As this is a build change only, and it would be nice to have 9dev build >> on Xcose once we have other pieces in instead of waiting for hostpot >> integration. >> >> Cheers, >> Henry >> From serguei.spitsyn at oracle.com Thu Feb 27 00:25:00 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Feb 2014 00:25:00 -0800 Subject: 2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530D007D.4040602@oracle.com> References: <530D007D.4040602@oracle.com> Message-ID: <530EF65C.5040707@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 Summary: It is the 2-nd round of review because the JTREG com/sun/jdi tests discovered a regression in the first round change. The issue was in the JvmtiEventController::clear_frame_pop() lock synchronization that is not allowed at safepoints. As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM operation for safety. Also, I've removed the lock synchronization from the 3 impacted JvmtiEventController:: functions: set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). Testing: In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi Thanks, Serguei On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 > > > Summary: > > This is another Test Stabilization issue. > The fix is very similar to other JVMTI stabilization fixes. > It is to use safepoints for updating the PopFrame data instead of > relying on the > suspend equivalent condition mechanism > (JvmtiEnv::is_thread_fully_suspended()) > which is not adequate from the reliability point of view. > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei > From dmitry.samersoff at oracle.com Thu Feb 27 00:58:14 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 27 Feb 2014 12:58:14 +0400 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530EAAF4.20305@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> <530EAAF4.20305@oracle.com> Message-ID: <530EFE26.20303@oracle.com> David, > That's why I said per-thread buffering (not that I see a way to > implement it). No-one blocks but *no thread starts to write > a line until it has a full line to write*. if the single line is result of different events it can take a while to get something printed. It's not always acceptable. -Dmitry On 2014-02-27 07:03, David Holmes wrote: > On 27/02/2014 3:21 AM, John Rose wrote: >> On Feb 26, 2014, at 4:35 AM, David Holmes > > wrote: >> >>> I really didn't follow how you could untangle arbitrary non-delimited >>> text, but I think it will still require changes to the use of the >>> print functions to fix it - right? Logically what we want is >>> per-thread buffering so that we only do a write() of a full line of >>> text. >> >> The log is line-oriented, so switching threads in the middle of a line >> requires that extra info. > > Line-oriented in that we always start a new line when we switch threads > - ok. Hadn't realized that. > >> You could queue up threads until the writer has finished his line but >> I'd rather not, given that lines might require internal computation. > > That's why I said per-thread buffering (not that I see a way to > implement it). No-one blocks but no thread starts to write a line until > it has a full line to write. > >> It's better (IMO) to push the work to decode/reassemble after the JVM >> exits. >> >> Here's approximately what I had in mind: >> >> diff --git a/src/share/vm/utilities/ostream.cpp >> b/src/share/vm/utilities/ostream.cpp >> --- a/src/share/vm/utilities/ostream.cpp >> +++ b/src/share/vm/utilities/ostream.cpp >> @@ -961,7 +961,11 @@ >> // got the lock >> if (writer_id != _last_writer) { >> if (has_log) { >> - _log_file->bol(); >> + int pos = _log_file->position(); >> + if (pos > 0) { >> + _log_file->bol(); >> + _log_file->print_cr("", pos); >> + } >> // output a hint where this output is coming from: >> _log_file->print_cr("", >> writer_id); >> } > > I see. > > David > ----- > > >> The "pos" bit is redundant, an extra clue about trailing spaces. >> >> ? John -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From per.liden at oracle.com Thu Feb 27 01:14:16 2014 From: per.liden at oracle.com (Per Liden) Date: Thu, 27 Feb 2014 10:14:16 +0100 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530B1490.3030304@oracle.com> References: <530B1490.3030304@oracle.com> Message-ID: <530F01E8.9030106@oracle.com> Looks good Stefan! /Per On 02/24/2014 10:44 AM, Stefan Karlsson wrote: > Hi all, > > Please, review this change to let java_lang_String::print take a raw > String oop instead of a Handle to a String oop. This change makes > java_lang_String::print callable from code that has no HandleMark setup. > E.g. when calling from a debugger. > > Webrev: > http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8035648 > > thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 27 01:15:14 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 27 Feb 2014 10:15:14 +0100 Subject: RFR: 8035648: Don't use Handle in java_lang_String::print In-Reply-To: <530F01E8.9030106@oracle.com> References: <530B1490.3030304@oracle.com> <530F01E8.9030106@oracle.com> Message-ID: <530F0222.4090002@oracle.com> On 2014-02-27 10:14, Per Liden wrote: > Looks good Stefan! Thanks! StefanK > > /Per > > On 02/24/2014 10:44 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this change to let java_lang_String::print take a raw >> String oop instead of a Handle to a String oop. This change makes >> java_lang_String::print callable from code that has no HandleMark setup. >> E.g. when calling from a debugger. >> >> Webrev: >> http://cr.openjdk.java.net/~stefank/8035648/webrev.00/ >> >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8035648 >> >> thanks, >> StefanK > From ludwig.mark at siemens.com Thu Feb 27 04:46:39 2014 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Thu, 27 Feb 2014 12:46:39 +0000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530EFE26.20303@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> <530EAAF4.20305@oracle.com> <530EFE26.20303@oracle.com> Message-ID: Here in the Peanut Gallery, it seems obvious that there is something wrong with the definition of what comprises a "line" of log output if it must be written by "different events." Is it really difficult to make each "write" be a complete line? I realize the result would be (much) shorter lines.... Cheers, Mark > From Dmitry Samersoff, Thursday, February 27, 2014 2:58 AM > David, > > > That's why I said per-thread buffering (not that I see a way to > > implement it). No-one blocks but *no thread starts to write > > a line until it has a full line to write*. > > if the single line is result of different events it can take a while to > get something printed. It's not always acceptable. > > -Dmitry From erik.joelsson at oracle.com Thu Feb 27 05:10:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 27 Feb 2014 14:10:04 +0100 Subject: JDK-8035944: Build failed wilth configure option --disable-debuginfo-files In-Reply-To: <530F3425.5060503@ysfactory.dip.jp> References: <530F323C.1090901@ysfactory.dip.jp> <530F3425.5060503@ysfactory.dip.jp> Message-ID: <530F392C.1000307@oracle.com> Adding hotspot-dev as this is a hotspot fix /Erik On 2014-02-27 13:48, Yasumasa Suenaga wrote: > Sorry, I forgot to upload webrev. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8035944/webrev.00/ > > Please review and sponsoring! > > > Yasumasa > > On 02/27/2014 09:40 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I tried to build JDK8 with configure option: >> "--disable-debuginfo-files", however I got error >> mesasges as following: >> >> ----------------- >> ## Starting hotspot >> Generating source files >> Building adlc >> Building libjvm.so >> Building libjsig.so >> Building libsaproc.so >> gmake[2]: *** No rule to make target >> `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/libjvm/libjvm.diz', >> needed by >> `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/dist/jre/lib/amd64/server/libjvm.diz'. >> Stop. >> gmake[2]: *** Waiting for unfinished jobs.... >> Copying files to dist directory >> gmake[1]: *** [dist-only] Error 2 >> make: *** [hotspot-only] Error 2 >> ----------------- >> >> I guess this error is caused by: >> Various improvements. Add dist implementation. >> http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5dadd2bb22c0 >> >> If we give --disable-zip-debuginfo-files to configure, Makefile and >> related files should regard it. >> >> I've made patche which is attached in this email, it works fine. >> >> >> I am just an Author. So I need a sponsor. >> Could you help me? >> >> >> Please cooperate. >> >> >> Thanks, >> >> Yasumasa >> > From yasu at ysfactory.dip.jp Thu Feb 27 05:24:08 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Thu, 27 Feb 2014 22:24:08 +0900 Subject: JDK-8035944: Build failed wilth configure option --disable-debuginfo-files In-Reply-To: <530F392C.1000307@oracle.com> References: <530F323C.1090901@ysfactory.dip.jp> <530F3425.5060503@ysfactory.dip.jp> <530F392C.1000307@oracle.com> Message-ID: <530F3C78.4040400@ysfactory.dip.jp> Hi Erik, David, I used build-infra/jdk8 repository. And configure options is "--disable-zip-debug-info" . I tried to build jdk9/dev, it was succeeded with "--disable-zip-debug-info" . David says build-infra is still a work in progress. Should close this issue with "Won't Fix" ? Or should I post another mail list ? Thanks, Yasumasa On 02/27/2014 10:10 PM, Erik Joelsson wrote: > Adding hotspot-dev as this is a hotspot fix > > /Erik > > On 2014-02-27 13:48, Yasumasa Suenaga wrote: >> Sorry, I forgot to upload webrev. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8035944/webrev.00/ >> >> Please review and sponsoring! >> >> >> Yasumasa >> >> On 02/27/2014 09:40 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I tried to build JDK8 with configure option: >>> "--disable-debuginfo-files", however I got error >>> mesasges as following: >>> >>> ----------------- >>> ## Starting hotspot >>> Generating source files >>> Building adlc >>> Building libjvm.so >>> Building libjsig.so >>> Building libsaproc.so >>> gmake[2]: *** No rule to make target >>> `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/libjvm/libjvm.diz', >>> needed by >>> `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/dist/jre/lib/amd64/server/libjvm.diz'. >>> Stop. >>> gmake[2]: *** Waiting for unfinished jobs.... >>> Copying files to dist directory >>> gmake[1]: *** [dist-only] Error 2 >>> make: *** [hotspot-only] Error 2 >>> ----------------- >>> >>> I guess this error is caused by: >>> Various improvements. Add dist implementation. >>> http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5dadd2bb22c0 >>> >>> If we give --disable-zip-debuginfo-files to configure, Makefile and >>> related files should regard it. >>> >>> I've made patche which is attached in this email, it works fine. >>> >>> >>> I am just an Author. So I need a sponsor. >>> Could you help me? >>> >>> >>> Please cooperate. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >> > From albert.noll at oracle.com Thu Feb 27 06:25:02 2014 From: albert.noll at oracle.com (Albert) Date: Thu, 27 Feb 2014 15:25:02 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530E4742.20006@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> <530E4742.20006@oracle.com> Message-ID: <530F4ABE.9040509@oracle.com> Hi, thanks for your feedback. That hashtable (ResourceHashtable) was exactly what I was looking for. Unfortunately, I did not know it existed... I implemented a different version of 8034839 that uses ResourceHashtable and compared the results against the version of the newly added hashtable (GenericHashtable). The performance is almost the same. GenericHashtable is little faster, since ResourceHashtable requires 2 lookups (1 to check if the element is in the hashtable and the 2nd when adding the element) to add a non-existing item to the hashtable. We could change ResourceHashtable such that it returns NULL if the item is added to the hashtable and a pointer to the previously stored value, if the item already existed. The Java hashtable has the same signature for put(). What do you think? We can also leave ResourceHashtable as it is, I do not insist on this change. In any case, we should remove GenericHashtable. I filed https://bugs.openjdk.java.net/browse/JDK-8035946 . If we decide to do the suggested change in ResourceHashtable, I guess it would be best to send the RFR to hotspot-dev ? Best, Albert On 02/26/2014 08:57 PM, Vladimir Kozlov wrote: > I have asked Albert to try ResourceHashtable and if it gives us the > same results we may remove the new one. I think the confusion come > from the fact that it is in a different file. We thought all > hashtables are in hashtable.hpp. > > Regards, > Vladimir > > On 2/26/14 11:51 AM, Coleen Phillimore wrote: >> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >>> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>>> Too late Coleen, it is pushed already. It was on review on >>>> hotspot-dev since last week. >>>> I did not know about ResourceHashtable. Why it is in different file? >>>> I will let Albert investigate the possibility of use >>>> ResourceHashtable. >>> >>> Bummer, I tagged it but didn't get to it. I was on vacation this >>> week. There are a few more ad-hoc hashtables too in class file >>> parser that I thought we could use Keith's hashtable for also. It's in >>> the utilities directory... >> >> Sorry, to be clear, I think the runtime group should do the classfile >> parser ones... >> Coleen >> >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>>> >>>>> Albert, >>>>> >>>>> This looks like nice work but it seems to add another completely >>>>> different hashtable to the system. I was expecting this change >>>>> to be >>>>> generalizing BasicHashTable to allow resource allocation but it >>>>> doesn't >>>>> do that. It doesn't seem to make this easier to do either >>>>> because it >>>>> uses different names and doesn't have the hashing and other >>>>> functionality that the general case needs. Was there a plan to do >>>>> this? >>>>> >>>>> Keith McGuigan added a resource allocated hashtable also in >>>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>>>> needs? >>>>> >>>>> I think we shouldn't add a generalized class like this if it >>>>> doesn't or >>>>> can't support the general case - ie. the C_heap hashtable uses in the >>>>> JVM, specificially for the symbol, string, and system dictionaries. >>>>> It's >>>>> just a lot of extra code and complex template parameters. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> I agree that your version is more clear. Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>>> Can you align methods bodies?: >>>>>>> >>>>>>> + T* next() const { return _next; } >>>>>>> + T* prev() const { return _prev; } >>>>>>> + void set_next(T* item) { _next = item; } >>>>>>> + void set_prev(T* item) { _prev = item; } >>>>>>> >>>>>>> I am not sure that your methods factoring will produce better code >>>>>>> with all C++ compilers. You added switch which you assume will >>>>>>> constant-fold but it is not guarantee. >>>>>>> >>>>>>> When I asked about refactoring I meant something a little simpler. >>>>>>> To have inlined index(item) method in GenericHashtable: >>>>>>> >>>>>>> int index(T* item)) { assert(item != NULL, "missing null check"); >>>>>>> return item->key() % size(); } >>>>>>> >>>>>>> and have only your contains_impl() as common method >>>>>>> >>>>>>> template T* GenericHashtable::contains(T* >>>>>>> item) { >>>>>>> if (item != NULL) { >>>>>>> int idx = index(item); >>>>>>> return contains_impl(item, idx); >>>>>>> } >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> template bool GenericHashtable::add(T* >>>>>>> item) { >>>>>>> if (item != NULL) { >>>>>>> int idx = index(item); >>>>>>> T* found_item = contains_impl(item, idx); >>>>>>> if (found_item == NULL) { >>>>>>> ... // code from add_impl() after (!contains) check >>>>>>> return true; >>>>>>> } >>>>>>> } >>>>>>> return false; >>>>>>> } >>>>>>> >>>>>>> template T* GenericHashtable::remove(T* >>>>>>> item) { >>>>>>> if (item != NULL) { >>>>>>> int idx = index(item); >>>>>>> T* found_item = contains_impl(item, idx); >>>>>>> if (found_item != NULL) { >>>>>>> ... // code from remove_impl() after (contains) check >>>>>>> return found_item; >>>>>>> } >>>>>>> } >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> I think it is more clear. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>>>>> feedback. >>>>>>>> >>>>>>>> @Vladimir: >>>>>>>> No, this change is based on the version of 7194669. However, >>>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>>> make the >>>>>>>> code more readable (for me). >>>>>>>> >>>>>>>> I have changed the parameter name, (bool C_heap = false), adapted >>>>>>>> the >>>>>>>> 'add' function >>>>>>>> according to your suggestion, and implemented the hashtable >>>>>>>> destructor >>>>>>>> as well as the >>>>>>>> remove function. >>>>>>>> >>>>>>>> @Christian: >>>>>>>> This for noticing this inconsistency. I fixed the parameter names >>>>>>>> >>>>>>>> @Vitaly: >>>>>>>> I would prefer to leave the size parameter as it is now. While we >>>>>>>> would >>>>>>>> save some instructions, >>>>>>>> I think that specifying the size of the hashtable where it is used >>>>>>>> makes >>>>>>>> the code more readable. >>>>>>>> >>>>>>>> Shouldn't we, in general, try to avoid hash table sizes that >>>>>>>> are an >>>>>>>> exact power of 2? >>>>>>>> >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>>> >>>>>>>>>> Note the current hashtable allocates only in c_heap. Albert >>>>>>>>>> added >>>>>>>>>> hashtable which can allocate in thread local resource area for >>>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>>> >>>>>>>>>> Albert, >>>>>>>>>> >>>>>>>>>> So you restored code in dependencies.?pp to one before 7194669 >>>>>>>>>> fix. >>>>>>>>>> Right? >>>>>>>>>> >>>>>>>>>> I think you need to follow GrowableArray example to name >>>>>>>>>> parameter >>>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>>> should be >>>>>>>>>> saved in a field because you need to free c_heap in >>>>>>>>>> destructor if >>>>>>>>>> C-heap is used: >>>>>>>>>> >>>>>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>>>>> >>>>>>>>>> Also I think you should avoid call to contains(item) in add() to >>>>>>>>>> avoid doing the same thing twice. >>>>>>>>> ?and you should stick to either item or element: >>>>>>>>> >>>>>>>>> + template bool GenericHashtable::add(T* >>>>>>>>> item) { >>>>>>>>> + template bool GenericHashtable>>>>>>>> F>::contains(T* >>>>>>>>> element) { >>>>>>>>> >>>>>>>>>> You should implement remove(). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>>> >>>>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>>>> supposed to >>>>>>>>>>> speed-up dependency checking >>>>>>>>>>> causes a performance regression. The reason >>>>>>>>>>> for the >>>>>>>>>>> performance regression is that most dependencies >>>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>>> determining if >>>>>>>>>>> the dependency is already checked plus the >>>>>>>>>>> overhead of dependency checking. The >>>>>>>>>>> overhead of >>>>>>>>>>> searching is significant, since we perform >>>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>>> >>>>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>>>> already >>>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>>> required >>>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>>> can be easily extended as needed. >>>>>>>>>>> >>>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test >>>>>>>>>>> case >>>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>>> following >>>>>>>>>>> times spent for dependency checking: >>>>>>>>>>> >>>>>>>>>>> with this patch: 844s >>>>>>>>>>> 7194669: 1080s >>>>>>>>>>> before 7194669: 5223s >>>>>>>>>>> >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From magnus.ihse.bursie at oracle.com Thu Feb 27 07:51:22 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Feb 2014 16:51:22 +0100 Subject: JDK-8035944: Build failed wilth configure option --disable-debuginfo-files In-Reply-To: <530F3C78.4040400@ysfactory.dip.jp> References: <530F323C.1090901@ysfactory.dip.jp> <530F3425.5060503@ysfactory.dip.jp> <530F392C.1000307@oracle.com> <530F3C78.4040400@ysfactory.dip.jp> Message-ID: <420E14B8-608D-48AC-916F-F666BF1F4FEA@oracle.com> You are building hotspot using the experimental new build in build-infra. It is known not to work. Please use a proper forest instead, e.g jdk8/jdk8 for the JDK 8 master. /Magnus 27 feb 2014 kl. 14:24 skrev Yasumasa Suenaga : > Hi Erik, David, > > I used build-infra/jdk8 repository. > And configure options is "--disable-zip-debug-info" . > > > I tried to build jdk9/dev, it was succeeded with "--disable-zip-debug-info" . > > David says build-infra is still a work in progress. > Should close this issue with "Won't Fix" ? Or should I post another mail list ? > > > Thanks, > > Yasumasa > > > On 02/27/2014 10:10 PM, Erik Joelsson wrote: >> Adding hotspot-dev as this is a hotspot fix >> >> /Erik >> >> On 2014-02-27 13:48, Yasumasa Suenaga wrote: >>> Sorry, I forgot to upload webrev. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8035944/webrev.00/ >>> >>> Please review and sponsoring! >>> >>> >>> Yasumasa >>> >>> On 02/27/2014 09:40 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I tried to build JDK8 with configure option: "--disable-debuginfo-files", however I got error >>>> mesasges as following: >>>> >>>> ----------------- >>>> ## Starting hotspot >>>> Generating source files >>>> Building adlc >>>> Building libjvm.so >>>> Building libjsig.so >>>> Building libsaproc.so >>>> gmake[2]: *** No rule to make target `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/libjvm/libjvm.diz', needed by `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/dist/jre/lib/amd64/server/libjvm.diz'. Stop. >>>> gmake[2]: *** Waiting for unfinished jobs.... >>>> Copying files to dist directory >>>> gmake[1]: *** [dist-only] Error 2 >>>> make: *** [hotspot-only] Error 2 >>>> ----------------- >>>> >>>> I guess this error is caused by: >>>> Various improvements. Add dist implementation. >>>> http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5dadd2bb22c0 >>>> >>>> If we give --disable-zip-debuginfo-files to configure, Makefile and related files should regard it. >>>> >>>> I've made patche which is attached in this email, it works fine. >>>> >>>> >>>> I am just an Author. So I need a sponsor. >>>> Could you help me? >>>> >>>> >>>> Please cooperate. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa > From coleen.phillimore at oracle.com Thu Feb 27 08:53:42 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 27 Feb 2014 11:53:42 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530F4ABE.9040509@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> <530E4742.20006@oracle.com> <530F4ABE.9040509@oracle.com> Message-ID: <530F6D96.20206@oracle.com> Albert, Thank you for doing this investigation. I'm sorry I didn't notice it sooner. On 2/27/14 9:25 AM, Albert wrote: > Hi, > > thanks for your feedback. That hashtable (ResourceHashtable) was > exactly what I was looking for. > Unfortunately, I did not know it existed... > > I implemented a different version of 8034839 that uses > ResourceHashtable and compared > the results against the version of the newly added hashtable > (GenericHashtable). The performance > is almost the same. > GenericHashtable is little faster, since ResourceHashtable requires 2 > lookups (1 to check > if the element is in the hashtable and the 2nd when adding the > element) to add a non-existing item > to the hashtable. > > We could change ResourceHashtable such that it returns NULL if the > item is added to the hashtable and > a pointer to the previously stored value, if the item already existed. > The Java hashtable has the same > signature for put(). What do you think? > We can also leave ResourceHashtable as it is, I do not insist on this > change. That seems fine to do if it improves performance. There is only one other use of this hashtable now that would benefit from this change also in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth tests that will exercise that code. Thanks, Coleen > > In any case, we should remove GenericHashtable. I filed > https://bugs.openjdk.java.net/browse/JDK-8035946 . > If we decide to do the suggested change in ResourceHashtable, I guess > it would be best to send the RFR > to hotspot-dev ? > > Best, > Albert > > > On 02/26/2014 08:57 PM, Vladimir Kozlov wrote: >> I have asked Albert to try ResourceHashtable and if it gives us the >> same results we may remove the new one. I think the confusion come >> from the fact that it is in a different file. We thought all >> hashtables are in hashtable.hpp. >> >> Regards, >> Vladimir >> >> On 2/26/14 11:51 AM, Coleen Phillimore wrote: >>> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >>>> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>>>> Too late Coleen, it is pushed already. It was on review on >>>>> hotspot-dev since last week. >>>>> I did not know about ResourceHashtable. Why it is in different file? >>>>> I will let Albert investigate the possibility of use >>>>> ResourceHashtable. >>>> >>>> Bummer, I tagged it but didn't get to it. I was on vacation this >>>> week. There are a few more ad-hoc hashtables too in class file >>>> parser that I thought we could use Keith's hashtable for also. It's in >>>> the utilities directory... >>> >>> Sorry, to be clear, I think the runtime group should do the classfile >>> parser ones... >>> Coleen >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Albert, >>>>>> >>>>>> This looks like nice work but it seems to add another completely >>>>>> different hashtable to the system. I was expecting this change >>>>>> to be >>>>>> generalizing BasicHashTable to allow resource allocation but it >>>>>> doesn't >>>>>> do that. It doesn't seem to make this easier to do either >>>>>> because it >>>>>> uses different names and doesn't have the hashing and other >>>>>> functionality that the general case needs. Was there a plan to do >>>>>> this? >>>>>> >>>>>> Keith McGuigan added a resource allocated hashtable also in >>>>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>>>>> needs? >>>>>> >>>>>> I think we shouldn't add a generalized class like this if it >>>>>> doesn't or >>>>>> can't support the general case - ie. the C_heap hashtable uses in >>>>>> the >>>>>> JVM, specificially for the symbol, string, and system dictionaries. >>>>>> It's >>>>>> just a lot of extra code and complex template parameters. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> I agree that your version is more clear. Here is the updated >>>>>>> webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>>>> Can you align methods bodies?: >>>>>>>> >>>>>>>> + T* next() const { return _next; } >>>>>>>> + T* prev() const { return _prev; } >>>>>>>> + void set_next(T* item) { _next = item; } >>>>>>>> + void set_prev(T* item) { _prev = item; } >>>>>>>> >>>>>>>> I am not sure that your methods factoring will produce better code >>>>>>>> with all C++ compilers. You added switch which you assume will >>>>>>>> constant-fold but it is not guarantee. >>>>>>>> >>>>>>>> When I asked about refactoring I meant something a little simpler. >>>>>>>> To have inlined index(item) method in GenericHashtable: >>>>>>>> >>>>>>>> int index(T* item)) { assert(item != NULL, "missing null >>>>>>>> check"); >>>>>>>> return item->key() % size(); } >>>>>>>> >>>>>>>> and have only your contains_impl() as common method >>>>>>>> >>>>>>>> template T* GenericHashtable::contains(T* >>>>>>>> item) { >>>>>>>> if (item != NULL) { >>>>>>>> int idx = index(item); >>>>>>>> return contains_impl(item, idx); >>>>>>>> } >>>>>>>> return NULL; >>>>>>>> } >>>>>>>> >>>>>>>> template bool GenericHashtable::add(T* >>>>>>>> item) { >>>>>>>> if (item != NULL) { >>>>>>>> int idx = index(item); >>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>> if (found_item == NULL) { >>>>>>>> ... // code from add_impl() after (!contains) check >>>>>>>> return true; >>>>>>>> } >>>>>>>> } >>>>>>>> return false; >>>>>>>> } >>>>>>>> >>>>>>>> template T* GenericHashtable::remove(T* >>>>>>>> item) { >>>>>>>> if (item != NULL) { >>>>>>>> int idx = index(item); >>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>> if (found_item != NULL) { >>>>>>>> ... // code from remove_impl() after (contains) check >>>>>>>> return found_item; >>>>>>>> } >>>>>>>> } >>>>>>>> return NULL; >>>>>>>> } >>>>>>>> >>>>>>>> I think it is more clear. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>>>>>> feedback. >>>>>>>>> >>>>>>>>> @Vladimir: >>>>>>>>> No, this change is based on the version of 7194669. However, >>>>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>>>> make the >>>>>>>>> code more readable (for me). >>>>>>>>> >>>>>>>>> I have changed the parameter name, (bool C_heap = false), adapted >>>>>>>>> the >>>>>>>>> 'add' function >>>>>>>>> according to your suggestion, and implemented the hashtable >>>>>>>>> destructor >>>>>>>>> as well as the >>>>>>>>> remove function. >>>>>>>>> >>>>>>>>> @Christian: >>>>>>>>> This for noticing this inconsistency. I fixed the parameter names >>>>>>>>> >>>>>>>>> @Vitaly: >>>>>>>>> I would prefer to leave the size parameter as it is now. While we >>>>>>>>> would >>>>>>>>> save some instructions, >>>>>>>>> I think that specifying the size of the hashtable where it is >>>>>>>>> used >>>>>>>>> makes >>>>>>>>> the code more readable. >>>>>>>>> >>>>>>>>> Shouldn't we, in general, try to avoid hash table sizes that >>>>>>>>> are an >>>>>>>>> exact power of 2? >>>>>>>>> >>>>>>>>> Here is the new webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>>>> >>>>>>>>>>> Note the current hashtable allocates only in c_heap. Albert >>>>>>>>>>> added >>>>>>>>>>> hashtable which can allocate in thread local resource area for >>>>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>>>> >>>>>>>>>>> Albert, >>>>>>>>>>> >>>>>>>>>>> So you restored code in dependencies.?pp to one before 7194669 >>>>>>>>>>> fix. >>>>>>>>>>> Right? >>>>>>>>>>> >>>>>>>>>>> I think you need to follow GrowableArray example to name >>>>>>>>>>> parameter >>>>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>>>> should be >>>>>>>>>>> saved in a field because you need to free c_heap in >>>>>>>>>>> destructor if >>>>>>>>>>> C-heap is used: >>>>>>>>>>> >>>>>>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>>>>>> >>>>>>>>>>> Also I think you should avoid call to contains(item) in >>>>>>>>>>> add() to >>>>>>>>>>> avoid doing the same thing twice. >>>>>>>>>> ?and you should stick to either item or element: >>>>>>>>>> >>>>>>>>>> + template bool GenericHashtable::add(T* >>>>>>>>>> item) { >>>>>>>>>> + template bool GenericHashtable>>>>>>>>> F>::contains(T* >>>>>>>>>> element) { >>>>>>>>>> >>>>>>>>>>> You should implement remove(). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>>>> >>>>>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>>>>> supposed to >>>>>>>>>>>> speed-up dependency checking >>>>>>>>>>>> causes a performance regression. The reason >>>>>>>>>>>> for the >>>>>>>>>>>> performance regression is that most dependencies >>>>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>>>> determining if >>>>>>>>>>>> the dependency is already checked plus the >>>>>>>>>>>> overhead of dependency checking. The >>>>>>>>>>>> overhead of >>>>>>>>>>>> searching is significant, since we perform >>>>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>>>> >>>>>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>>>>> already >>>>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>>>> required >>>>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>>>> can be easily extended as needed. >>>>>>>>>>>> >>>>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test >>>>>>>>>>>> case >>>>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>>>> following >>>>>>>>>>>> times spent for dependency checking: >>>>>>>>>>>> >>>>>>>>>>>> with this patch: 844s >>>>>>>>>>>> 7194669: 1080s >>>>>>>>>>>> before 7194669: 5223s >>>>>>>>>>>> >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Albert >>>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Thu Feb 27 10:20:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Feb 2014 10:20:43 -0800 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530F6D96.20206@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> <530E4742.20006@oracle.com> <530F4ABE.9040509@oracle.com> <530F6D96.20206@oracle.com> Message-ID: <530F81FB.4000006@oracle.com> > in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth > tests that will exercise that code. Coleen, can we measure performance with them or they checks only correctness? I am for improving performance of ResourceHashtable. Thanks, Vladimir On 2/27/14 8:53 AM, Coleen Phillimore wrote: > > Albert, Thank you for doing this investigation. I'm sorry I didn't > notice it sooner. > > On 2/27/14 9:25 AM, Albert wrote: >> Hi, >> >> thanks for your feedback. That hashtable (ResourceHashtable) was >> exactly what I was looking for. >> Unfortunately, I did not know it existed... >> >> I implemented a different version of 8034839 that uses >> ResourceHashtable and compared >> the results against the version of the newly added hashtable >> (GenericHashtable). The performance >> is almost the same. >> GenericHashtable is little faster, since ResourceHashtable requires 2 >> lookups (1 to check >> if the element is in the hashtable and the 2nd when adding the >> element) to add a non-existing item >> to the hashtable. >> >> We could change ResourceHashtable such that it returns NULL if the >> item is added to the hashtable and >> a pointer to the previously stored value, if the item already existed. >> The Java hashtable has the same >> signature for put(). What do you think? >> We can also leave ResourceHashtable as it is, I do not insist on this >> change. > > That seems fine to do if it improves performance. There is only one > other use of this hashtable now that would benefit from this change also > in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth > tests that will exercise that code. > > Thanks, > Coleen >> >> In any case, we should remove GenericHashtable. I filed >> https://bugs.openjdk.java.net/browse/JDK-8035946 . >> If we decide to do the suggested change in ResourceHashtable, I guess >> it would be best to send the RFR >> to hotspot-dev ? >> >> Best, >> Albert >> >> >> On 02/26/2014 08:57 PM, Vladimir Kozlov wrote: >>> I have asked Albert to try ResourceHashtable and if it gives us the >>> same results we may remove the new one. I think the confusion come >>> from the fact that it is in a different file. We thought all >>> hashtables are in hashtable.hpp. >>> >>> Regards, >>> Vladimir >>> >>> On 2/26/14 11:51 AM, Coleen Phillimore wrote: >>>> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >>>>> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>>>>> Too late Coleen, it is pushed already. It was on review on >>>>>> hotspot-dev since last week. >>>>>> I did not know about ResourceHashtable. Why it is in different file? >>>>>> I will let Albert investigate the possibility of use >>>>>> ResourceHashtable. >>>>> >>>>> Bummer, I tagged it but didn't get to it. I was on vacation this >>>>> week. There are a few more ad-hoc hashtables too in class file >>>>> parser that I thought we could use Keith's hashtable for also. It's in >>>>> the utilities directory... >>>> >>>> Sorry, to be clear, I think the runtime group should do the classfile >>>> parser ones... >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Albert, >>>>>>> >>>>>>> This looks like nice work but it seems to add another completely >>>>>>> different hashtable to the system. I was expecting this change >>>>>>> to be >>>>>>> generalizing BasicHashTable to allow resource allocation but it >>>>>>> doesn't >>>>>>> do that. It doesn't seem to make this easier to do either >>>>>>> because it >>>>>>> uses different names and doesn't have the hashing and other >>>>>>> functionality that the general case needs. Was there a plan to do >>>>>>> this? >>>>>>> >>>>>>> Keith McGuigan added a resource allocated hashtable also in >>>>>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>>>>>> needs? >>>>>>> >>>>>>> I think we shouldn't add a generalized class like this if it >>>>>>> doesn't or >>>>>>> can't support the general case - ie. the C_heap hashtable uses in >>>>>>> the >>>>>>> JVM, specificially for the symbol, string, and system dictionaries. >>>>>>> It's >>>>>>> just a lot of extra code and complex template parameters. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> I agree that your version is more clear. Here is the updated >>>>>>>> webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>>>>> Can you align methods bodies?: >>>>>>>>> >>>>>>>>> + T* next() const { return _next; } >>>>>>>>> + T* prev() const { return _prev; } >>>>>>>>> + void set_next(T* item) { _next = item; } >>>>>>>>> + void set_prev(T* item) { _prev = item; } >>>>>>>>> >>>>>>>>> I am not sure that your methods factoring will produce better code >>>>>>>>> with all C++ compilers. You added switch which you assume will >>>>>>>>> constant-fold but it is not guarantee. >>>>>>>>> >>>>>>>>> When I asked about refactoring I meant something a little simpler. >>>>>>>>> To have inlined index(item) method in GenericHashtable: >>>>>>>>> >>>>>>>>> int index(T* item)) { assert(item != NULL, "missing null >>>>>>>>> check"); >>>>>>>>> return item->key() % size(); } >>>>>>>>> >>>>>>>>> and have only your contains_impl() as common method >>>>>>>>> >>>>>>>>> template T* GenericHashtable::contains(T* >>>>>>>>> item) { >>>>>>>>> if (item != NULL) { >>>>>>>>> int idx = index(item); >>>>>>>>> return contains_impl(item, idx); >>>>>>>>> } >>>>>>>>> return NULL; >>>>>>>>> } >>>>>>>>> >>>>>>>>> template bool GenericHashtable::add(T* >>>>>>>>> item) { >>>>>>>>> if (item != NULL) { >>>>>>>>> int idx = index(item); >>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>> if (found_item == NULL) { >>>>>>>>> ... // code from add_impl() after (!contains) check >>>>>>>>> return true; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> return false; >>>>>>>>> } >>>>>>>>> >>>>>>>>> template T* GenericHashtable::remove(T* >>>>>>>>> item) { >>>>>>>>> if (item != NULL) { >>>>>>>>> int idx = index(item); >>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>> if (found_item != NULL) { >>>>>>>>> ... // code from remove_impl() after (contains) check >>>>>>>>> return found_item; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> return NULL; >>>>>>>>> } >>>>>>>>> >>>>>>>>> I think it is more clear. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and your >>>>>>>>>> feedback. >>>>>>>>>> >>>>>>>>>> @Vladimir: >>>>>>>>>> No, this change is based on the version of 7194669. However, >>>>>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>>>>> make the >>>>>>>>>> code more readable (for me). >>>>>>>>>> >>>>>>>>>> I have changed the parameter name, (bool C_heap = false), adapted >>>>>>>>>> the >>>>>>>>>> 'add' function >>>>>>>>>> according to your suggestion, and implemented the hashtable >>>>>>>>>> destructor >>>>>>>>>> as well as the >>>>>>>>>> remove function. >>>>>>>>>> >>>>>>>>>> @Christian: >>>>>>>>>> This for noticing this inconsistency. I fixed the parameter names >>>>>>>>>> >>>>>>>>>> @Vitaly: >>>>>>>>>> I would prefer to leave the size parameter as it is now. While we >>>>>>>>>> would >>>>>>>>>> save some instructions, >>>>>>>>>> I think that specifying the size of the hashtable where it is >>>>>>>>>> used >>>>>>>>>> makes >>>>>>>>>> the code more readable. >>>>>>>>>> >>>>>>>>>> Shouldn't we, in general, try to avoid hash table sizes that >>>>>>>>>> are an >>>>>>>>>> exact power of 2? >>>>>>>>>> >>>>>>>>>> Here is the new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>>>>> >>>>>>>>>>>> Note the current hashtable allocates only in c_heap. Albert >>>>>>>>>>>> added >>>>>>>>>>>> hashtable which can allocate in thread local resource area for >>>>>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>>>>> >>>>>>>>>>>> Albert, >>>>>>>>>>>> >>>>>>>>>>>> So you restored code in dependencies.?pp to one before 7194669 >>>>>>>>>>>> fix. >>>>>>>>>>>> Right? >>>>>>>>>>>> >>>>>>>>>>>> I think you need to follow GrowableArray example to name >>>>>>>>>>>> parameter >>>>>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>>>>> should be >>>>>>>>>>>> saved in a field because you need to free c_heap in >>>>>>>>>>>> destructor if >>>>>>>>>>>> C-heap is used: >>>>>>>>>>>> >>>>>>>>>>>> ~GrowableArray() { if (on_C_heap()) clear_and_deallocate(); } >>>>>>>>>>>> >>>>>>>>>>>> Also I think you should avoid call to contains(item) in >>>>>>>>>>>> add() to >>>>>>>>>>>> avoid doing the same thing twice. >>>>>>>>>>> ?and you should stick to either item or element: >>>>>>>>>>> >>>>>>>>>>> + template bool GenericHashtable::add(T* >>>>>>>>>>> item) { >>>>>>>>>>> + template bool GenericHashtable>>>>>>>>>> F>::contains(T* >>>>>>>>>>> element) { >>>>>>>>>>> >>>>>>>>>>>> You should implement remove(). >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Vladimir >>>>>>>>>>>> >>>>>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>>>>>> supposed to >>>>>>>>>>>>> speed-up dependency checking >>>>>>>>>>>>> causes a performance regression. The reason >>>>>>>>>>>>> for the >>>>>>>>>>>>> performance regression is that most dependencies >>>>>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>>>>> determining if >>>>>>>>>>>>> the dependency is already checked plus the >>>>>>>>>>>>> overhead of dependency checking. The >>>>>>>>>>>>> overhead of >>>>>>>>>>>>> searching is significant, since we perform >>>>>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>>>>>> already >>>>>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>>>>> required >>>>>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>>>>> can be easily extended as needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test >>>>>>>>>>>>> case >>>>>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>>>>> following >>>>>>>>>>>>> times spent for dependency checking: >>>>>>>>>>>>> >>>>>>>>>>>>> with this patch: 844s >>>>>>>>>>>>> 7194669: 1080s >>>>>>>>>>>>> before 7194669: 5223s >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Albert >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> > From albert.noll at oracle.com Thu Feb 27 10:44:49 2014 From: albert.noll at oracle.com (Albert) Date: Thu, 27 Feb 2014 19:44:49 +0100 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530F81FB.4000006@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> <530E4742.20006@oracle.com> <530F4ABE.9040509@oracle.com> <530F6D96.20206@oracle.com> <530F81FB.4000006@oracle.com> Message-ID: <530F87A1.6090901@oracle.com> Hi, it seems that the proposed change to ResourceHashtable does not imply changes in src/share/vm/classfile/defaultMethods.cpp . I think the proposed change affects only performance of dependency checking. Best, Albert On 02/27/2014 07:20 PM, Vladimir Kozlov wrote: > > in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth > > tests that will exercise that code. > > Coleen, can we measure performance with them or they checks only > correctness? > > I am for improving performance of ResourceHashtable. > > Thanks, > Vladimir > > On 2/27/14 8:53 AM, Coleen Phillimore wrote: >> >> Albert, Thank you for doing this investigation. I'm sorry I didn't >> notice it sooner. >> >> On 2/27/14 9:25 AM, Albert wrote: >>> Hi, >>> >>> thanks for your feedback. That hashtable (ResourceHashtable) was >>> exactly what I was looking for. >>> Unfortunately, I did not know it existed... >>> >>> I implemented a different version of 8034839 that uses >>> ResourceHashtable and compared >>> the results against the version of the newly added hashtable >>> (GenericHashtable). The performance >>> is almost the same. >>> GenericHashtable is little faster, since ResourceHashtable requires 2 >>> lookups (1 to check >>> if the element is in the hashtable and the 2nd when adding the >>> element) to add a non-existing item >>> to the hashtable. >>> >>> We could change ResourceHashtable such that it returns NULL if the >>> item is added to the hashtable and >>> a pointer to the previously stored value, if the item already existed. >>> The Java hashtable has the same >>> signature for put(). What do you think? >>> We can also leave ResourceHashtable as it is, I do not insist on this >>> change. >> >> That seems fine to do if it improves performance. There is only one >> other use of this hashtable now that would benefit from this change also >> in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth >> tests that will exercise that code. >> >> Thanks, >> Coleen >>> >>> In any case, we should remove GenericHashtable. I filed >>> https://bugs.openjdk.java.net/browse/JDK-8035946 . >>> If we decide to do the suggested change in ResourceHashtable, I guess >>> it would be best to send the RFR >>> to hotspot-dev ? >>> >>> Best, >>> Albert >>> >>> >>> On 02/26/2014 08:57 PM, Vladimir Kozlov wrote: >>>> I have asked Albert to try ResourceHashtable and if it gives us the >>>> same results we may remove the new one. I think the confusion come >>>> from the fact that it is in a different file. We thought all >>>> hashtables are in hashtable.hpp. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 2/26/14 11:51 AM, Coleen Phillimore wrote: >>>>> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >>>>>> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>>>>>> Too late Coleen, it is pushed already. It was on review on >>>>>>> hotspot-dev since last week. >>>>>>> I did not know about ResourceHashtable. Why it is in different >>>>>>> file? >>>>>>> I will let Albert investigate the possibility of use >>>>>>> ResourceHashtable. >>>>>> >>>>>> Bummer, I tagged it but didn't get to it. I was on vacation this >>>>>> week. There are a few more ad-hoc hashtables too in class file >>>>>> parser that I thought we could use Keith's hashtable for also. >>>>>> It's in >>>>>> the utilities directory... >>>>> >>>>> Sorry, to be clear, I think the runtime group should do the classfile >>>>> parser ones... >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Albert, >>>>>>>> >>>>>>>> This looks like nice work but it seems to add another completely >>>>>>>> different hashtable to the system. I was expecting this change >>>>>>>> to be >>>>>>>> generalizing BasicHashTable to allow resource allocation but it >>>>>>>> doesn't >>>>>>>> do that. It doesn't seem to make this easier to do either >>>>>>>> because it >>>>>>>> uses different names and doesn't have the hashing and other >>>>>>>> functionality that the general case needs. Was there a plan >>>>>>>> to do >>>>>>>> this? >>>>>>>> >>>>>>>> Keith McGuigan added a resource allocated hashtable also in >>>>>>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve your >>>>>>>> needs? >>>>>>>> >>>>>>>> I think we shouldn't add a generalized class like this if it >>>>>>>> doesn't or >>>>>>>> can't support the general case - ie. the C_heap hashtable uses in >>>>>>>> the >>>>>>>> JVM, specificially for the symbol, string, and system >>>>>>>> dictionaries. >>>>>>>> It's >>>>>>>> just a lot of extra code and complex template parameters. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> I agree that your version is more clear. Here is the updated >>>>>>>>> webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>>>>>> Can you align methods bodies?: >>>>>>>>>> >>>>>>>>>> + T* next() const { return _next; } >>>>>>>>>> + T* prev() const { return _prev; } >>>>>>>>>> + void set_next(T* item) { _next = item; } >>>>>>>>>> + void set_prev(T* item) { _prev = item; } >>>>>>>>>> >>>>>>>>>> I am not sure that your methods factoring will produce better >>>>>>>>>> code >>>>>>>>>> with all C++ compilers. You added switch which you assume will >>>>>>>>>> constant-fold but it is not guarantee. >>>>>>>>>> >>>>>>>>>> When I asked about refactoring I meant something a little >>>>>>>>>> simpler. >>>>>>>>>> To have inlined index(item) method in GenericHashtable: >>>>>>>>>> >>>>>>>>>> int index(T* item)) { assert(item != NULL, "missing null >>>>>>>>>> check"); >>>>>>>>>> return item->key() % size(); } >>>>>>>>>> >>>>>>>>>> and have only your contains_impl() as common method >>>>>>>>>> >>>>>>>>>> template T* GenericHashtable>>>>>>>>> F>::contains(T* >>>>>>>>>> item) { >>>>>>>>>> if (item != NULL) { >>>>>>>>>> int idx = index(item); >>>>>>>>>> return contains_impl(item, idx); >>>>>>>>>> } >>>>>>>>>> return NULL; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> template bool GenericHashtable::add(T* >>>>>>>>>> item) { >>>>>>>>>> if (item != NULL) { >>>>>>>>>> int idx = index(item); >>>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>>> if (found_item == NULL) { >>>>>>>>>> ... // code from add_impl() after (!contains) check >>>>>>>>>> return true; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> return false; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> template T* GenericHashtable::remove(T* >>>>>>>>>> item) { >>>>>>>>>> if (item != NULL) { >>>>>>>>>> int idx = index(item); >>>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>>> if (found_item != NULL) { >>>>>>>>>> ... // code from remove_impl() after (contains) check >>>>>>>>>> return found_item; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> return NULL; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> I think it is more clear. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and >>>>>>>>>>> your >>>>>>>>>>> feedback. >>>>>>>>>>> >>>>>>>>>>> @Vladimir: >>>>>>>>>>> No, this change is based on the version of 7194669. However, >>>>>>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>>>>>> make the >>>>>>>>>>> code more readable (for me). >>>>>>>>>>> >>>>>>>>>>> I have changed the parameter name, (bool C_heap = false), >>>>>>>>>>> adapted >>>>>>>>>>> the >>>>>>>>>>> 'add' function >>>>>>>>>>> according to your suggestion, and implemented the hashtable >>>>>>>>>>> destructor >>>>>>>>>>> as well as the >>>>>>>>>>> remove function. >>>>>>>>>>> >>>>>>>>>>> @Christian: >>>>>>>>>>> This for noticing this inconsistency. I fixed the parameter >>>>>>>>>>> names >>>>>>>>>>> >>>>>>>>>>> @Vitaly: >>>>>>>>>>> I would prefer to leave the size parameter as it is now. >>>>>>>>>>> While we >>>>>>>>>>> would >>>>>>>>>>> save some instructions, >>>>>>>>>>> I think that specifying the size of the hashtable where it is >>>>>>>>>>> used >>>>>>>>>>> makes >>>>>>>>>>> the code more readable. >>>>>>>>>>> >>>>>>>>>>> Shouldn't we, in general, try to avoid hash table sizes that >>>>>>>>>>> are an >>>>>>>>>>> exact power of 2? >>>>>>>>>>> >>>>>>>>>>> Here is the new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>>>>>> >>>>>>>>>>>>> Note the current hashtable allocates only in c_heap. Albert >>>>>>>>>>>>> added >>>>>>>>>>>>> hashtable which can allocate in thread local resource area >>>>>>>>>>>>> for >>>>>>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>>>>>> >>>>>>>>>>>>> Albert, >>>>>>>>>>>>> >>>>>>>>>>>>> So you restored code in dependencies.?pp to one before >>>>>>>>>>>>> 7194669 >>>>>>>>>>>>> fix. >>>>>>>>>>>>> Right? >>>>>>>>>>>>> >>>>>>>>>>>>> I think you need to follow GrowableArray example to name >>>>>>>>>>>>> parameter >>>>>>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>>>>>> should be >>>>>>>>>>>>> saved in a field because you need to free c_heap in >>>>>>>>>>>>> destructor if >>>>>>>>>>>>> C-heap is used: >>>>>>>>>>>>> >>>>>>>>>>>>> ~GrowableArray() { if (on_C_heap()) >>>>>>>>>>>>> clear_and_deallocate(); } >>>>>>>>>>>>> >>>>>>>>>>>>> Also I think you should avoid call to contains(item) in >>>>>>>>>>>>> add() to >>>>>>>>>>>>> avoid doing the same thing twice. >>>>>>>>>>>> ?and you should stick to either item or element: >>>>>>>>>>>> >>>>>>>>>>>> + template bool GenericHashtable>>>>>>>>>>> F>::add(T* >>>>>>>>>>>> item) { >>>>>>>>>>>> + template bool GenericHashtable>>>>>>>>>>> F>::contains(T* >>>>>>>>>>>> element) { >>>>>>>>>>>> >>>>>>>>>>>>> You should implement remove(). >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Vladimir >>>>>>>>>>>>> >>>>>>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: The problem is that the patch (7194669) - which was >>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>> speed-up dependency checking >>>>>>>>>>>>>> causes a performance regression. The reason >>>>>>>>>>>>>> for the >>>>>>>>>>>>>> performance regression is that most dependencies >>>>>>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>>>>>> determining if >>>>>>>>>>>>>> the dependency is already checked plus the >>>>>>>>>>>>>> overhead of dependency checking. The >>>>>>>>>>>>>> overhead of >>>>>>>>>>>>>> searching is significant, since we perform >>>>>>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: Use a hashtable instead of linear search to lookup >>>>>>>>>>>>>> already >>>>>>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>>>>>> required >>>>>>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>>>>>> can be easily extended as needed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test >>>>>>>>>>>>>> case >>>>>>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>>>>>> following >>>>>>>>>>>>>> times spent for dependency checking: >>>>>>>>>>>>>> >>>>>>>>>>>>>> with this patch: 844s >>>>>>>>>>>>>> 7194669: 1080s >>>>>>>>>>>>>> before 7194669: 5223s >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Albert >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From coleen.phillimore at oracle.com Thu Feb 27 10:50:51 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 27 Feb 2014 13:50:51 -0500 Subject: [9] RFR(S): 8034839: jvm hangs with gc/gctests/LoadUnloadGC test In-Reply-To: <530F87A1.6090901@oracle.com> References: <530708A7.1030700@oracle.com> <5307A8B5.2050307@oracle.com> <530C94CB.3030800@oracle.com> <530CFA42.1090307@oracle.com> <530D9035.3080709@oracle.com> <530E3330.9090809@oracle.com> <530E3D20.8070007@oracle.com> <530E44B0.7080805@oracle.com> <530E45B7.4060603@oracle.com> <530E4742.20006@oracle.com> <530F4ABE.9040509@oracle.com> <530F6D96.20206@oracle.com> <530F81FB.4000006@oracle.com> <530F87A1.6090901@oracle.com> Message-ID: <530F890B.9010800@oracle.com> On 2/27/14 1:44 PM, Albert wrote: > Hi, > > it seems that the proposed change to ResourceHashtable does not imply > changes in > src/share/vm/classfile/defaultMethods.cpp . I think the proposed > change affects only > performance of dependency checking. Okay. That's good then. Coleen > > Best, > Albert > > On 02/27/2014 07:20 PM, Vladimir Kozlov wrote: >> > in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth >> > tests that will exercise that code. >> >> Coleen, can we measure performance with them or they checks only >> correctness? >> >> I am for improving performance of ResourceHashtable. >> >> Thanks, >> Vladimir >> >> On 2/27/14 8:53 AM, Coleen Phillimore wrote: >>> >>> Albert, Thank you for doing this investigation. I'm sorry I didn't >>> notice it sooner. >>> >>> On 2/27/14 9:25 AM, Albert wrote: >>>> Hi, >>>> >>>> thanks for your feedback. That hashtable (ResourceHashtable) was >>>> exactly what I was looking for. >>>> Unfortunately, I did not know it existed... >>>> >>>> I implemented a different version of 8034839 that uses >>>> ResourceHashtable and compared >>>> the results against the version of the newly added hashtable >>>> (GenericHashtable). The performance >>>> is almost the same. >>>> GenericHashtable is little faster, since ResourceHashtable requires 2 >>>> lookups (1 to check >>>> if the element is in the hashtable and the 2nd when adding the >>>> element) to add a non-existing item >>>> to the hashtable. >>>> >>>> We could change ResourceHashtable such that it returns NULL if the >>>> item is added to the hashtable and >>>> a pointer to the previously stored value, if the item already existed. >>>> The Java hashtable has the same >>>> signature for put(). What do you think? >>>> We can also leave ResourceHashtable as it is, I do not insist on this >>>> change. >>> >>> That seems fine to do if it improves performance. There is only one >>> other use of this hashtable now that would benefit from this change >>> also >>> in src/share/vm/classfile/defaultMethods.cpp. There are nsk defmeth >>> tests that will exercise that code. >>> >>> Thanks, >>> Coleen >>>> >>>> In any case, we should remove GenericHashtable. I filed >>>> https://bugs.openjdk.java.net/browse/JDK-8035946 . >>>> If we decide to do the suggested change in ResourceHashtable, I guess >>>> it would be best to send the RFR >>>> to hotspot-dev ? >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 02/26/2014 08:57 PM, Vladimir Kozlov wrote: >>>>> I have asked Albert to try ResourceHashtable and if it gives us the >>>>> same results we may remove the new one. I think the confusion come >>>>> from the fact that it is in a different file. We thought all >>>>> hashtables are in hashtable.hpp. >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 2/26/14 11:51 AM, Coleen Phillimore wrote: >>>>>> On 2/26/2014 2:46 PM, Coleen Phillimore wrote: >>>>>>> On 2/26/2014 2:14 PM, Vladimir Kozlov wrote: >>>>>>>> Too late Coleen, it is pushed already. It was on review on >>>>>>>> hotspot-dev since last week. >>>>>>>> I did not know about ResourceHashtable. Why it is in different >>>>>>>> file? >>>>>>>> I will let Albert investigate the possibility of use >>>>>>>> ResourceHashtable. >>>>>>> >>>>>>> Bummer, I tagged it but didn't get to it. I was on vacation this >>>>>>> week. There are a few more ad-hoc hashtables too in class file >>>>>>> parser that I thought we could use Keith's hashtable for also. >>>>>>> It's in >>>>>>> the utilities directory... >>>>>> >>>>>> Sorry, to be clear, I think the runtime group should do the >>>>>> classfile >>>>>> parser ones... >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 2/26/14 10:32 AM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> Albert, >>>>>>>>> >>>>>>>>> This looks like nice work but it seems to add another completely >>>>>>>>> different hashtable to the system. I was expecting this change >>>>>>>>> to be >>>>>>>>> generalizing BasicHashTable to allow resource allocation but it >>>>>>>>> doesn't >>>>>>>>> do that. It doesn't seem to make this easier to do either >>>>>>>>> because it >>>>>>>>> uses different names and doesn't have the hashing and other >>>>>>>>> functionality that the general case needs. Was there a plan >>>>>>>>> to do >>>>>>>>> this? >>>>>>>>> >>>>>>>>> Keith McGuigan added a resource allocated hashtable also in >>>>>>>>> src/share/vm/utilities/resourceHash.hpp. Can this not serve >>>>>>>>> your >>>>>>>>> needs? >>>>>>>>> >>>>>>>>> I think we shouldn't add a generalized class like this if it >>>>>>>>> doesn't or >>>>>>>>> can't support the general case - ie. the C_heap hashtable uses in >>>>>>>>> the >>>>>>>>> JVM, specificially for the symbol, string, and system >>>>>>>>> dictionaries. >>>>>>>>> It's >>>>>>>>> just a lot of extra code and complex template parameters. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 2/26/2014 1:56 AM, Albert wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> I agree that your version is more clear. Here is the updated >>>>>>>>>> webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.02/ >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> On 02/25/2014 09:17 PM, Vladimir Kozlov wrote: >>>>>>>>>>> Can you align methods bodies?: >>>>>>>>>>> >>>>>>>>>>> + T* next() const { return _next; } >>>>>>>>>>> + T* prev() const { return _prev; } >>>>>>>>>>> + void set_next(T* item) { _next = item; } >>>>>>>>>>> + void set_prev(T* item) { _prev = item; } >>>>>>>>>>> >>>>>>>>>>> I am not sure that your methods factoring will produce >>>>>>>>>>> better code >>>>>>>>>>> with all C++ compilers. You added switch which you assume will >>>>>>>>>>> constant-fold but it is not guarantee. >>>>>>>>>>> >>>>>>>>>>> When I asked about refactoring I meant something a little >>>>>>>>>>> simpler. >>>>>>>>>>> To have inlined index(item) method in GenericHashtable: >>>>>>>>>>> >>>>>>>>>>> int index(T* item)) { assert(item != NULL, "missing null >>>>>>>>>>> check"); >>>>>>>>>>> return item->key() % size(); } >>>>>>>>>>> >>>>>>>>>>> and have only your contains_impl() as common method >>>>>>>>>>> >>>>>>>>>>> template T* GenericHashtable>>>>>>>>>> F>::contains(T* >>>>>>>>>>> item) { >>>>>>>>>>> if (item != NULL) { >>>>>>>>>>> int idx = index(item); >>>>>>>>>>> return contains_impl(item, idx); >>>>>>>>>>> } >>>>>>>>>>> return NULL; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> template bool GenericHashtable::add(T* >>>>>>>>>>> item) { >>>>>>>>>>> if (item != NULL) { >>>>>>>>>>> int idx = index(item); >>>>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>>>> if (found_item == NULL) { >>>>>>>>>>> ... // code from add_impl() after (!contains) check >>>>>>>>>>> return true; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> return false; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> template T* GenericHashtable::remove(T* >>>>>>>>>>> item) { >>>>>>>>>>> if (item != NULL) { >>>>>>>>>>> int idx = index(item); >>>>>>>>>>> T* found_item = contains_impl(item, idx); >>>>>>>>>>> if (found_item != NULL) { >>>>>>>>>>> ... // code from remove_impl() after (contains) check >>>>>>>>>>> return found_item; >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> return NULL; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> I think it is more clear. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 2/25/14 5:04 AM, Albert wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Vladimir, Christian, Vitaly, thanks for looking at this and >>>>>>>>>>>> your >>>>>>>>>>>> feedback. >>>>>>>>>>>> >>>>>>>>>>>> @Vladimir: >>>>>>>>>>>> No, this change is based on the version of 7194669. However, >>>>>>>>>>>> the diff to before 7194669 are mainly code refactorings, which >>>>>>>>>>>> make the >>>>>>>>>>>> code more readable (for me). >>>>>>>>>>>> >>>>>>>>>>>> I have changed the parameter name, (bool C_heap = false), >>>>>>>>>>>> adapted >>>>>>>>>>>> the >>>>>>>>>>>> 'add' function >>>>>>>>>>>> according to your suggestion, and implemented the hashtable >>>>>>>>>>>> destructor >>>>>>>>>>>> as well as the >>>>>>>>>>>> remove function. >>>>>>>>>>>> >>>>>>>>>>>> @Christian: >>>>>>>>>>>> This for noticing this inconsistency. I fixed the parameter >>>>>>>>>>>> names >>>>>>>>>>>> >>>>>>>>>>>> @Vitaly: >>>>>>>>>>>> I would prefer to leave the size parameter as it is now. >>>>>>>>>>>> While we >>>>>>>>>>>> would >>>>>>>>>>>> save some instructions, >>>>>>>>>>>> I think that specifying the size of the hashtable where it is >>>>>>>>>>>> used >>>>>>>>>>>> makes >>>>>>>>>>>> the code more readable. >>>>>>>>>>>> >>>>>>>>>>>> Shouldn't we, in general, try to avoid hash table sizes that >>>>>>>>>>>> are an >>>>>>>>>>>> exact power of 2? >>>>>>>>>>>> >>>>>>>>>>>> Here is the new webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Albert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 02/21/2014 11:54 PM, Christian Thalinger wrote: >>>>>>>>>>>>> On Feb 21, 2014, at 11:27 AM, Vladimir Kozlov >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Lets discuss it on hotspot-dev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note the current hashtable allocates only in c_heap. Albert >>>>>>>>>>>>>> added >>>>>>>>>>>>>> hashtable which can allocate in thread local resource >>>>>>>>>>>>>> area for >>>>>>>>>>>>>> temporary table and c_heap for long live table. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Albert, >>>>>>>>>>>>>> >>>>>>>>>>>>>> So you restored code in dependencies.?pp to one before >>>>>>>>>>>>>> 7194669 >>>>>>>>>>>>>> fix. >>>>>>>>>>>>>> Right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you need to follow GrowableArray example to name >>>>>>>>>>>>>> parameter >>>>>>>>>>>>>> "bool C_heap = false" instead of "bool resource_mark". It >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> saved in a field because you need to free c_heap in >>>>>>>>>>>>>> destructor if >>>>>>>>>>>>>> C-heap is used: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ~GrowableArray() { if (on_C_heap()) >>>>>>>>>>>>>> clear_and_deallocate(); } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also I think you should avoid call to contains(item) in >>>>>>>>>>>>>> add() to >>>>>>>>>>>>>> avoid doing the same thing twice. >>>>>>>>>>>>> ?and you should stick to either item or element: >>>>>>>>>>>>> >>>>>>>>>>>>> + template bool GenericHashtable>>>>>>>>>>>> F>::add(T* >>>>>>>>>>>>> item) { >>>>>>>>>>>>> + template bool GenericHashtable>>>>>>>>>>>> F>::contains(T* >>>>>>>>>>>>> element) { >>>>>>>>>>>>> >>>>>>>>>>>>>> You should implement remove(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Vladimir >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/21/14 12:04 AM, Albert wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> could I get reviews for this small patch? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8034839 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Problem: The problem is that the patch (7194669) - which >>>>>>>>>>>>>>> was >>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>> speed-up dependency checking >>>>>>>>>>>>>>> causes a performance regression. The reason >>>>>>>>>>>>>>> for the >>>>>>>>>>>>>>> performance regression is that most dependencies >>>>>>>>>>>>>>> are unique, so we have the overhead of >>>>>>>>>>>>>>> determining if >>>>>>>>>>>>>>> the dependency is already checked plus the >>>>>>>>>>>>>>> overhead of dependency checking. The >>>>>>>>>>>>>>> overhead of >>>>>>>>>>>>>>> searching is significant, since we perform >>>>>>>>>>>>>>> a linear search on 6000+ items each time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Solution: Use a hashtable instead of linear search to >>>>>>>>>>>>>>> lookup >>>>>>>>>>>>>>> already >>>>>>>>>>>>>>> checked dependencies. The new hashtable >>>>>>>>>>>>>>> is very rudimentary. It provides only the >>>>>>>>>>>>>>> required >>>>>>>>>>>>>>> functionality to solve this bug. However, the functionality >>>>>>>>>>>>>>> can be easily extended as needed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: jprt, failing test case, nashorn. The failing test >>>>>>>>>>>>>>> case >>>>>>>>>>>>>>> completes in approx. the same time as before 7194669. >>>>>>>>>>>>>>> For nashorn + Octane, this patch yields the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> times spent for dependency checking: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with this patch: 844s >>>>>>>>>>>>>>> 7194669: 1080s >>>>>>>>>>>>>>> before 7194669: 5223s >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anoll/8034939/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Albert >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From daniel.daugherty at oracle.com Thu Feb 27 11:09:06 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 27 Feb 2014 12:09:06 -0700 Subject: 2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530EF65C.5040707@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> Message-ID: <530F8D52.2040400@oracle.com> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 > src/share/vm/runtime/vm_operations.hpp No comments. src/share/vm/prims/jvmtiEnvBase.hpp No comments. src/share/vm/prims/jvmtiEnv.cpp No comments. src/share/vm/prims/jvmtiEnvThreadState.cpp No comments. src/share/vm/prims/jvmtiEventController.cpp JvmtiEventController::set_frame_pop() is called by JvmtiEnvThreadState::set_frame_pop() which is called by JvmtiEnv::NotifyFramePop(). The "MutexLocker mu(JvmtiThreadState_lock)" in JvmtiEventController::set_frame_pop() protected the work done by JvmtiEventControllerPrivate::set_frame_pop(): ets->get_frame_pops()->set(fpop); recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); Since multiple threads can call JVM/TI NotifyFramePop() on the same target thread, what keeps the threads from messing with the list of frame pops simultaneously or messing with the thread enabled events bits in parallel? I suspect that this might also be an issue for JvmtiEventController::clear_frame_pop() and JvmtiEventController::clear_to_frame_pop() also. src/share/vm/prims/jvmtiThreadState.cpp No comments. Dan > > Summary: > > It is the 2-nd round of review because the JTREG com/sun/jdi tests > discovered a regression > in the first round change. The issue was in the > JvmtiEventController::clear_frame_pop() > lock synchronization that is not allowed at safepoints. > > As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM > operation for safety. > Also, I've removed the lock synchronization from the 3 impacted > JvmtiEventController:: > functions: set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). > > Testing: > In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei > > > On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >> >> >> Summary: >> >> This is another Test Stabilization issue. >> The fix is very similar to other JVMTI stabilization fixes. >> It is to use safepoints for updating the PopFrame data instead of >> relying on the >> suspend equivalent condition mechanism >> (JvmtiEnv::is_thread_fully_suspended()) >> which is not adequate from the reliability point of view. >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> > From goetz.lindenmaier at sap.com Thu Feb 27 11:45:47 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 27 Feb 2014 19:45:47 +0000 Subject: RFR(XS): 8035970: PPC64: fix ad file after 8027754: Enable loop optimizations for loops with MathExact Message-ID: <4295855A5C1DE049A61835A1887419CC2CEA4FAA@DEWDFEMB12A.global.corp.sap> Hi, please review and test this tiny change. It needs to go to hs-comp to fix the ppc64 build after 8027754. http://cr.openjdk.java.net/~goetz/webrevs/8035970/ thanks and best regards, Goetz. From vladimir.kozlov at oracle.com Thu Feb 27 12:27:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Feb 2014 12:27:35 -0800 Subject: RFR(XS): 8035970: PPC64: fix ad file after 8027754: Enable loop optimizations for loops with MathExact In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA4FAA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA4FAA@DEWDFEMB12A.global.corp.sap> Message-ID: <530F9FB7.1080705@oracle.com> Good. It is in JPRT for push. Thanks, Vladimir On 2/27/14 11:45 AM, Lindenmaier, Goetz wrote: > Hi, > > please review and test this tiny change. > It needs to go to hs-comp to fix the ppc64 build after 8027754. > http://cr.openjdk.java.net/~goetz/webrevs/8035970/ > > thanks and best regards, > Goetz. > From serguei.spitsyn at oracle.com Thu Feb 27 12:28:35 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Feb 2014 12:28:35 -0800 Subject: 2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530F8D52.2040400@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> Message-ID: <530F9FF3.7030209@oracle.com> Dan, Thank you a lot for reviewing this! On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: > On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >> > > src/share/vm/runtime/vm_operations.hpp > No comments. > > src/share/vm/prims/jvmtiEnvBase.hpp > No comments. > > src/share/vm/prims/jvmtiEnv.cpp > No comments. > > src/share/vm/prims/jvmtiEnvThreadState.cpp > No comments. > > src/share/vm/prims/jvmtiEventController.cpp > JvmtiEventController::set_frame_pop() is called by > JvmtiEnvThreadState::set_frame_pop() which is called by > JvmtiEnv::NotifyFramePop(). > > The "MutexLocker mu(JvmtiThreadState_lock)" in > JvmtiEventController::set_frame_pop() protected the work > done by JvmtiEventControllerPrivate::set_frame_pop(): > > ets->get_frame_pops()->set(fpop); > recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); Your check is the right thing to do, thanks! I had to explain this more clearly in this 2-nd review request. The approach I've taken here is that all this code paths are executed on the target thread or at a safepoint. It is true for all 3 functions: set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). And the updated assert guards ensure that it is the case. It could be a good idea to add a No_Safepoint_Verifier for PopFrame() and NotifyFramePop() to make sure the current/target thread does not go to safepoint until it is returned from update_for_pop_top_frame() and set_frame_pop() correspondingly. A No_Safepoint_Verifier can be also needed in the JvmtiExport::post_method_exit(). These are all places where these functions are called: prims/jvmtiEnv.cpp: state->env_thread_state(this)->set_frame_pop(frame_number); // JvmtiEnv::NotifyFramePop() prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // JvmtiExport::post_method_exit() prims/jvmtiThreadState.cpp: ets->clear_frame_pop(popframe_number); // JvmtiThreadState::update_for_pop_top_frame() The function JvmtiEnvThreadState::clear_to_frame_pop() is never called now. Thanks, Serguei > > Since multiple threads can call JVM/TI NotifyFramePop() on the > same target thread, what keeps the threads from messing with > the list of frame pops simultaneously or messing with the > thread enabled events bits in parallel? > > I suspect that this might also be an issue for > JvmtiEventController::clear_frame_pop() and > JvmtiEventController::clear_to_frame_pop() also. > > src/share/vm/prims/jvmtiThreadState.cpp > No comments. > > Dan > > >> >> Summary: >> >> It is the 2-nd round of review because the JTREG com/sun/jdi tests >> discovered a regression >> in the first round change. The issue was in the >> JvmtiEventController::clear_frame_pop() >> lock synchronization that is not allowed at safepoints. >> >> As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM >> operation for safety. >> Also, I've removed the lock synchronization from the 3 impacted >> JvmtiEventController:: >> functions: set_frame_pop(), clear_frame_pop() and >> clear_to_frame_pop(). >> >> Testing: >> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> >> >> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>> >>> >>> Summary: >>> >>> This is another Test Stabilization issue. >>> The fix is very similar to other JVMTI stabilization fixes. >>> It is to use safepoints for updating the PopFrame data instead of >>> relying on the >>> suspend equivalent condition mechanism >>> (JvmtiEnv::is_thread_fully_suspended()) >>> which is not adequate from the reliability point of view. >>> >>> Testing: >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Thu Feb 27 13:03:27 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Feb 2014 13:03:27 -0800 Subject: 2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530F9FF3.7030209@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> Message-ID: <530FA81F.8040309@oracle.com> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: > Dan, > > Thank you a lot for reviewing this! > > On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>> >> >> src/share/vm/runtime/vm_operations.hpp >> No comments. >> >> src/share/vm/prims/jvmtiEnvBase.hpp >> No comments. >> >> src/share/vm/prims/jvmtiEnv.cpp >> No comments. >> >> src/share/vm/prims/jvmtiEnvThreadState.cpp >> No comments. >> >> src/share/vm/prims/jvmtiEventController.cpp >> JvmtiEventController::set_frame_pop() is called by >> JvmtiEnvThreadState::set_frame_pop() which is called by >> JvmtiEnv::NotifyFramePop(). >> >> The "MutexLocker mu(JvmtiThreadState_lock)" in >> JvmtiEventController::set_frame_pop() protected the work >> done by JvmtiEventControllerPrivate::set_frame_pop(): >> >> ets->get_frame_pops()->set(fpop); >> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); > > Your check is the right thing to do, thanks! > I had to explain this more clearly in this 2-nd review request. > > The approach I've taken here is that all this code paths are executed > on the target thread or at a safepoint. > > It is true for all 3 functions: > set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). > > And the updated assert guards ensure that it is the case. > > It could be a good idea to add a No_Safepoint_Verifier for PopFrame() > and NotifyFramePop() > to make sure the current/target thread does not go to safepoint until > it is returned from > update_for_pop_top_frame() and set_frame_pop() correspondingly. > A No_Safepoint_Verifier can be also needed in the > JvmtiExport::post_method_exit(). > > These are all places where these functions are called: > prims/jvmtiEnv.cpp: > state->env_thread_state(this)->set_frame_pop(frame_number); // > JvmtiEnv::NotifyFramePop() > prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // > JvmtiExport::post_method_exit() > prims/jvmtiThreadState.cpp: > ets->clear_frame_pop(popframe_number); // > JvmtiThreadState::update_for_pop_top_frame() > > The function JvmtiEnvThreadState::clear_to_frame_pop() is never called > now. There is still a concern about recompute_thread_enabled(). If it is normally always protected with the JvmtiThreadState_lock then the approach above is not going to work. I'm trying to check this now. Thanks, Serguei > > Thanks, > Serguei > > > > > >> >> Since multiple threads can call JVM/TI NotifyFramePop() on the >> same target thread, what keeps the threads from messing with >> the list of frame pops simultaneously or messing with the >> thread enabled events bits in parallel? >> >> I suspect that this might also be an issue for >> JvmtiEventController::clear_frame_pop() and >> JvmtiEventController::clear_to_frame_pop() also. >> >> src/share/vm/prims/jvmtiThreadState.cpp >> No comments. >> >> Dan >> >> >>> >>> Summary: >>> >>> It is the 2-nd round of review because the JTREG com/sun/jdi tests >>> discovered a regression >>> in the first round change. The issue was in the >>> JvmtiEventController::clear_frame_pop() >>> lock synchronization that is not allowed at safepoints. >>> >>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM >>> operation for safety. >>> Also, I've removed the lock synchronization from the 3 impacted >>> JvmtiEventController:: >>> functions: set_frame_pop(), clear_frame_pop() and >>> clear_to_frame_pop(). >>> >>> Testing: >>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>> >>>> >>>> Summary: >>>> >>>> This is another Test Stabilization issue. >>>> The fix is very similar to other JVMTI stabilization fixes. >>>> It is to use safepoints for updating the PopFrame data instead of >>>> relying on the >>>> suspend equivalent condition mechanism >>>> (JvmtiEnv::is_thread_fully_suspended()) >>>> which is not adequate from the reliability point of view. >>>> >>>> Testing: >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Feb 27 14:00:18 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Feb 2014 14:00:18 -0800 Subject: 2-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530FA81F.8040309@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> Message-ID: <530FB572.4010507@oracle.com> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: > On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >> Dan, >> >> Thank you a lot for reviewing this! >> >> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>> >>> >>> src/share/vm/runtime/vm_operations.hpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEnvBase.hpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEnv.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEventController.cpp >>> JvmtiEventController::set_frame_pop() is called by >>> JvmtiEnvThreadState::set_frame_pop() which is called by >>> JvmtiEnv::NotifyFramePop(). >>> >>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>> JvmtiEventController::set_frame_pop() protected the work >>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>> >>> ets->get_frame_pops()->set(fpop); >>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >> >> Your check is the right thing to do, thanks! >> I had to explain this more clearly in this 2-nd review request. >> >> The approach I've taken here is that all this code paths are executed >> on the target thread or at a safepoint. >> >> It is true for all 3 functions: >> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >> >> And the updated assert guards ensure that it is the case. >> >> It could be a good idea to add a No_Safepoint_Verifier for PopFrame() >> and NotifyFramePop() >> to make sure the current/target thread does not go to safepoint until >> it is returned from >> update_for_pop_top_frame() and set_frame_pop() correspondingly. >> A No_Safepoint_Verifier can be also needed in the >> JvmtiExport::post_method_exit(). >> >> These are all places where these functions are called: >> prims/jvmtiEnv.cpp: >> state->env_thread_state(this)->set_frame_pop(frame_number); // >> JvmtiEnv::NotifyFramePop() >> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >> JvmtiExport::post_method_exit() >> prims/jvmtiThreadState.cpp: >> ets->clear_frame_pop(popframe_number); // >> JvmtiThreadState::update_for_pop_top_frame() >> >> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >> called now. > > There is still a concern about recompute_thread_enabled(). > If it is normally always protected with the JvmtiThreadState_lock > then the approach above is not going to work. > I'm trying to check this now. Dan, I came to a conclusion that these 3 functions still must be protected by the JvmtiThreadState_lock when they are called out of a safepoint. It is a little bit ugly but has to be safe though. Please, let me know if you see eny problems with that. I'll send a new webrev soon. Thanks, Serguei > > Thanks, > Serguei > > >> >> Thanks, >> Serguei >> >> >> >> >> >>> >>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>> same target thread, what keeps the threads from messing with >>> the list of frame pops simultaneously or messing with the >>> thread enabled events bits in parallel? >>> >>> I suspect that this might also be an issue for >>> JvmtiEventController::clear_frame_pop() and >>> JvmtiEventController::clear_to_frame_pop() also. >>> >>> src/share/vm/prims/jvmtiThreadState.cpp >>> No comments. >>> >>> Dan >>> >>> >>>> >>>> Summary: >>>> >>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>> tests discovered a regression >>>> in the first round change. The issue was in the >>>> JvmtiEventController::clear_frame_pop() >>>> lock synchronization that is not allowed at safepoints. >>>> >>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a VM >>>> operation for safety. >>>> Also, I've removed the lock synchronization from the 3 impacted >>>> JvmtiEventController:: >>>> functions: set_frame_pop(), clear_frame_pop() and >>>> clear_to_frame_pop(). >>>> >>>> Testing: >>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This is another Test Stabilization issue. >>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>> It is to use safepoints for updating the PopFrame data instead >>>>> of relying on the >>>>> suspend equivalent condition mechanism >>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>> which is not adequate from the reliability point of view. >>>>> >>>>> Testing: >>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Feb 27 14:14:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Feb 2014 08:14:22 +1000 Subject: JDK-8035944: Build failed wilth configure option --disable-debuginfo-files In-Reply-To: <420E14B8-608D-48AC-916F-F666BF1F4FEA@oracle.com> References: <530F323C.1090901@ysfactory.dip.jp> <530F3425.5060503@ysfactory.dip.jp> <530F392C.1000307@oracle.com> <530F3C78.4040400@ysfactory.dip.jp> <420E14B8-608D-48AC-916F-F666BF1F4FEA@oracle.com> Message-ID: <530FB8BE.8020907@oracle.com> I have closed the bug as "Not an issue". David On 28/02/2014 1:51 AM, Magnus Ihse Bursie wrote: > You are building hotspot using the experimental new build in build-infra. > > It is known not to work. > > Please use a proper forest instead, e.g jdk8/jdk8 for the JDK 8 master. > > /Magnus > > 27 feb 2014 kl. 14:24 skrev Yasumasa Suenaga : > >> Hi Erik, David, >> >> I used build-infra/jdk8 repository. >> And configure options is "--disable-zip-debug-info" . >> >> >> I tried to build jdk9/dev, it was succeeded with "--disable-zip-debug-info" . >> >> David says build-infra is still a work in progress. >> Should close this issue with "Won't Fix" ? Or should I post another mail list ? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 02/27/2014 10:10 PM, Erik Joelsson wrote: >>> Adding hotspot-dev as this is a hotspot fix >>> >>> /Erik >>> >>> On 2014-02-27 13:48, Yasumasa Suenaga wrote: >>>> Sorry, I forgot to upload webrev. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8035944/webrev.00/ >>>> >>>> Please review and sponsoring! >>>> >>>> >>>> Yasumasa >>>> >>>> On 02/27/2014 09:40 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I tried to build JDK8 with configure option: "--disable-debuginfo-files", however I got error >>>>> mesasges as following: >>>>> >>>>> ----------------- >>>>> ## Starting hotspot >>>>> Generating source files >>>>> Building adlc >>>>> Building libjvm.so >>>>> Building libjsig.so >>>>> Building libsaproc.so >>>>> gmake[2]: *** No rule to make target `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/libjvm/libjvm.diz', needed by `/usr/src/OpenJDK/jdk8/build/linux-x86_64-normal-server-release/hotspot/dist/jre/lib/amd64/server/libjvm.diz'. Stop. >>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>> Copying files to dist directory >>>>> gmake[1]: *** [dist-only] Error 2 >>>>> make: *** [hotspot-only] Error 2 >>>>> ----------------- >>>>> >>>>> I guess this error is caused by: >>>>> Various improvements. Add dist implementation. >>>>> http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/5dadd2bb22c0 >>>>> >>>>> If we give --disable-zip-debuginfo-files to configure, Makefile and related files should regard it. >>>>> >>>>> I've made patche which is attached in this email, it works fine. >>>>> >>>>> >>>>> I am just an Author. So I need a sponsor. >>>>> Could you help me? >>>>> >>>>> >>>>> Please cooperate. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >> From vladimir.kozlov at oracle.com Thu Feb 27 16:33:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Feb 2014 16:33:42 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) Message-ID: <530FD966.7030306@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8035983 http://cr.openjdk.java.net/~kvn/8035983/webrev/ We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. Thanks, Vladimir Output before the fix: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f After the fix: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] j Test$1.run()V+0 v ~StubRoutines::call_stub V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa V [libjvm.so+0x1b8f3c8] java_start+0x248 C [libc.so.1+0x122105] _thrp_setup+0xa5 C [libc.so.1+0x1223b0] _lwp_start+0x0 From christian.thalinger at oracle.com Thu Feb 27 17:38:24 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Feb 2014 17:38:24 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <530FD966.7030306@oracle.com> References: <530FD966.7030306@oracle.com> Message-ID: <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8035983 > http://cr.openjdk.java.net/~kvn/8035983/webrev/ > > We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). > Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. I have two questions: 1) Why does this work: + // Catch very first native frame by using stack address. + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; Because we set the stack base to the current value when we start the thread? 2) Why does this not work? I have seen many correct stack traces in the past. > > Thanks, > Vladimir > > Output before the fix: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 > V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 > V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a > V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 > V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a > V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a > V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f > > > After the fix: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 > V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 > V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a > V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 > V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a > V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a > V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f > J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] > J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] > j Test$1.run()V+0 > v ~StubRoutines::call_stub > V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 > V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 > V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a > V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 > V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 > V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 > V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e > V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa > V [libjvm.so+0x1b8f3c8] java_start+0x248 > C [libc.so.1+0x122105] _thrp_setup+0xa5 > C [libc.so.1+0x1223b0] _lwp_start+0x0 From vladimir.kozlov at oracle.com Thu Feb 27 18:08:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Feb 2014 18:08:36 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> Message-ID: <530FEFA4.1040105@oracle.com> On 2/27/14 5:38 PM, Christian Thalinger wrote: > > On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8035983 >> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >> >> We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). >> Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. > > I have two questions: > > 1) Why does this work: > > + // Catch very first native frame by using stack address. > + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; > > Because we set the stack base to the current value when we start the thread? You are right not all threads have stack base set (all VM's thread do). So I need to add check for stack_size() != 0 and use is_first_C_frame() if it is 0 (uninitialized). > > 2) Why does this not work? I have seen many correct stack traces in the past. Look on os::is_first_C_frame(). It does some stupid simple checks which nothing to do with real value. The test will pass if a java compiled code has a pointer in EBP register. Thanks, Vladimir > >> >> Thanks, >> Vladimir >> >> Output before the fix: >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >> >> >> After the fix: >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >> J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] >> j Test$1.run()V+0 >> v ~StubRoutines::call_stub >> V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >> V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >> V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >> V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >> V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >> V [libjvm.so+0x1b8f3c8] java_start+0x248 >> C [libc.so.1+0x122105] _thrp_setup+0xa5 >> C [libc.so.1+0x1223b0] _lwp_start+0x0 > From christian.thalinger at oracle.com Thu Feb 27 18:31:21 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Feb 2014 18:31:21 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <530FEFA4.1040105@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> Message-ID: <48C6875B-3BB8-4D47-A798-3610EFF33C73@oracle.com> On Feb 27, 2014, at 6:08 PM, Vladimir Kozlov wrote: > > > On 2/27/14 5:38 PM, Christian Thalinger wrote: >> >> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>> >>> We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). >>> Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. >> >> I have two questions: >> >> 1) Why does this work: >> >> + // Catch very first native frame by using stack address. >> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; >> >> Because we set the stack base to the current value when we start the thread? > > You are right not all threads have stack base set (all VM's thread do). So I need to add check for stack_size() != 0 and use is_first_C_frame() if it is 0 (uninitialized). Maybe add a comment why the on_local_stack() check works. > >> >> 2) Why does this not work? I have seen many correct stack traces in the past. > > Look on os::is_first_C_frame(). It does some stupid simple checks which nothing to do with real value. The test will pass if a java compiled code has a pointer in EBP register. Ah, that?s what I was missing. Makes sense then. Yeah, the code in os::is_first_C_frame() is weird :-) > > Thanks, > Vladimir > >> >>> >>> Thanks, >>> Vladimir >>> >>> Output before the fix: >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>> >>> >>> After the fix: >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>> J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] >>> j Test$1.run()V+0 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>> V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>> V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>> V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>> V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>> C [libc.so.1+0x1223b0] _lwp_start+0x0 From vladimir.kozlov at oracle.com Thu Feb 27 18:39:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Feb 2014 18:39:23 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <48C6875B-3BB8-4D47-A798-3610EFF33C73@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> <48C6875B-3BB8-4D47-A798-3610EFF33C73@oracle.com> Message-ID: <530FF6DB.50301@oracle.com> http://cr.openjdk.java.net/~kvn/8035983/webrev.01/ New check is used only for JavaThread where it is definitely initialized and where we have problem with call stack dump. thanks, Vladimir On 2/27/14 6:31 PM, Christian Thalinger wrote: > > On Feb 27, 2014, at 6:08 PM, Vladimir Kozlov wrote: > >> >> >> On 2/27/14 5:38 PM, Christian Thalinger wrote: >>> >>> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>>> >>>> We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). >>>> Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. >>> >>> I have two questions: >>> >>> 1) Why does this work: >>> >>> + // Catch very first native frame by using stack address. >>> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; >>> >>> Because we set the stack base to the current value when we start the thread? >> >> You are right not all threads have stack base set (all VM's thread do). So I need to add check for stack_size() != 0 and use is_first_C_frame() if it is 0 (uninitialized). > > Maybe add a comment why the on_local_stack() check works. > >> >>> >>> 2) Why does this not work? I have seen many correct stack traces in the past. >> >> Look on os::is_first_C_frame(). It does some stupid simple checks which nothing to do with real value. The test will pass if a java compiled code has a pointer in EBP register. > > Ah, that?s what I was missing. Makes sense then. Yeah, the code in os::is_first_C_frame() is weird :-) > >> >> Thanks, >> Vladimir >> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Output before the fix: >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>> >>>> >>>> After the fix: >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>> J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] >>>> j Test$1.run()V+0 >>>> v ~StubRoutines::call_stub >>>> V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>>> V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>>> V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>>> V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>>> V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>>> C [libc.so.1+0x1223b0] _lwp_start+0x0 > From serguei.spitsyn at oracle.com Thu Feb 27 19:50:18 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Feb 2014 19:50:18 -0800 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <530FB572.4010507@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> Message-ID: <5310077A.7010004@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 Summary: It is another attempt to fix the JTREG com/sun/jdi tests regression discovered in the first round change. The fix is to avoid lock synchronization at safepoints(jvmtiEventController.cpp). Thanks to Dan for catching the problem in the 2-nd round of review! Testing: All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi Thanks, Serguei On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: > On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, >>> >>> Thank you a lot for reviewing this! >>> >>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>> >>>> >>>> src/share/vm/runtime/vm_operations.hpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiEnv.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiEventController.cpp >>>> JvmtiEventController::set_frame_pop() is called by >>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>> JvmtiEnv::NotifyFramePop(). >>>> >>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>> JvmtiEventController::set_frame_pop() protected the work >>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>> >>>> ets->get_frame_pops()->set(fpop); >>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>> >>> Your check is the right thing to do, thanks! >>> I had to explain this more clearly in this 2-nd review request. >>> >>> The approach I've taken here is that all this code paths are executed >>> on the target thread or at a safepoint. >>> >>> It is true for all 3 functions: >>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>> >>> And the updated assert guards ensure that it is the case. >>> >>> It could be a good idea to add a No_Safepoint_Verifier for >>> PopFrame() and NotifyFramePop() >>> to make sure the current/target thread does not go to safepoint >>> until it is returned from >>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>> A No_Safepoint_Verifier can be also needed in the >>> JvmtiExport::post_method_exit(). >>> >>> These are all places where these functions are called: >>> prims/jvmtiEnv.cpp: >>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>> JvmtiEnv::NotifyFramePop() >>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>> JvmtiExport::post_method_exit() >>> prims/jvmtiThreadState.cpp: >>> ets->clear_frame_pop(popframe_number); // >>> JvmtiThreadState::update_for_pop_top_frame() >>> >>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>> called now. >> >> There is still a concern about recompute_thread_enabled(). >> If it is normally always protected with the JvmtiThreadState_lock >> then the approach above is not going to work. >> I'm trying to check this now. > > Dan, > > I came to a conclusion that these 3 functions still must be protected > by the JvmtiThreadState_lock when they are called out of a safepoint. > It is a little bit ugly but has to be safe though. > > Please, let me know if you see eny problems with that. > I'll send a new webrev soon. > > Thanks, > Serguei > > >> >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >>> >>>> >>>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>>> same target thread, what keeps the threads from messing with >>>> the list of frame pops simultaneously or messing with the >>>> thread enabled events bits in parallel? >>>> >>>> I suspect that this might also be an issue for >>>> JvmtiEventController::clear_frame_pop() and >>>> JvmtiEventController::clear_to_frame_pop() also. >>>> >>>> src/share/vm/prims/jvmtiThreadState.cpp >>>> No comments. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Summary: >>>>> >>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>> tests discovered a regression >>>>> in the first round change. The issue was in the >>>>> JvmtiEventController::clear_frame_pop() >>>>> lock synchronization that is not allowed at safepoints. >>>>> >>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>> VM operation for safety. >>>>> Also, I've removed the lock synchronization from the 3 impacted >>>>> JvmtiEventController:: >>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>> clear_to_frame_pop(). >>>>> >>>>> Testing: >>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This is another Test Stabilization issue. >>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>> It is to use safepoints for updating the PopFrame data instead >>>>>> of relying on the >>>>>> suspend equivalent condition mechanism >>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>> which is not adequate from the reliability point of view. >>>>>> >>>>>> Testing: >>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > From christian.thalinger at oracle.com Thu Feb 27 19:59:51 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 27 Feb 2014 19:59:51 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <530FF6DB.50301@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> <48C6875B-3BB8-4D47-A798-3610EFF33C73@oracle.com> <530FF6DB.50301@oracle.com> Message-ID: <2FBF907F-6AD8-4D8A-9266-01D7AD8C0EEB@oracle.com> On Feb 27, 2014, at 6:39 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8035983/webrev.01/ > > New check is used only for JavaThread where it is definitely initialized and where we have problem with call stack dump. Looks good. Just to be sure; +1 would also work here: + if (!_thread->on_local_stack((address)(fr.sp() + 4))) Right? > > thanks, > Vladimir > > On 2/27/14 6:31 PM, Christian Thalinger wrote: >> >> On Feb 27, 2014, at 6:08 PM, Vladimir Kozlov wrote: >> >>> >>> >>> On 2/27/14 5:38 PM, Christian Thalinger wrote: >>>> >>>> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>>>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>>>> >>>>> We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). >>>>> Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. >>>> >>>> I have two questions: >>>> >>>> 1) Why does this work: >>>> >>>> + // Catch very first native frame by using stack address. >>>> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; >>>> >>>> Because we set the stack base to the current value when we start the thread? >>> >>> You are right not all threads have stack base set (all VM's thread do). So I need to add check for stack_size() != 0 and use is_first_C_frame() if it is 0 (uninitialized). >> >> Maybe add a comment why the on_local_stack() check works. >> >>> >>>> >>>> 2) Why does this not work? I have seen many correct stack traces in the past. >>> >>> Look on os::is_first_C_frame(). It does some stupid simple checks which nothing to do with real value. The test will pass if a java compiled code has a pointer in EBP register. >> >> Ah, that?s what I was missing. Makes sense then. Yeah, the code in os::is_first_C_frame() is weird :-) >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Output before the fix: >>>>> >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>>> >>>>> >>>>> After the fix: >>>>> >>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>>> J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>>>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] >>>>> j Test$1.run()V+0 >>>>> v ~StubRoutines::call_stub >>>>> V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>>>> V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>>>> V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>>>> V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>>>> V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>>>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>>>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>>>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>>>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>>>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>>>> C [libc.so.1+0x1223b0] _lwp_start+0x0 >> From mike.duigou at oracle.com Thu Feb 27 21:24:17 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 27 Feb 2014 21:24:17 -0800 Subject: 8030350 breaks build with older gccs. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEA4CDC@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEA45E3@DEWDFEMB12A.global.corp.sap> <3D63CD24-EF6A-46CB-BF46-631A7F67EB0B@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEA4CDC@DEWDFEMB12A.global.corp.sap> Message-ID: <8E94A625-1A2F-47E4-A9A3-722E3E9EE2AB@oracle.com> My current plan is to add specific feature tests for the individual options and enable them as available. This make take a few days as I have other pending issues in progress. It is still up to the hotspot team whether to accept the code modifications which would eliminate the immediate need for these options. Except for the "-Wno-error=format-nonliteral" which would be allowed to revert to an error the other options would still be enabled to catch future introductions of similar bugs. Mike On Feb 26 2014, at 14:22 , Lindenmaier, Goetz wrote: > Hi, > > currently, the build with 4.8 issues a warning. The flag just avoids that the > warning is treated as error. > So I thought removing the warning is the best way - as this is anyways > the path currently followed, right? (Although the code looks better without > my change). > > But if you don't like the special case for older compilers (which I just reuse, > it's there anyways!), you can also switch off the warning for all compilers. > > By the way, 4.1.2 knows -Wno-error and -Wformat-nonliteral, but not the > combination. > > Best regards, > Goetz. > > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Wednesday, February 26, 2014 10:37 AM > To: Mike Duigou > Cc: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net > Subject: Re: 8030350 breaks build with older gccs. > > On Wed, Feb 26, 2014 at 7:29 AM, Mike Duigou wrote: >> Hello Goetz; >> >> The earliest version I considered was 4.2. It is unfortunate that these options aren't available on older gcc releases. I think we are going to have to add configure logic to enable them based upon the compiler version found. Whether the code should also be fixed I leave to the hotspot commiters, yourself included. >> >> David Holmes does bring a good point about the minimum reasonable or expected gcc version. Even if we do add conditional checks for these options it would,probably quickly get silly with every switch being checked. I picked 4.2 rather arbitrarily based on some other test I saw. I note that the 4.3.x line is almost 6 years old. By the time java 9 is released gcc 4.6 will be about 5 years old. I believe that is about as far back as it is reasonable to support. Requiring 4.6 today would probably be premature even though many are already using 4.8 and reporting 4.9. >> >> Unfortunately, I can't imagine that we could reasonably support both 3.3.3 and 4.9 and all versions in between on all platforms plus whatever comes in the next two years. We need to have a way to trim the set of supported compilers. Suggestions? >> > > I think we should look at the Linux distributions that we want to > support. For example gcc 3.3.3 was shipped with SLES 9 and gcc 4.1 > with SLES 10. It is part of our (i.e. SAP's) business that we support > older releases for a long time, that's why we're interested in keeping > the source base buildable with older releases as well. > > I don't think it is too complicated and I don't see any problem in > adding new compiler options based on the compiler version. This was > done before and it doesn't affect anybody who is using a newer > compiler (if you look at the make files you'll even find checks for > gcc 2). As long as we only speak of new warnings like in this case it > is trivial to enable them only if they are supported. > > That's why I think that Goetz's change > http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ which fixes > the makefiles to only use "-Wno-error=format-nonliteral" if available > is simple, effective and good. I'd only suggest to check for gcc >= > 4.2 (instead of 4.3) after you wrote that the option already appeared > in gcc 4.2. > > Regards, > Volker > >> Mike >> >> On Feb 25, 2014, at 3:42 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Mike, >>> >>> your change breaks the build with older gccs as they don?t know the option ?-Wno-error=format-nonliteral" >>> >>> I saw this with gcc 4.1.2 on linuxppc64 and linuxx86_64, and with gcc 3.3.3 on linuxx86_64. >>> Gcc 4.3.4 works. >>> >>> In the mail thread I saw that you opened some bugs to fix further warnings, maybe you detected >>> this issue already, or there is a bug to fix this? >>> >>> I would propose to fix this by either adapting hotspot code not to issue these warnings: >>> http://cr.openjdk.java.net/~goetz/webrevs/fix_hotspot/ >>> or to adapt the makefiles not to use the warning on older gccs: >>> http://cr.openjdk.java.net/~goetz/webrevs/fix_makefiles/ >>> >>> If you give me advice what you would prefer, I will open a bug and send >>> a RFR. >>> >>> Best regards, >>> Goetz. >>> >>> From david.holmes at oracle.com Thu Feb 27 22:04:50 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Feb 2014 16:04:50 +1000 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <5310077A.7010004@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> Message-ID: <53102702.4070603@oracle.com> Hi Serguei, On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-6471769 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 > > > Summary: > > It is another attempt to fix the JTREG com/sun/jdi tests regression > discovered in the first round change. > The fix is to avoid lock synchronization at > safepoints(jvmtiEventController.cpp). > Thanks to Dan for catching the problem in the 2-nd round of review! The basic approach here seems sound. I find the checking for cur->is_VMThread() somewhat overly conservative - if we are at a safepoint, and executing this code, then we must be the VMThread. But ok. You could also use MutexLockerEx to avoid the need for locked and unlocked paths to a common call, but that's just stylistic. Though if you are grabbing the current thread anyway you can also use the MutexLocker calls that take the thread arg - to avoid a second look-up of the current thread. David ----- > Testing: > All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi > > > Thanks, > Serguei > > > On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>> Dan, >>>> >>>> Thank you a lot for reviewing this! >>>> >>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>> >>>>> >>>>> src/share/vm/runtime/vm_operations.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>> JvmtiEventController::set_frame_pop() is called by >>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>> JvmtiEnv::NotifyFramePop(). >>>>> >>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>> JvmtiEventController::set_frame_pop() protected the work >>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>> >>>>> ets->get_frame_pops()->set(fpop); >>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>> >>>> Your check is the right thing to do, thanks! >>>> I had to explain this more clearly in this 2-nd review request. >>>> >>>> The approach I've taken here is that all this code paths are executed >>>> on the target thread or at a safepoint. >>>> >>>> It is true for all 3 functions: >>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>> >>>> And the updated assert guards ensure that it is the case. >>>> >>>> It could be a good idea to add a No_Safepoint_Verifier for >>>> PopFrame() and NotifyFramePop() >>>> to make sure the current/target thread does not go to safepoint >>>> until it is returned from >>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>> A No_Safepoint_Verifier can be also needed in the >>>> JvmtiExport::post_method_exit(). >>>> >>>> These are all places where these functions are called: >>>> prims/jvmtiEnv.cpp: >>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>> JvmtiEnv::NotifyFramePop() >>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>> JvmtiExport::post_method_exit() >>>> prims/jvmtiThreadState.cpp: >>>> ets->clear_frame_pop(popframe_number); // >>>> JvmtiThreadState::update_for_pop_top_frame() >>>> >>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>> called now. >>> >>> There is still a concern about recompute_thread_enabled(). >>> If it is normally always protected with the JvmtiThreadState_lock >>> then the approach above is not going to work. >>> I'm trying to check this now. >> >> Dan, >> >> I came to a conclusion that these 3 functions still must be protected >> by the JvmtiThreadState_lock when they are called out of a safepoint. >> It is a little bit ugly but has to be safe though. >> >> Please, let me know if you see eny problems with that. >> I'll send a new webrev soon. >> >> Thanks, >> Serguei >> >> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>>>> same target thread, what keeps the threads from messing with >>>>> the list of frame pops simultaneously or messing with the >>>>> thread enabled events bits in parallel? >>>>> >>>>> I suspect that this might also be an issue for >>>>> JvmtiEventController::clear_frame_pop() and >>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>> >>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>> No comments. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>> tests discovered a regression >>>>>> in the first round change. The issue was in the >>>>>> JvmtiEventController::clear_frame_pop() >>>>>> lock synchronization that is not allowed at safepoints. >>>>>> >>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>>> VM operation for safety. >>>>>> Also, I've removed the lock synchronization from the 3 impacted >>>>>> JvmtiEventController:: >>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>> clear_to_frame_pop(). >>>>>> >>>>>> Testing: >>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This is another Test Stabilization issue. >>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>> It is to use safepoints for updating the PopFrame data instead >>>>>>> of relying on the >>>>>>> suspend equivalent condition mechanism >>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>> which is not adequate from the reliability point of view. >>>>>>> >>>>>>> Testing: >>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Feb 27 23:05:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Feb 2014 17:05:46 +1000 Subject: hotspot.log overlapping log statements (JITWatch) In-Reply-To: <530EFE26.20303@oracle.com> References: <2e1e16b091c3de913bf9ab6e32bae7b2.squirrel@excalibur.xssl.net> <530C3E14.6030308@oracle.com> <3CBADBED-B62A-4808-B6A6-6B73DDD123EE@oracle.com> <4954aa79ced86c6fe602010585fd4c1b.squirrel@excalibur.xssl.net> <530D88D0.5030001@oracle.com> <530DDF9A.6000505@oracle.com> <6F01FEBF-CBE6-47C4-8DFA-5242DFF76B6B@oracle.com> <530EAAF4.20305@oracle.com> <530EFE26.20303@oracle.com> Message-ID: <5310354A.3000308@oracle.com> On 27/02/2014 6:58 PM, Dmitry Samersoff wrote: > David, > >> That's why I said per-thread buffering (not that I see a way to >> implement it). No-one blocks but *no thread starts to write >> a line until it has a full line to write*. > > if the single line is result of different events it can take a while to > get something printed. It's not always acceptable. Okay but I'm not really thinking of multiple events here, simply a single event written in multiple parts. Anyway John's solution seems the way to go. David > -Dmitry > > > On 2014-02-27 07:03, David Holmes wrote: >> On 27/02/2014 3:21 AM, John Rose wrote: >>> On Feb 26, 2014, at 4:35 AM, David Holmes >> > wrote: >>> >>>> I really didn't follow how you could untangle arbitrary non-delimited >>>> text, but I think it will still require changes to the use of the >>>> print functions to fix it - right? Logically what we want is >>>> per-thread buffering so that we only do a write() of a full line of >>>> text. >>> >>> The log is line-oriented, so switching threads in the middle of a line >>> requires that extra info. >> >> Line-oriented in that we always start a new line when we switch threads >> - ok. Hadn't realized that. >> >>> You could queue up threads until the writer has finished his line but >>> I'd rather not, given that lines might require internal computation. >> >> That's why I said per-thread buffering (not that I see a way to >> implement it). No-one blocks but no thread starts to write a line until >> it has a full line to write. >> >>> It's better (IMO) to push the work to decode/reassemble after the JVM >>> exits. >>> >>> Here's approximately what I had in mind: >>> >>> diff --git a/src/share/vm/utilities/ostream.cpp >>> b/src/share/vm/utilities/ostream.cpp >>> --- a/src/share/vm/utilities/ostream.cpp >>> +++ b/src/share/vm/utilities/ostream.cpp >>> @@ -961,7 +961,11 @@ >>> // got the lock >>> if (writer_id != _last_writer) { >>> if (has_log) { >>> - _log_file->bol(); >>> + int pos = _log_file->position(); >>> + if (pos > 0) { >>> + _log_file->bol(); >>> + _log_file->print_cr("", pos); >>> + } >>> // output a hint where this output is coming from: >>> _log_file->print_cr("", >>> writer_id); >>> } >> >> I see. >> >> David >> ----- >> >> >>> The "pos" bit is redundant, an extra clue about trailing spaces. >>> >>> ? John > > From yasu at ysfactory.dip.jp Fri Feb 28 01:18:10 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Fri, 28 Feb 2014 18:18:10 +0900 Subject: JDK-8036003: Add variable not to separate debug information. Message-ID: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> Hi all, Currently, configure script can accept --disable-debug-symbols and --disable-zip-debug-info as controlling to generate debug information. However, current makefiles cannot build ELF binaries which is contained debug information with "images" target. Some Linux distros use RPM as package manager. RPM is built by rpmbuild command, it strips symbols and debug information during to generate rpm packages. https://fedoraproject.org/wiki/Packaging:Debuginfo For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not contain debug information. Actual debug information is shipped by OpenJDK debuginfo package. This packaging is important when we have to debug JVM/JNI libraries. If we want to use debugging tools (GDB, SystemTap, etc...), they may requires debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is located at sub directory in /usr/lib/debug . It is defined in ELF section (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain valid debug information. We need to access libjvm.debuginfo.debug at same location. When we think to build OpenJDK rpm packages, we have to build ELF binaries which contain all debug information. we should not to separate debug information. Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not execute objcopy command for generating debuginfo binaries. If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments of make command. Or ELF binaries will be stripped. I've uploaded webrev for this enhancement. This is separated 3-part: top of forest, hotspot, jdk http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ Please review it and sponsoring! Thanks, Yasumasa P.S. I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like "--disable-separated-debug-info" . I ran configure which is located at jdk9/dev directory after I ran autoconf and common/autoconf/autogen.sh. However it failed. I guess this is caused by changeset as below. JDK-8035495: Improvements in autoconf integration http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 This changes add "CHECKME" option to configure script. However, this changes affects "configure" only. It should change "configure.ac" . From david.holmes at oracle.com Fri Feb 28 03:13:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Feb 2014 21:13:14 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> Message-ID: <53106F4A.8030905@oracle.com> Hi, As I put in the bug report this seems way too complicated. Seems to me all you need to do to get what you want is not use FDS and not strip the symbols from the binary. The former is trivial. The latter is more awkward as the strip policy stuff does not work as I would want it to work, but still doable. David On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: > Hi all, > > > Currently, configure script can accept --disable-debug-symbols and > --disable-zip-debug-info as controlling to generate debug information. > However, current makefiles cannot build ELF binaries which is contained > debug information with "images" target. > > Some Linux distros use RPM as package manager. > RPM is built by rpmbuild command, it strips symbols and debug information > during to generate rpm packages. > https://fedoraproject.org/wiki/Packaging:Debuginfo > > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not > contain debug information. Actual debug information is shipped by OpenJDK > debuginfo package. > This packaging is important when we have to debug JVM/JNI libraries. > If we want to use debugging tools (GDB, SystemTap, etc...), they may requires > debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is > located at sub directory in /usr/lib/debug . It is defined in ELF section > (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain > valid debug information. We need to access libjvm.debuginfo.debug at same location. > > > When we think to build OpenJDK rpm packages, we have to build ELF binaries > which contain all debug information. we should not to separate debug information. > > > Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . > If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not > execute objcopy command for generating debuginfo binaries. > > If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments > of make command. Or ELF binaries will be stripped. > > > I've uploaded webrev for this enhancement. > This is separated 3-part: top of forest, hotspot, jdk > http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ > > Please review it and sponsoring! > > > Thanks, > > Yasumasa > > > P.S. > I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like > "--disable-separated-debug-info" . > I ran configure which is located at jdk9/dev directory after I ran autoconf > and common/autoconf/autogen.sh. However it failed. > > I guess this is caused by changeset as below. > JDK-8035495: Improvements in autoconf integration > http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 > > This changes add "CHECKME" option to configure script. However, this changes > affects "configure" only. It should change "configure.ac" . > From daniel.daugherty at oracle.com Fri Feb 28 06:04:34 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 28 Feb 2014 07:04:34 -0700 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53106F4A.8030905@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> Message-ID: <53109772.9070808@oracle.com> The proper way to fix this is to disable FDS. We should not need yet another option to control debug info. Dan On 2/28/14 4:13 AM, David Holmes wrote: > Hi, > > As I put in the bug report this seems way too complicated. Seems to me > all you need to do to get what you want is not use FDS and not strip the > symbols from the binary. The former is trivial. The latter is more > awkward as the strip policy stuff does not work as I would want it to > work, but still doable. > > David > > On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> >> Currently, configure script can accept --disable-debug-symbols and >> --disable-zip-debug-info as controlling to generate debug information. >> However, current makefiles cannot build ELF binaries which is contained >> debug information with "images" target. >> >> Some Linux distros use RPM as package manager. >> RPM is built by rpmbuild command, it strips symbols and debug information >> during to generate rpm packages. >> https://fedoraproject.org/wiki/Packaging:Debuginfo >> >> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >> contain debug information. Actual debug information is shipped by OpenJDK >> debuginfo package. >> This packaging is important when we have to debug JVM/JNI libraries. >> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >> located at sub directory in /usr/lib/debug . It is defined in ELF section >> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >> valid debug information. We need to access libjvm.debuginfo.debug at same location. >> >> >> When we think to build OpenJDK rpm packages, we have to build ELF binaries >> which contain all debug information. we should not to separate debug information. >> >> >> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >> execute objcopy command for generating debuginfo binaries. >> >> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >> of make command. Or ELF binaries will be stripped. >> >> >> I've uploaded webrev for this enhancement. >> This is separated 3-part: top of forest, hotspot, jdk >> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >> >> Please review it and sponsoring! >> >> >> Thanks, >> >> Yasumasa >> >> >> P.S. >> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >> "--disable-separated-debug-info" . >> I ran configure which is located at jdk9/dev directory after I ran autoconf >> and common/autoconf/autogen.sh. However it failed. >> >> I guess this is caused by changeset as below. >> JDK-8035495: Improvements in autoconf integration >> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >> >> This changes add "CHECKME" option to configure script. However, this changes >> affects "configure" only. It should change "configure.ac" . >> From poonam.bajaj at oracle.com Fri Feb 28 06:08:00 2014 From: poonam.bajaj at oracle.com (poonam.bajaj at oracle.com) Date: Fri, 28 Feb 2014 14:08:00 +0000 Subject: hg: hsx/jdk7u/hotspot: 8035283: Second phase of branch shortening doesn't account for loop alignment Message-ID: <20140228140817.990BB62366@hg.openjdk.java.net> Changeset: 25bc6340b786 Author: poonam Date: 2014-02-28 02:45 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/25bc6340b786 8035283: Second phase of branch shortening doesn't account for loop alignment Summary: added missing check for loop padding case. Reviewed-by: kvn, jrose ! src/share/vm/opto/output.cpp From albert.noll at oracle.com Fri Feb 28 06:58:59 2014 From: albert.noll at oracle.com (Albert) Date: Fri, 28 Feb 2014 15:58:59 +0100 Subject: [9] RFR(S): 8035946: Use ResourceHashtable for dependency checking Message-ID: <5310A433.3000807@oracle.com> Hi, I send this to hotspot-dev, since the change contains a small modification in resourceHash.hpp Bug: https://bugs.openjdk.java.net/browse/JDK-8035946 Problem: JDK-8034839 introduced a new hashtable for caching checked dependencies. However, a hashtable that already existed prior to JDK-8034839 (ResourceHashtable) could have been used instead of introducing the new one. Solution: Use ResourceHashtable and remove the new hashtable that was introduced with JDK-8034839. Testing: jprt, failing test webrev: http://cr.openjdk.java.net/~anoll/8035946/webrev.00/ Many thanks in advance, Albert From yasu at ysfactory.dip.jp Fri Feb 28 07:38:24 2014 From: yasu at ysfactory.dip.jp (Yasumasa Suenaga) Date: Sat, 01 Mar 2014 00:38:24 +0900 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <53109772.9070808@oracle.com> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> Message-ID: <5310AD70.2070908@ysfactory.dip.jp> > The proper way to fix this is to disable FDS. Does this mean I have to pass --disable-debug-symbols to configure ? I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols to configure, gcc/g++ is not passed -g option. "-g" is needed to generate debuginfo. Thanks, Yasumasa On 2014/02/28 23:04, Daniel D. Daugherty wrote: > The proper way to fix this is to disable FDS. We should not need > yet another option to control debug info. > > Dan > > > On 2/28/14 4:13 AM, David Holmes wrote: >> Hi, >> >> As I put in the bug report this seems way too complicated. Seems to me >> all you need to do to get what you want is not use FDS and not strip the >> symbols from the binary. The former is trivial. The latter is more >> awkward as the strip policy stuff does not work as I would want it to >> work, but still doable. >> >> David >> >> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> >>> Currently, configure script can accept --disable-debug-symbols and >>> --disable-zip-debug-info as controlling to generate debug information. >>> However, current makefiles cannot build ELF binaries which is contained >>> debug information with "images" target. >>> >>> Some Linux distros use RPM as package manager. >>> RPM is built by rpmbuild command, it strips symbols and debug information >>> during to generate rpm packages. >>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>> >>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>> contain debug information. Actual debug information is shipped by OpenJDK >>> debuginfo package. >>> This packaging is important when we have to debug JVM/JNI libraries. >>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>> >>> >>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>> which contain all debug information. we should not to separate debug information. >>> >>> >>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>> execute objcopy command for generating debuginfo binaries. >>> >>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>> of make command. Or ELF binaries will be stripped. >>> >>> >>> I've uploaded webrev for this enhancement. >>> This is separated 3-part: top of forest, hotspot, jdk >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>> >>> Please review it and sponsoring! >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> P.S. >>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>> "--disable-separated-debug-info" . >>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>> and common/autoconf/autogen.sh. However it failed. >>> >>> I guess this is caused by changeset as below. >>> JDK-8035495: Improvements in autoconf integration >>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>> >>> This changes add "CHECKME" option to configure script. However, this changes >>> affects "configure" only. It should change "configure.ac" . >>> > From vladimir.kozlov at oracle.com Fri Feb 28 09:35:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Feb 2014 09:35:26 -0800 Subject: [9] RFR(S): 8035946: Use ResourceHashtable for dependency checking In-Reply-To: <5310A433.3000807@oracle.com> References: <5310A433.3000807@oracle.com> Message-ID: <5310C8DE.1050209@oracle.com> Albert, This looks good. Thank you for doing it. Can you fix indent of second line of DepTable typedef to start it under after opening "<"? Thanks, Vladimir On 2/28/14 6:58 AM, Albert wrote: > Hi, > > I send this to hotspot-dev, since the change contains a small modification in > resourceHash.hpp > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8035946 > > Problem: > JDK-8034839 introduced a new hashtable for caching checked dependencies. However, a hashtable that already existed prior > to JDK-8034839 (ResourceHashtable) could have been used instead of introducing the new one. > > Solution: > Use ResourceHashtable and remove the new hashtable that was introduced with JDK-8034839. > > Testing: > jprt, failing test > > webrev: > http://cr.openjdk.java.net/~anoll/8035946/webrev.00/ > > Many thanks in advance, > Albert From coleen.phillimore at oracle.com Fri Feb 28 11:11:56 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 14:11:56 -0500 Subject: [9] RFR(S): 8035946: Use ResourceHashtable for dependency checking In-Reply-To: <5310A433.3000807@oracle.com> References: <5310A433.3000807@oracle.com> Message-ID: <5310DF7C.7040309@oracle.com> Looks good! Thanks for doing this. Coleen On 2/28/14 9:58 AM, Albert wrote: > Hi, > > I send this to hotspot-dev, since the change contains a small > modification in > resourceHash.hpp > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8035946 > > Problem: > JDK-8034839 introduced a new hashtable for caching checked > dependencies. However, a hashtable that already existed prior to > JDK-8034839 (ResourceHashtable) could have been used instead of > introducing the new one. > > Solution: > Use ResourceHashtable and remove the new hashtable that was introduced > with JDK-8034839. > > Testing: > jprt, failing test > > webrev: > http://cr.openjdk.java.net/~anoll/8035946/webrev.00/ > > Many thanks in advance, > Albert From coleen.phillimore at oracle.com Fri Feb 28 11:14:39 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 14:14:39 -0500 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <530FEFA4.1040105@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> Message-ID: <5310E01F.2010406@oracle.com> I think this is fine but could we replace is_first_C_frame() uses with this expression that determines if the fp is not on the stack? Would that be a useful further cleanup? thanks, Coleen On 2/27/14 9:08 PM, Vladimir Kozlov wrote: > > > On 2/27/14 5:38 PM, Christian Thalinger wrote: >> >> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov >> wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>> >>> We don't print whole stack if native frames intermix with compiled >>> java frames (on x86 fp is used by compiled code). >>> Instead of using os::is_first_C_frame() which produces incorrect >>> result for compiled java frames I am suggesting to look on frame's >>> stack pointer relative to stack base. >> >> I have two questions: >> >> 1) Why does this work: >> >> + // Catch very first native frame by using stack address. >> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) >> break; >> >> Because we set the stack base to the current value when we start the >> thread? > > You are right not all threads have stack base set (all VM's thread > do). So I need to add check for stack_size() != 0 and use > is_first_C_frame() if it is 0 (uninitialized). > >> >> 2) Why does this not work? I have seen many correct stack traces in >> the past. > > Look on os::is_first_C_frame(). It does some stupid simple checks > which nothing to do with real value. The test will pass if a java > compiled code has a pointer in EBP register. > > Thanks, > Vladimir > >> >>> >>> Thanks, >>> Vladimir >>> >>> Output before the fix: >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const >>> char*,const char*)+0x9a >>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>> V [libjvm.so+0x1d41cda] void >>> ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>> V [libjvm.so+0x1d41fba] void >>> ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>> V [libjvm.so+0x1caa13f] void >>> SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>> >>> >>> After the fix: >>> >>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>> C=native code) >>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const >>> char*,const char*)+0x9a >>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>> V [libjvm.so+0x1d41cda] void >>> ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>> V [libjvm.so+0x1d41fba] void >>> ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>> V [libjvm.so+0x1caa13f] void >>> SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>> J 13 C2 >>> java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 >>> bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c >>> [0xffff80ffb97a1840+0x44c] >>> j Test$1.run()V+0 >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x177d196] void >>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>> V [libjvm.so+0x1b9a6c8] void >>> os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>> V [libjvm.so+0x177c90a] void >>> JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>> >>> V [libjvm.so+0x177be70] void >>> JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>> V [libjvm.so+0x177bf56] void >>> JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>> C [libc.so.1+0x1223b0] _lwp_start+0x0 >> From vladimir.kozlov at oracle.com Fri Feb 28 11:29:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Feb 2014 11:29:53 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <5310E01F.2010406@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> <5310E01F.2010406@oracle.com> Message-ID: <5310E3B1.7090006@oracle.com> Hi, Coleen On 2/28/14 11:14 AM, Coleen Phillimore wrote: > > I think this is fine but could we replace is_first_C_frame() uses with > this expression that determines if the fp is not on the stack? Would > that be a useful further cleanup? In my latest changes I use new check only for JavaThread which have stack values set: http://cr.openjdk.java.net/~kvn/8035983/webrev.01/ Thanks, Vladimir > thanks, > Coleen > > On 2/27/14 9:08 PM, Vladimir Kozlov wrote: >> >> >> On 2/27/14 5:38 PM, Christian Thalinger wrote: >>> >>> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov >>> wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>>> >>>> We don't print whole stack if native frames intermix with compiled >>>> java frames (on x86 fp is used by compiled code). >>>> Instead of using os::is_first_C_frame() which produces incorrect >>>> result for compiled java frames I am suggesting to look on frame's >>>> stack pointer relative to stack base. >>> >>> I have two questions: >>> >>> 1) Why does this work: >>> >>> + // Catch very first native frame by using stack address. >>> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) >>> break; >>> >>> Because we set the stack base to the current value when we start the >>> thread? >> >> You are right not all threads have stack base set (all VM's thread >> do). So I need to add check for stack_size() != 0 and use >> is_first_C_frame() if it is 0 (uninitialized). >> >>> >>> 2) Why does this not work? I have seen many correct stack traces in >>> the past. >> >> Look on os::is_first_C_frame(). It does some stupid simple checks >> which nothing to do with real value. The test will pass if a java >> compiled code has a pointer in EBP register. >> >> Thanks, >> Vladimir >> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Output before the fix: >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native code) >>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const >>>> char*,const char*)+0x9a >>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>> V [libjvm.so+0x1d41cda] void >>>> ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>> V [libjvm.so+0x1d41fba] void >>>> ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>> V [libjvm.so+0x1caa13f] void >>>> SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>> >>>> >>>> After the fix: >>>> >>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >>>> C=native code) >>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const >>>> char*,const char*)+0x9a >>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>> V [libjvm.so+0x1d41cda] void >>>> ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>> V [libjvm.so+0x1d41fba] void >>>> ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>> V [libjvm.so+0x1caa13f] void >>>> SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>> J 13 C2 >>>> java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 >>>> bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c >>>> [0xffff80ffb97a1840+0x44c] >>>> j Test$1.run()V+0 >>>> v ~StubRoutines::call_stub >>>> V [libjvm.so+0x177d196] void >>>> JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>>> >>>> V [libjvm.so+0x1b9a6c8] void >>>> os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>>> >>>> V [libjvm.so+0x177c90a] void >>>> JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>>> >>>> V [libjvm.so+0x177be70] void >>>> JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>>> >>>> V [libjvm.so+0x177bf56] void >>>> JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>>> >>>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>>> C [libc.so.1+0x1223b0] _lwp_start+0x0 >>> > From serguei.spitsyn at oracle.com Fri Feb 28 11:55:02 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Feb 2014 11:55:02 -0800 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <53102702.4070603@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> <53102702.4070603@oracle.com> Message-ID: <5310E996.9010800@oracle.com> On 2/27/14 10:04 PM, David Holmes wrote: > Hi Serguei, > > On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-6471769 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 >> >> >> >> Summary: >> >> It is another attempt to fix the JTREG com/sun/jdi tests regression >> discovered in the first round change. >> The fix is to avoid lock synchronization at >> safepoints(jvmtiEventController.cpp). >> Thanks to Dan for catching the problem in the 2-nd round of review! > > The basic approach here seems sound. Thank you for reviewing the fix! > > I find the checking for cur->is_VMThread() somewhat overly > conservative - if we are at a safepoint, and executing this code, then > we must be the VMThread. But ok. Agreed and simplified. Thanks! > > You could also use MutexLockerEx to avoid the need for locked and > unlocked paths to a common call, but that's just stylistic. Though if > you are grabbing the current thread anyway you can also use the > MutexLocker calls that take the thread arg - to avoid a second look-up > of the current thread. Thank you for reminding. I keep forgetting about it. Will check what is better here, just do not want to rerun the whole testing. But I'm in favor to make it simpler. :) Thanks, Serguei > > David > ----- > >> Testing: >> All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >> >> >> Thanks, >> Serguei >> >> >> On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>>> Dan, >>>>> >>>>> Thank you a lot for reviewing this! >>>>> >>>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>>> >>>>>>> >>>>>> >>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>> JvmtiEventController::set_frame_pop() is called by >>>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>>> JvmtiEnv::NotifyFramePop(). >>>>>> >>>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>>> JvmtiEventController::set_frame_pop() protected the work >>>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>>> >>>>>> ets->get_frame_pops()->set(fpop); >>>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>>> >>>>> Your check is the right thing to do, thanks! >>>>> I had to explain this more clearly in this 2-nd review request. >>>>> >>>>> The approach I've taken here is that all this code paths are executed >>>>> on the target thread or at a safepoint. >>>>> >>>>> It is true for all 3 functions: >>>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>>> >>>>> And the updated assert guards ensure that it is the case. >>>>> >>>>> It could be a good idea to add a No_Safepoint_Verifier for >>>>> PopFrame() and NotifyFramePop() >>>>> to make sure the current/target thread does not go to safepoint >>>>> until it is returned from >>>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>>> A No_Safepoint_Verifier can be also needed in the >>>>> JvmtiExport::post_method_exit(). >>>>> >>>>> These are all places where these functions are called: >>>>> prims/jvmtiEnv.cpp: >>>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>>> JvmtiEnv::NotifyFramePop() >>>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>>> JvmtiExport::post_method_exit() >>>>> prims/jvmtiThreadState.cpp: >>>>> ets->clear_frame_pop(popframe_number); // >>>>> JvmtiThreadState::update_for_pop_top_frame() >>>>> >>>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>>> called now. >>>> >>>> There is still a concern about recompute_thread_enabled(). >>>> If it is normally always protected with the JvmtiThreadState_lock >>>> then the approach above is not going to work. >>>> I'm trying to check this now. >>> >>> Dan, >>> >>> I came to a conclusion that these 3 functions still must be protected >>> by the JvmtiThreadState_lock when they are called out of a safepoint. >>> It is a little bit ugly but has to be safe though. >>> >>> Please, let me know if you see eny problems with that. >>> I'll send a new webrev soon. >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>>>>> same target thread, what keeps the threads from messing with >>>>>> the list of frame pops simultaneously or messing with the >>>>>> thread enabled events bits in parallel? >>>>>> >>>>>> I suspect that this might also be an issue for >>>>>> JvmtiEventController::clear_frame_pop() and >>>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>>> >>>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>>> No comments. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>>> tests discovered a regression >>>>>>> in the first round change. The issue was in the >>>>>>> JvmtiEventController::clear_frame_pop() >>>>>>> lock synchronization that is not allowed at safepoints. >>>>>>> >>>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>>>> VM operation for safety. >>>>>>> Also, I've removed the lock synchronization from the 3 impacted >>>>>>> JvmtiEventController:: >>>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>>> clear_to_frame_pop(). >>>>>>> >>>>>>> Testing: >>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> This is another Test Stabilization issue. >>>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>>> It is to use safepoints for updating the PopFrame data instead >>>>>>>> of relying on the >>>>>>>> suspend equivalent condition mechanism >>>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>>> which is not adequate from the reliability point of view. >>>>>>>> >>>>>>>> Testing: >>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Fri Feb 28 12:08:53 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 15:08:53 -0500 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases Message-ID: <5310ECD5.8000807@oracle.com> Summary: Call is_metadata instead which does less work for the call in debugInfo.hpp which is called for all compiled code stack frames. open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ bug link https://bugs.openjdk.java.net/browse/JDK-8035735 Tested with failing test case, nsk.quick.testlist, jcks and jtreg tests. Coleen From ylt at letallec.org Fri Feb 28 12:27:40 2014 From: ylt at letallec.org (Yann Le Tallec) Date: Fri, 28 Feb 2014 20:27:40 +0000 Subject: Re.: CHA ignores default methods during analysis leading to incorrect code generation Message-ID: Original message: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-January/012252.html The test (DefaultAndConcreteMethodsCHA.java) passes as expected on b129. However a post on Stackoverflow reports a very similar bug that can still be reproduced on b129: http://stackoverflow.com/q/22096052/829571 Code copied below for reference - I get the erroneous output for i ~ 260, i.e. after approximately 25 seconds. Yann public class IsolatedBug { static int i = 0; private final Box box; private final List drawables; public IsolatedBug() { this.box = new Box(); this.drawables = new ArrayList<>(); drawables.add(box); drawables.forEach(drawable -> System.out.println(++i + " " + drawable + " C=" + drawable.isShadowCaster() + "/R=" + drawable.isShadowReceiver())); } private void init() throws InterruptedException { while (true) { drawables.forEach(drawable -> System.out.println(++i + " " + drawable + " C=" + drawable.isShadowCaster() + "/R=" + drawable.isShadowReceiver())); Thread.sleep(100); } } public static void main(String[] args) throws InterruptedException { new IsolatedBug().init(); } } abstract class Drawable implements DrawableInterface {} interface DrawableInterface { default public boolean isShadowReceiver() { return false; } default public boolean isShadowCaster() { return false; } } interface ShadowDrawable extends DrawableInterface { @Override default public boolean isShadowReceiver() { return true; } @Override default public boolean isShadowCaster() { return true; } } class Box extends Drawable implements ShadowDrawable {} From daniel.daugherty at oracle.com Fri Feb 28 13:12:57 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 28 Feb 2014 14:12:57 -0700 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <5310E996.9010800@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> <53102702.4070603@oracle.com> <5310E996.9010800@oracle.com> Message-ID: <5310FBD9.5090607@oracle.com> On 2/28/14 12:55 PM, serguei.spitsyn at oracle.com wrote: > On 2/27/14 10:04 PM, David Holmes wrote: >> Hi Serguei, >> >> On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 >>> Thumbs up! (including the tweaks in the .4 version) src/share/vm/runtime/vm_operations.hpp No comments. src/share/vm/prims/jvmtiEnvBase.hpp line 375: bool allow_nested_vm_operations() const { return true; } Does VM_SetFramePop really gave to permit nested VMops? src/share/vm/prims/jvmtiEnv.cpp No comments. src/share/vm/prims/jvmtiEnvThreadState.cpp No comments. src/share/vm/prims/jvmtiEventController.cpp No comments. src/share/vm/prims/jvmtiThreadState.cpp No comments. Dan >>> >>> >>> Summary: >>> >>> It is another attempt to fix the JTREG com/sun/jdi tests regression >>> discovered in the first round change. >>> The fix is to avoid lock synchronization at >>> safepoints(jvmtiEventController.cpp). >>> Thanks to Dan for catching the problem in the 2-nd round of review! >> >> The basic approach here seems sound. > > Thank you for reviewing the fix! > >> >> I find the checking for cur->is_VMThread() somewhat overly >> conservative - if we are at a safepoint, and executing this code, >> then we must be the VMThread. But ok. > > Agreed and simplified. Thanks! > >> >> You could also use MutexLockerEx to avoid the need for locked and >> unlocked paths to a common call, but that's just stylistic. Though if >> you are grabbing the current thread anyway you can also use the >> MutexLocker calls that take the thread arg - to avoid a second >> look-up of the current thread. > > Thank you for reminding. I keep forgetting about it. > Will check what is better here, just do not want to rerun the whole > testing. > But I'm in favor to make it simpler. :) > > Thanks, > Serguei > >> >> David >> ----- >> >>> Testing: >>> All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg >>> com/sun/jdi >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Dan, >>>>>> >>>>>> Thank you a lot for reviewing this! >>>>>> >>>>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>>>> No comments. >>>>>>> >>>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>>> JvmtiEventController::set_frame_pop() is called by >>>>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>>>> JvmtiEnv::NotifyFramePop(). >>>>>>> >>>>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>>>> JvmtiEventController::set_frame_pop() protected the work >>>>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>>>> >>>>>>> ets->get_frame_pops()->set(fpop); >>>>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>>>> >>>>>> Your check is the right thing to do, thanks! >>>>>> I had to explain this more clearly in this 2-nd review request. >>>>>> >>>>>> The approach I've taken here is that all this code paths are >>>>>> executed >>>>>> on the target thread or at a safepoint. >>>>>> >>>>>> It is true for all 3 functions: >>>>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>>>> >>>>>> And the updated assert guards ensure that it is the case. >>>>>> >>>>>> It could be a good idea to add a No_Safepoint_Verifier for >>>>>> PopFrame() and NotifyFramePop() >>>>>> to make sure the current/target thread does not go to safepoint >>>>>> until it is returned from >>>>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>>>> A No_Safepoint_Verifier can be also needed in the >>>>>> JvmtiExport::post_method_exit(). >>>>>> >>>>>> These are all places where these functions are called: >>>>>> prims/jvmtiEnv.cpp: >>>>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>>>> JvmtiEnv::NotifyFramePop() >>>>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>>>> JvmtiExport::post_method_exit() >>>>>> prims/jvmtiThreadState.cpp: >>>>>> ets->clear_frame_pop(popframe_number); // >>>>>> JvmtiThreadState::update_for_pop_top_frame() >>>>>> >>>>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>>>> called now. >>>>> >>>>> There is still a concern about recompute_thread_enabled(). >>>>> If it is normally always protected with the JvmtiThreadState_lock >>>>> then the approach above is not going to work. >>>>> I'm trying to check this now. >>>> >>>> Dan, >>>> >>>> I came to a conclusion that these 3 functions still must be protected >>>> by the JvmtiThreadState_lock when they are called out of a safepoint. >>>> It is a little bit ugly but has to be safe though. >>>> >>>> Please, let me know if you see eny problems with that. >>>> I'll send a new webrev soon. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>>>>>> same target thread, what keeps the threads from messing with >>>>>>> the list of frame pops simultaneously or messing with the >>>>>>> thread enabled events bits in parallel? >>>>>>> >>>>>>> I suspect that this might also be an issue for >>>>>>> JvmtiEventController::clear_frame_pop() and >>>>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>>>> >>>>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>>>> No comments. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>>>> tests discovered a regression >>>>>>>> in the first round change. The issue was in the >>>>>>>> JvmtiEventController::clear_frame_pop() >>>>>>>> lock synchronization that is not allowed at safepoints. >>>>>>>> >>>>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>>>>> VM operation for safety. >>>>>>>> Also, I've removed the lock synchronization from the 3 impacted >>>>>>>> JvmtiEventController:: >>>>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>>>> clear_to_frame_pop(). >>>>>>>> >>>>>>>> Testing: >>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> This is another Test Stabilization issue. >>>>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>>>> It is to use safepoints for updating the PopFrame data instead >>>>>>>>> of relying on the >>>>>>>>> suspend equivalent condition mechanism >>>>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>>>> which is not adequate from the reliability point of view. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Fri Feb 28 13:24:47 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Feb 2014 13:24:47 -0800 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <5310FBD9.5090607@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> <53102702.4070603@oracle.com> <5310E996.9010800@oracle.com> <5310FBD9.5090607@oracle.com> Message-ID: <5310FE9F.1060606@oracle.com> On 2/28/14 1:12 PM, Daniel D. Daugherty wrote: > On 2/28/14 12:55 PM, serguei.spitsyn at oracle.com wrote: >> On 2/27/14 10:04 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 >>>> > > Thumbs up! (including the tweaks in the .4 version) Thanks a lot, Dan! > > src/share/vm/runtime/vm_operations.hpp > No comments. > > src/share/vm/prims/jvmtiEnvBase.hpp > line 375: bool allow_nested_vm_operations() const { return > true; } > Does VM_SetFramePop really gave to permit nested VMops? Yes. It was a real surprise that it is really necessary. Thanks! Serguei > > src/share/vm/prims/jvmtiEnv.cpp > No comments. > > src/share/vm/prims/jvmtiEnvThreadState.cpp > No comments. > > src/share/vm/prims/jvmtiEventController.cpp > No comments. > > src/share/vm/prims/jvmtiThreadState.cpp > No comments. > > Dan > > > >>>> >>>> >>>> Summary: >>>> >>>> It is another attempt to fix the JTREG com/sun/jdi tests regression >>>> discovered in the first round change. >>>> The fix is to avoid lock synchronization at >>>> safepoints(jvmtiEventController.cpp). >>>> Thanks to Dan for catching the problem in the 2-nd round of review! >>> >>> The basic approach here seems sound. >> >> Thank you for reviewing the fix! >> >>> >>> I find the checking for cur->is_VMThread() somewhat overly >>> conservative - if we are at a safepoint, and executing this code, >>> then we must be the VMThread. But ok. >> >> Agreed and simplified. Thanks! >> >>> >>> You could also use MutexLockerEx to avoid the need for locked and >>> unlocked paths to a common call, but that's just stylistic. Though >>> if you are grabbing the current thread anyway you can also use the >>> MutexLocker calls that take the thread arg - to avoid a second >>> look-up of the current thread. >> >> Thank you for reminding. I keep forgetting about it. >> Will check what is better here, just do not want to rerun the whole >> testing. >> But I'm in favor to make it simpler. :) >> >> Thanks, >> Serguei >> >>> >>> David >>> ----- >>> >>>> Testing: >>>> All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg >>>> com/sun/jdi >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Dan, >>>>>>> >>>>>>> Thank you a lot for reviewing this! >>>>>>> >>>>>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>>>> JvmtiEventController::set_frame_pop() is called by >>>>>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>>>>> JvmtiEnv::NotifyFramePop(). >>>>>>>> >>>>>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>>>>> JvmtiEventController::set_frame_pop() protected the work >>>>>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>>>>> >>>>>>>> ets->get_frame_pops()->set(fpop); >>>>>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>>>>> >>>>>>> Your check is the right thing to do, thanks! >>>>>>> I had to explain this more clearly in this 2-nd review request. >>>>>>> >>>>>>> The approach I've taken here is that all this code paths are >>>>>>> executed >>>>>>> on the target thread or at a safepoint. >>>>>>> >>>>>>> It is true for all 3 functions: >>>>>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>>>>> >>>>>>> And the updated assert guards ensure that it is the case. >>>>>>> >>>>>>> It could be a good idea to add a No_Safepoint_Verifier for >>>>>>> PopFrame() and NotifyFramePop() >>>>>>> to make sure the current/target thread does not go to safepoint >>>>>>> until it is returned from >>>>>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>>>>> A No_Safepoint_Verifier can be also needed in the >>>>>>> JvmtiExport::post_method_exit(). >>>>>>> >>>>>>> These are all places where these functions are called: >>>>>>> prims/jvmtiEnv.cpp: >>>>>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>>>>> JvmtiEnv::NotifyFramePop() >>>>>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>>>>> JvmtiExport::post_method_exit() >>>>>>> prims/jvmtiThreadState.cpp: >>>>>>> ets->clear_frame_pop(popframe_number); // >>>>>>> JvmtiThreadState::update_for_pop_top_frame() >>>>>>> >>>>>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>>>>> called now. >>>>>> >>>>>> There is still a concern about recompute_thread_enabled(). >>>>>> If it is normally always protected with the JvmtiThreadState_lock >>>>>> then the approach above is not going to work. >>>>>> I'm trying to check this now. >>>>> >>>>> Dan, >>>>> >>>>> I came to a conclusion that these 3 functions still must be protected >>>>> by the JvmtiThreadState_lock when they are called out of a safepoint. >>>>> It is a little bit ugly but has to be safe though. >>>>> >>>>> Please, let me know if you see eny problems with that. >>>>> I'll send a new webrev soon. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Since multiple threads can call JVM/TI NotifyFramePop() on the >>>>>>>> same target thread, what keeps the threads from messing with >>>>>>>> the list of frame pops simultaneously or messing with the >>>>>>>> thread enabled events bits in parallel? >>>>>>>> >>>>>>>> I suspect that this might also be an issue for >>>>>>>> JvmtiEventController::clear_frame_pop() and >>>>>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>>>>> No comments. >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>>>>> tests discovered a regression >>>>>>>>> in the first round change. The issue was in the >>>>>>>>> JvmtiEventController::clear_frame_pop() >>>>>>>>> lock synchronization that is not allowed at safepoints. >>>>>>>>> >>>>>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>>>>>> VM operation for safety. >>>>>>>>> Also, I've removed the lock synchronization from the 3 impacted >>>>>>>>> JvmtiEventController:: >>>>>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>>>>> clear_to_frame_pop(). >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> This is another Test Stabilization issue. >>>>>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>>>>> It is to use safepoints for updating the PopFrame data instead >>>>>>>>>> of relying on the >>>>>>>>>> suspend equivalent condition mechanism >>>>>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>>>>> which is not adequate from the reliability point of view. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From daniel.daugherty at oracle.com Fri Feb 28 13:26:43 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 28 Feb 2014 14:26:43 -0700 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <5310FE9F.1060606@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> <53102702.4070603@oracle.com> <5310E996.9010800@oracle.com> <5310FBD9.5090607@oracle.com> <5310FE9F.1060606@oracle.com> Message-ID: <5310FF13.8050204@oracle.com> On 2/28/14 2:24 PM, serguei.spitsyn at oracle.com wrote: > On 2/28/14 1:12 PM, Daniel D. Daugherty wrote: >> On 2/28/14 12:55 PM, serguei.spitsyn at oracle.com wrote: >>> On 2/27/14 10:04 PM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 >>>>> >> >> Thumbs up! (including the tweaks in the .4 version) > > Thanks a lot, Dan! > >> >> src/share/vm/runtime/vm_operations.hpp >> No comments. >> >> src/share/vm/prims/jvmtiEnvBase.hpp >> line 375: bool allow_nested_vm_operations() const { return >> true; } >> Does VM_SetFramePop really gave to permit nested VMops? > > Yes. > It was a real surprise that it is really necessary. Maybe add a one line comment saying something like: // needs to permit nested because this VMop can be invoked from XXX VMop... or something like that. Dan > > Thanks! > Serguei > >> >> src/share/vm/prims/jvmtiEnv.cpp >> No comments. >> >> src/share/vm/prims/jvmtiEnvThreadState.cpp >> No comments. >> >> src/share/vm/prims/jvmtiEventController.cpp >> No comments. >> >> src/share/vm/prims/jvmtiThreadState.cpp >> No comments. >> >> Dan >> >> >> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> It is another attempt to fix the JTREG com/sun/jdi tests >>>>> regression >>>>> discovered in the first round change. >>>>> The fix is to avoid lock synchronization at >>>>> safepoints(jvmtiEventController.cpp). >>>>> Thanks to Dan for catching the problem in the 2-nd round of >>>>> review! >>>> >>>> The basic approach here seems sound. >>> >>> Thank you for reviewing the fix! >>> >>>> >>>> I find the checking for cur->is_VMThread() somewhat overly >>>> conservative - if we are at a safepoint, and executing this code, >>>> then we must be the VMThread. But ok. >>> >>> Agreed and simplified. Thanks! >>> >>>> >>>> You could also use MutexLockerEx to avoid the need for locked and >>>> unlocked paths to a common call, but that's just stylistic. Though >>>> if you are grabbing the current thread anyway you can also use the >>>> MutexLocker calls that take the thread arg - to avoid a second >>>> look-up of the current thread. >>> >>> Thank you for reminding. I keep forgetting about it. >>> Will check what is better here, just do not want to rerun the whole >>> testing. >>> But I'm in favor to make it simpler. :) >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ----- >>>> >>>>> Testing: >>>>> All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg >>>>> com/sun/jdi >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Dan, >>>>>>>> >>>>>>>> Thank you a lot for reviewing this! >>>>>>>> >>>>>>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>>>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>>>>> JvmtiEventController::set_frame_pop() is called by >>>>>>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>>>>>> JvmtiEnv::NotifyFramePop(). >>>>>>>>> >>>>>>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>>>>>> JvmtiEventController::set_frame_pop() protected the work >>>>>>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>>>>>> >>>>>>>>> ets->get_frame_pops()->set(fpop); >>>>>>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>>>>>>> >>>>>>>> >>>>>>>> Your check is the right thing to do, thanks! >>>>>>>> I had to explain this more clearly in this 2-nd review request. >>>>>>>> >>>>>>>> The approach I've taken here is that all this code paths are >>>>>>>> executed >>>>>>>> on the target thread or at a safepoint. >>>>>>>> >>>>>>>> It is true for all 3 functions: >>>>>>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>>>>>> >>>>>>>> And the updated assert guards ensure that it is the case. >>>>>>>> >>>>>>>> It could be a good idea to add a No_Safepoint_Verifier for >>>>>>>> PopFrame() and NotifyFramePop() >>>>>>>> to make sure the current/target thread does not go to safepoint >>>>>>>> until it is returned from >>>>>>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>>>>>> A No_Safepoint_Verifier can be also needed in the >>>>>>>> JvmtiExport::post_method_exit(). >>>>>>>> >>>>>>>> These are all places where these functions are called: >>>>>>>> prims/jvmtiEnv.cpp: >>>>>>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>>>>>> JvmtiEnv::NotifyFramePop() >>>>>>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>>>>>> JvmtiExport::post_method_exit() >>>>>>>> prims/jvmtiThreadState.cpp: >>>>>>>> ets->clear_frame_pop(popframe_number); // >>>>>>>> JvmtiThreadState::update_for_pop_top_frame() >>>>>>>> >>>>>>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>>>>>> called now. >>>>>>> >>>>>>> There is still a concern about recompute_thread_enabled(). >>>>>>> If it is normally always protected with the JvmtiThreadState_lock >>>>>>> then the approach above is not going to work. >>>>>>> I'm trying to check this now. >>>>>> >>>>>> Dan, >>>>>> >>>>>> I came to a conclusion that these 3 functions still must be >>>>>> protected >>>>>> by the JvmtiThreadState_lock when they are called out of a >>>>>> safepoint. >>>>>> It is a little bit ugly but has to be safe though. >>>>>> >>>>>> Please, let me know if you see eny problems with that. >>>>>> I'll send a new webrev soon. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Since multiple threads can call JVM/TI NotifyFramePop() on >>>>>>>>> the >>>>>>>>> same target thread, what keeps the threads from messing with >>>>>>>>> the list of frame pops simultaneously or messing with the >>>>>>>>> thread enabled events bits in parallel? >>>>>>>>> >>>>>>>>> I suspect that this might also be an issue for >>>>>>>>> JvmtiEventController::clear_frame_pop() and >>>>>>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>>>>>> No comments. >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>>>>>> tests discovered a regression >>>>>>>>>> in the first round change. The issue was in the >>>>>>>>>> JvmtiEventController::clear_frame_pop() >>>>>>>>>> lock synchronization that is not allowed at safepoints. >>>>>>>>>> >>>>>>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to use a >>>>>>>>>> VM operation for safety. >>>>>>>>>> Also, I've removed the lock synchronization from the 3 >>>>>>>>>> impacted >>>>>>>>>> JvmtiEventController:: >>>>>>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>>>>>> clear_to_frame_pop(). >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the fix for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Open webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> This is another Test Stabilization issue. >>>>>>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>>>>>> It is to use safepoints for updating the PopFrame data >>>>>>>>>>> instead >>>>>>>>>>> of relying on the >>>>>>>>>>> suspend equivalent condition mechanism >>>>>>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>>>>>> which is not adequate from the reliability point of view. >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Fri Feb 28 13:33:46 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Feb 2014 13:33:46 -0800 Subject: 3-nd round RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync") In-Reply-To: <5310FF13.8050204@oracle.com> References: <530D007D.4040602@oracle.com> <530EF65C.5040707@oracle.com> <530F8D52.2040400@oracle.com> <530F9FF3.7030209@oracle.com> <530FA81F.8040309@oracle.com> <530FB572.4010507@oracle.com> <5310077A.7010004@oracle.com> <53102702.4070603@oracle.com> <5310E996.9010800@oracle.com> <5310FBD9.5090607@oracle.com> <5310FE9F.1060606@oracle.com> <5310FF13.8050204@oracle.com> Message-ID: <531100BA.1020303@oracle.com> On 2/28/14 1:26 PM, Daniel D. Daugherty wrote: > On 2/28/14 2:24 PM, serguei.spitsyn at oracle.com wrote: >> On 2/28/14 1:12 PM, Daniel D. Daugherty wrote: >>> On 2/28/14 12:55 PM, serguei.spitsyn at oracle.com wrote: >>>> On 2/27/14 10:04 PM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 28/02/2014 1:50 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.3 >>>>>> >>> >>> Thumbs up! (including the tweaks in the .4 version) >> >> Thanks a lot, Dan! >> >>> >>> src/share/vm/runtime/vm_operations.hpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEnvBase.hpp >>> line 375: bool allow_nested_vm_operations() const { >>> return true; } >>> Does VM_SetFramePop really gave to permit nested VMops? >> >> Yes. >> It was a real surprise that it is really necessary. > > Maybe add a one line comment saying something like: > > // needs to permit nested because this VMop can be invoked from XXX > VMop... > > or something like that. Ok, I'll add a comment before the push. The latest public webrev with the simplification fixes suggested by David (no above comment yet): http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.4/ Thanks, Serguei > > Dan > > >> >> Thanks! >> Serguei >> >>> >>> src/share/vm/prims/jvmtiEnv.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiEventController.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiThreadState.cpp >>> No comments. >>> >>> Dan >>> >>> >>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> It is another attempt to fix the JTREG com/sun/jdi tests >>>>>> regression >>>>>> discovered in the first round change. >>>>>> The fix is to avoid lock synchronization at >>>>>> safepoints(jvmtiEventController.cpp). >>>>>> Thanks to Dan for catching the problem in the 2-nd round of >>>>>> review! >>>>> >>>>> The basic approach here seems sound. >>>> >>>> Thank you for reviewing the fix! >>>> >>>>> >>>>> I find the checking for cur->is_VMThread() somewhat overly >>>>> conservative - if we are at a safepoint, and executing this code, >>>>> then we must be the VMThread. But ok. >>>> >>>> Agreed and simplified. Thanks! >>>> >>>>> >>>>> You could also use MutexLockerEx to avoid the need for locked and >>>>> unlocked paths to a common call, but that's just stylistic. Though >>>>> if you are grabbing the current thread anyway you can also use the >>>>> MutexLocker calls that take the thread arg - to avoid a second >>>>> look-up of the current thread. >>>> >>>> Thank you for reminding. I keep forgetting about it. >>>> Will check what is better here, just do not want to rerun the whole >>>> testing. >>>> But I'm in favor to make it simpler. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Testing: >>>>>> All tests are passed: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg >>>>>> com/sun/jdi >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 2/27/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> On 2/27/14 1:03 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 2/27/14 12:28 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Dan, >>>>>>>>> >>>>>>>>> Thank you a lot for reviewing this! >>>>>>>>> >>>>>>>>> On 2/27/14 11:09 AM, Daniel D. Daugherty wrote: >>>>>>>>>> On 2/27/14 1:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the fix for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Open webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.2 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/vm_operations.hpp >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiEnvBase.hpp >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiEnv.cpp >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiEnvThreadState.cpp >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiEventController.cpp >>>>>>>>>> JvmtiEventController::set_frame_pop() is called by >>>>>>>>>> JvmtiEnvThreadState::set_frame_pop() which is called by >>>>>>>>>> JvmtiEnv::NotifyFramePop(). >>>>>>>>>> >>>>>>>>>> The "MutexLocker mu(JvmtiThreadState_lock)" in >>>>>>>>>> JvmtiEventController::set_frame_pop() protected the work >>>>>>>>>> done by JvmtiEventControllerPrivate::set_frame_pop(): >>>>>>>>>> >>>>>>>>>> ets->get_frame_pops()->set(fpop); >>>>>>>>>> recompute_thread_enabled(ets->get_thread()->jvmti_thread_state()); >>>>>>>>>> >>>>>>>>> >>>>>>>>> Your check is the right thing to do, thanks! >>>>>>>>> I had to explain this more clearly in this 2-nd review request. >>>>>>>>> >>>>>>>>> The approach I've taken here is that all this code paths are >>>>>>>>> executed >>>>>>>>> on the target thread or at a safepoint. >>>>>>>>> >>>>>>>>> It is true for all 3 functions: >>>>>>>>> set_frame_pop(), clear_frame_pop() and clear_to_frame_pop(). >>>>>>>>> >>>>>>>>> And the updated assert guards ensure that it is the case. >>>>>>>>> >>>>>>>>> It could be a good idea to add a No_Safepoint_Verifier for >>>>>>>>> PopFrame() and NotifyFramePop() >>>>>>>>> to make sure the current/target thread does not go to safepoint >>>>>>>>> until it is returned from >>>>>>>>> update_for_pop_top_frame() and set_frame_pop() correspondingly. >>>>>>>>> A No_Safepoint_Verifier can be also needed in the >>>>>>>>> JvmtiExport::post_method_exit(). >>>>>>>>> >>>>>>>>> These are all places where these functions are called: >>>>>>>>> prims/jvmtiEnv.cpp: >>>>>>>>> state->env_thread_state(this)->set_frame_pop(frame_number); // >>>>>>>>> JvmtiEnv::NotifyFramePop() >>>>>>>>> prims/jvmtiExport.cpp: ets->clear_frame_pop(cur_frame_number); // >>>>>>>>> JvmtiExport::post_method_exit() >>>>>>>>> prims/jvmtiThreadState.cpp: >>>>>>>>> ets->clear_frame_pop(popframe_number); // >>>>>>>>> JvmtiThreadState::update_for_pop_top_frame() >>>>>>>>> >>>>>>>>> The function JvmtiEnvThreadState::clear_to_frame_pop() is never >>>>>>>>> called now. >>>>>>>> >>>>>>>> There is still a concern about recompute_thread_enabled(). >>>>>>>> If it is normally always protected with the JvmtiThreadState_lock >>>>>>>> then the approach above is not going to work. >>>>>>>> I'm trying to check this now. >>>>>>> >>>>>>> Dan, >>>>>>> >>>>>>> I came to a conclusion that these 3 functions still must be >>>>>>> protected >>>>>>> by the JvmtiThreadState_lock when they are called out of a >>>>>>> safepoint. >>>>>>> It is a little bit ugly but has to be safe though. >>>>>>> >>>>>>> Please, let me know if you see eny problems with that. >>>>>>> I'll send a new webrev soon. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since multiple threads can call JVM/TI NotifyFramePop() >>>>>>>>>> on the >>>>>>>>>> same target thread, what keeps the threads from messing with >>>>>>>>>> the list of frame pops simultaneously or messing with the >>>>>>>>>> thread enabled events bits in parallel? >>>>>>>>>> >>>>>>>>>> I suspect that this might also be an issue for >>>>>>>>>> JvmtiEventController::clear_frame_pop() and >>>>>>>>>> JvmtiEventController::clear_to_frame_pop() also. >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiThreadState.cpp >>>>>>>>>> No comments. >>>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> It is the 2-nd round of review because the JTREG com/sun/jdi >>>>>>>>>>> tests discovered a regression >>>>>>>>>>> in the first round change. The issue was in the >>>>>>>>>>> JvmtiEventController::clear_frame_pop() >>>>>>>>>>> lock synchronization that is not allowed at safepoints. >>>>>>>>>>> >>>>>>>>>>> As a result I've changed the JvmtiEnv::NotifyFramePop to >>>>>>>>>>> use a >>>>>>>>>>> VM operation for safety. >>>>>>>>>>> Also, I've removed the lock synchronization from the 3 >>>>>>>>>>> impacted >>>>>>>>>>> JvmtiEventController:: >>>>>>>>>>> functions: set_frame_pop(), clear_frame_pop() and >>>>>>>>>>> clear_to_frame_pop(). >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/25/14 12:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Please, review the fix for: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6471769 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Open webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> >>>>>>>>>>>> This is another Test Stabilization issue. >>>>>>>>>>>> The fix is very similar to other JVMTI stabilization fixes. >>>>>>>>>>>> It is to use safepoints for updating the PopFrame data >>>>>>>>>>>> instead >>>>>>>>>>>> of relying on the >>>>>>>>>>>> suspend equivalent condition mechanism >>>>>>>>>>>> (JvmtiEnv::is_thread_fully_suspended()) >>>>>>>>>>>> which is not adequate from the reliability point of view. >>>>>>>>>>>> >>>>>>>>>>>> Testing: >>>>>>>>>>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From jon.masamitsu at oracle.com Fri Feb 28 13:48:36 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Feb 2014 13:48:36 -0800 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <5310ECD5.8000807@oracle.com> References: <5310ECD5.8000807@oracle.com> Message-ID: <53110434.6070401@oracle.com> Coleen, You're casting something to a Method*, right? Is that assert ever going to fail? Jon On 2/28/2014 12:08 PM, Coleen Phillimore wrote: > Summary: Call is_metadata instead which does less work for the call in > debugInfo.hpp which is called for all compiled code stack frames. > > open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ > bug link https://bugs.openjdk.java.net/browse/JDK-8035735 > > Tested with failing test case, nsk.quick.testlist, jcks and jtreg tests. > > Coleen From coleen.phillimore at oracle.com Fri Feb 28 13:57:35 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 16:57:35 -0500 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <53110434.6070401@oracle.com> References: <5310ECD5.8000807@oracle.com> <53110434.6070401@oracle.com> Message-ID: <5311064F.3080903@oracle.com> On 2/28/2014 4:48 PM, Jon Masamitsu wrote: > Coleen, > > You're casting something to a Method*, right? Is > that assert ever going to fail? It's not going to fail the assert, but it might crash trying to access the Metadata vtable if it's not metadata. I debated this with myself - would we rather have a SEGV there or no assert at all and some problem later on? We don't have a faster way to check whether somethings in the metaspace that is safe from CMS deleting mmap regions while we look at them. Coleen > > Jon > > On 2/28/2014 12:08 PM, Coleen Phillimore wrote: >> Summary: Call is_metadata instead which does less work for the call >> in debugInfo.hpp which is called for all compiled code stack frames. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ >> bug link https://bugs.openjdk.java.net/browse/JDK-8035735 >> >> Tested with failing test case, nsk.quick.testlist, jcks and jtreg tests. >> >> Coleen > From daniel.daugherty at oracle.com Fri Feb 28 14:03:18 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 28 Feb 2014 15:03:18 -0700 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <5310ECD5.8000807@oracle.com> References: <5310ECD5.8000807@oracle.com> Message-ID: <531107A6.3000206@oracle.com> On 2/28/14 1:08 PM, Coleen Phillimore wrote: > Summary: Call is_metadata instead which does less work for the call in > debugInfo.hpp which is called for all compiled code stack frames. > > open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ src/share/vm/code/debugInfo.hpp line 276: // is_metadata is a faster check In the context of the current code review, the comment is fine, but when you read it down the road (by itself), you'll ask yourself: Faster than what? :-) Perhaps: // is_metadata() is a faster check than is_metaspace_object() src/share/vm/oops/metadata.hpp No comments. Thumbs up, modulo Jon M's question... Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8035735 > > Tested with failing test case, nsk.quick.testlist, jcks and jtreg tests. > > Coleen From jon.masamitsu at oracle.com Fri Feb 28 14:33:00 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 28 Feb 2014 14:33:00 -0800 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <5311064F.3080903@oracle.com> References: <5310ECD5.8000807@oracle.com> <53110434.6070401@oracle.com> <5311064F.3080903@oracle.com> Message-ID: <53110E9C.5060004@oracle.com> On 2/28/2014 1:57 PM, Coleen Phillimore wrote: > On 2/28/2014 4:48 PM, Jon Masamitsu wrote: >> Coleen, >> >> You're casting something to a Method*, right? Is >> that assert ever going to fail? > > It's not going to fail the assert, but it might crash trying to access > the Metadata vtable if it's not metadata. I debated this with myself > - would we rather have a SEGV there or no assert at all and some > problem later on? We don't have a faster way to check whether > somethings in the metaspace that is safe from CMS deleting mmap > regions while we look at them. Ok. Looks good then. Jon > > Coleen >> >> Jon >> >> On 2/28/2014 12:08 PM, Coleen Phillimore wrote: >>> Summary: Call is_metadata instead which does less work for the call >>> in debugInfo.hpp which is called for all compiled code stack frames. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ >>> bug link https://bugs.openjdk.java.net/browse/JDK-8035735 >>> >>> Tested with failing test case, nsk.quick.testlist, jcks and jtreg >>> tests. >>> >>> Coleen >> > From coleen.phillimore at oracle.com Fri Feb 28 14:47:36 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 17:47:36 -0500 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <531107A6.3000206@oracle.com> References: <5310ECD5.8000807@oracle.com> <531107A6.3000206@oracle.com> Message-ID: <53111208.5080903@oracle.com> On 2/28/2014 5:03 PM, Daniel D. Daugherty wrote: > On 2/28/14 1:08 PM, Coleen Phillimore wrote: >> Summary: Call is_metadata instead which does less work for the call >> in debugInfo.hpp which is called for all compiled code stack frames. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ > > src/share/vm/code/debugInfo.hpp > line 276: // is_metadata is a faster check > In the context of the current code review, the comment is fine, > but when you read it down the road (by itself), you'll ask > yourself: > Faster than what? :-) > > Perhaps: > > // is_metadata() is a faster check than is_metaspace_object() Thanks - you are right. I updated the comment. Thank you for the code review. Coleen > > src/share/vm/oops/metadata.hpp > No comments. > > Thumbs up, modulo Jon M's question... > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8035735 >> >> Tested with failing test case, nsk.quick.testlist, jcks and jtreg tests. >> >> Coleen > From coleen.phillimore at oracle.com Fri Feb 28 14:49:24 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 28 Feb 2014 17:49:24 -0500 Subject: RFR 8035735: Metaspace::contains become extremely slow in some cases In-Reply-To: <53110E9C.5060004@oracle.com> References: <5310ECD5.8000807@oracle.com> <53110434.6070401@oracle.com> <5311064F.3080903@oracle.com> <53110E9C.5060004@oracle.com> Message-ID: <53111274.1040407@oracle.com> On 2/28/2014 5:33 PM, Jon Masamitsu wrote: > > On 2/28/2014 1:57 PM, Coleen Phillimore wrote: >> On 2/28/2014 4:48 PM, Jon Masamitsu wrote: >>> Coleen, >>> >>> You're casting something to a Method*, right? Is >>> that assert ever going to fail? >> >> It's not going to fail the assert, but it might crash trying to >> access the Metadata vtable if it's not metadata. I debated this >> with myself - would we rather have a SEGV there or no assert at all >> and some problem later on? We don't have a faster way to check >> whether somethings in the metaspace that is safe from CMS deleting >> mmap regions while we look at them. > > Ok. Looks good then. Thanks Jon! Coleen > > Jon >> >> Coleen >>> >>> Jon >>> >>> On 2/28/2014 12:08 PM, Coleen Phillimore wrote: >>>> Summary: Call is_metadata instead which does less work for the call >>>> in debugInfo.hpp which is called for all compiled code stack frames. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8035735/ >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8035735 >>>> >>>> Tested with failing test case, nsk.quick.testlist, jcks and jtreg >>>> tests. >>>> >>>> Coleen >>> >> > From vladimir.kozlov at oracle.com Fri Feb 28 15:25:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Feb 2014 15:25:48 -0800 Subject: RFR (XS): 8035983: Fix "Native frames:" in crash report (hs_err file) In-Reply-To: <2FBF907F-6AD8-4D8A-9266-01D7AD8C0EEB@oracle.com> References: <530FD966.7030306@oracle.com> <72C0DBF6-6BFE-4560-B2C8-950D39E84C8B@oracle.com> <530FEFA4.1040105@oracle.com> <48C6875B-3BB8-4D47-A798-3610EFF33C73@oracle.com> <530FF6DB.50301@oracle.com> <2FBF907F-6AD8-4D8A-9266-01D7AD8C0EEB@oracle.com> Message-ID: <53111AFC.6@oracle.com> On 2/27/14 7:59 PM, Christian Thalinger wrote: > > On Feb 27, 2014, at 6:39 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8035983/webrev.01/ >> >> New check is used only for JavaThread where it is definitely initialized and where we have problem with call stack dump. > > Looks good. Just to be sure; +1 would also work here: > > + if (!_thread->on_local_stack((address)(fr.sp() + 4))) > > Right? No, for Stack: [0xffff80ffa69f8000,0xffff80ffa6af8000] I see for first frame "_lwp_start+0x0" frame::_sp = 0xffff80ffa6af7ff0 I just tested it on SPARC and it needs more than +4 (+11), the first frame has: frame::_sp = 0xffffffff6befff50 It seems using fr.sender_sp() in the check work on x86 and sparc. On x86 it return stack_base value on sparc it returns STACK_BIAS. if (!_thread->on_local_stack((address)(fr.sender_sp() + 1))) break; http://cr.openjdk.java.net/~kvn/8035983/webrev.02/ Thanks, Vladimir > >> >> thanks, >> Vladimir >> >> On 2/27/14 6:31 PM, Christian Thalinger wrote: >>> >>> On Feb 27, 2014, at 6:08 PM, Vladimir Kozlov wrote: >>> >>>> >>>> >>>> On 2/27/14 5:38 PM, Christian Thalinger wrote: >>>>> >>>>> On Feb 27, 2014, at 4:33 PM, Vladimir Kozlov wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8035983 >>>>>> http://cr.openjdk.java.net/~kvn/8035983/webrev/ >>>>>> >>>>>> We don't print whole stack if native frames intermix with compiled java frames (on x86 fp is used by compiled code). >>>>>> Instead of using os::is_first_C_frame() which produces incorrect result for compiled java frames I am suggesting to look on frame's stack pointer relative to stack base. >>>>> >>>>> I have two questions: >>>>> >>>>> 1) Why does this work: >>>>> >>>>> + // Catch very first native frame by using stack address. >>>>> + if (!_thread->on_local_stack((address)(fr.sp() + 4))) break; >>>>> >>>>> Because we set the stack base to the current value when we start the thread? >>>> >>>> You are right not all threads have stack base set (all VM's thread do). So I need to add check for stack_size() != 0 and use is_first_C_frame() if it is 0 (uninitialized). >>> >>> Maybe add a comment why the on_local_stack() check works. >>> >>>> >>>>> >>>>> 2) Why does this not work? I have seen many correct stack traces in the past. >>>> >>>> Look on os::is_first_C_frame(). It does some stupid simple checks which nothing to do with real value. The test will pass if a java compiled code has a pointer in EBP register. >>> >>> Ah, that?s what I was missing. Makes sense then. Yeah, the code in os::is_first_C_frame() is weird :-) >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Output before the fix: >>>>>> >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>>>> >>>>>> >>>>>> After the fix: >>>>>> >>>>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>>>> V [libjvm.so+0x1e28428] void VMError::report(outputStream*)+0x1478 >>>>>> V [libjvm.so+0x1e29dd4] void VMError::report_and_die()+0x6b4 >>>>>> V [libjvm.so+0x14ad9ba] void report_vm_error(const char*,int,const char*,const char*)+0x9a >>>>>> V [libjvm.so+0x1b6ccf5] void ObjectMonitor::exit(bool,Thread*)+0x125 >>>>>> V [libjvm.so+0x1d41cda] void ObjectSynchronizer::fast_exit(oopDesc*,BasicLock*,Thread*)+0x38a >>>>>> V [libjvm.so+0x1d41fba] void ObjectSynchronizer::slow_exit(oopDesc*,BasicLock*,Thread*)+0x2a >>>>>> V [libjvm.so+0x1caa13f] void SharedRuntime::complete_monitor_unlocking_C(oopDesc*,BasicLock*)+0x27f >>>>>> J 13 C2 java.util.Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object; (69 bytes) @ 0xffff80ffb979da84 [0xffff80ffb979d700+0x384] >>>>>> J 10% C2 Test.Worker()V (381 bytes) @ 0xffff80ffb97a1c8c [0xffff80ffb97a1840+0x44c] >>>>>> j Test$1.run()V+0 >>>>>> v ~StubRoutines::call_stub >>>>>> V [libjvm.so+0x177d196] void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x886 >>>>>> V [libjvm.so+0x1b9a6c8] void os::os_exception_wrapper(void(*)(JavaValue*,methodHandle*,JavaCallArguments*,Thread*),JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x38 >>>>>> V [libjvm.so+0x177c90a] void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x9a >>>>>> V [libjvm.so+0x177be70] void JavaCalls::call_virtual(JavaValue*,KlassHandle,Symbol*,Symbol*,JavaCallArguments*,Thread*)+0x250 >>>>>> V [libjvm.so+0x177bf56] void JavaCalls::call_virtual(JavaValue*,Handle,KlassHandle,Symbol*,Symbol*,Thread*)+0x66 >>>>>> V [libjvm.so+0x1896897] void thread_entry(JavaThread*,Thread*)+0xc7 >>>>>> V [libjvm.so+0x1d8f23e] void JavaThread::thread_main_inner()+0x18e >>>>>> V [libjvm.so+0x1d8f09a] void JavaThread::run()+0x1fa >>>>>> V [libjvm.so+0x1b8f3c8] java_start+0x248 >>>>>> C [libc.so.1+0x122105] _thrp_setup+0xa5 >>>>>> C [libc.so.1+0x1223b0] _lwp_start+0x0 >>> > From david.holmes at oracle.com Fri Feb 28 15:47:37 2014 From: david.holmes at oracle.com (David Holmes) Date: Sat, 01 Mar 2014 09:47:37 +1000 Subject: JDK-8036003: Add variable not to separate debug information. In-Reply-To: <5310AD70.2070908@ysfactory.dip.jp> References: <20140228091835.58EB8C21F24@msgw007-05.ocn.ad.jp> <53106F4A.8030905@oracle.com> <53109772.9070808@oracle.com> <5310AD70.2070908@ysfactory.dip.jp> Message-ID: <53112019.9050504@oracle.com> On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote: >> The proper way to fix this is to disable FDS. > > Does this mean I have to pass --disable-debug-symbols to configure ? > I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols > to configure, gcc/g++ is not passed -g option. "-g" is needed to generate > debuginfo. There are three pieces to all of this: 1. Generating debug symbols in the binaries (via gcc -g or whatever) 2. Generating debuginfo files (zipped or not) (FDS) 3. Stripping debug symbols from the binaries (strip-policy) It may be that we don't have clean separation between them, and if so that should be fixed, but I don't see the current proposal as the way forward. Also there may well be differences between how things are handled on the JDK side and hotspot side. I will try to look closer if I get a chance but my time is limited at the moment. David > > Thanks, > > Yasumasa > > > On 2014/02/28 23:04, Daniel D. Daugherty wrote: >> The proper way to fix this is to disable FDS. We should not need >> yet another option to control debug info. >> >> Dan >> >> >> On 2/28/14 4:13 AM, David Holmes wrote: >>> Hi, >>> >>> As I put in the bug report this seems way too complicated. Seems to me >>> all you need to do to get what you want is not use FDS and not strip the >>> symbols from the binary. The former is trivial. The latter is more >>> awkward as the strip policy stuff does not work as I would want it to >>> work, but still doable. >>> >>> David >>> >>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> >>>> Currently, configure script can accept --disable-debug-symbols and >>>> --disable-zip-debug-info as controlling to generate debug information. >>>> However, current makefiles cannot build ELF binaries which is contained >>>> debug information with "images" target. >>>> >>>> Some Linux distros use RPM as package manager. >>>> RPM is built by rpmbuild command, it strips symbols and debug information >>>> during to generate rpm packages. >>>> https://fedoraproject.org/wiki/Packaging:Debuginfo >>>> >>>> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo . >>>> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not >>>> contain debug information. Actual debug information is shipped by OpenJDK >>>> debuginfo package. >>>> This packaging is important when we have to debug JVM/JNI libraries. >>>> If we want to use debugging tools (GDB, SystemTap, etc...), they may requires >>>> debuginfo package. Debuggee (e.g. libjvm.so) points libjvm.so.debug which is >>>> located at sub directory in /usr/lib/debug . It is defined in ELF section >>>> (.note.gnu.build-id) of libjvm.so . However libjvm.so.debug does not contain >>>> valid debug information. We need to access libjvm.debuginfo.debug at same location. >>>> >>>> >>>> When we think to build OpenJDK rpm packages, we have to build ELF binaries >>>> which contain all debug information. we should not to separate debug information. >>>> >>>> >>>> Thus I want to add a variable "SEPARATED_DEBUGINFO_FILES" . >>>> If we pass "SEPARATED_DEBUGINFO_FILES=false" to make command, "make" does not >>>> execute objcopy command for generating debuginfo binaries. >>>> >>>> If we build rpm packages, we also have to add "STRIP_POLICY=no_strip" to arguments >>>> of make command. Or ELF binaries will be stripped. >>>> >>>> >>>> I've uploaded webrev for this enhancement. >>>> This is separated 3-part: top of forest, hotspot, jdk >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/ >>>> >>>> Please review it and sponsoring! >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> P.S. >>>> I tried to add SEPARATED_DEBUGINFO_FILES as a configure option like >>>> "--disable-separated-debug-info" . >>>> I ran configure which is located at jdk9/dev directory after I ran autoconf >>>> and common/autoconf/autogen.sh. However it failed. >>>> >>>> I guess this is caused by changeset as below. >>>> JDK-8035495: Improvements in autoconf integration >>>> http://hg.openjdk.java.net/jdk9/dev/rev/6e29cd9ac2b4 >>>> >>>> This changes add "CHECKME" option to configure script. However, this changes >>>> affects "configure" only. It should change "configure.ac" . >>>> >> > From daniel.daugherty at oracle.com Fri Feb 28 16:27:27 2014 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Sat, 01 Mar 2014 00:27:27 +0000 Subject: hg: hsx/jdk7u/hotspot: 8028073: race condition in ObjectMonitor implementation causing deadlocks Message-ID: <20140301002732.CC94E6241A@hg.openjdk.java.net> Changeset: 7d0fcff82726 Author: dcubed Date: 2014-02-28 14:56 -0800 URL: http://hg.openjdk.java.net/hsx/jdk7u/hotspot/rev/7d0fcff82726 8028073: race condition in ObjectMonitor implementation causing deadlocks Summary: Move redo of ParkEvent.unpark() after JVMTI_EVENT_MONITOR_WAITED event handler is called. Reviewed-by: rdurbin, acorn, sspitsyn, dsimms, dholmes ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/objectMonitor.cpp