From Alan.Bateman at oracle.com Thu Jan 1 08:29:00 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Jan 2015 08:29:00 +0000 Subject: RFR: 8028357: Unnecessary allocation in AliasFileParser In-Reply-To: <54A3DAF1.60601@oracle.com> References: <54A17895.3010707@oracle.com> <54A2AC06.6030705@oracle.com> <54A2CDBF.7010408@oracle.com> <54A2E255.3080708@oracle.com> <54A325B0.3070703@oracle.com> <54A3DAF1.60601@oracle.com> Message-ID: <54A5054C.7090405@oracle.com> On 31/12/2014 11:16, Jaroslav Bachorik wrote: > : >> >> I guess something like "// 8028357 removed old, inefficient debug >> logging" in place of the DEBUG declaration in each affected file >> wouldn't be too busy and also give future maintainers a handle to this >> changeset and thus this discussion. Would that suffice? > > Sounds good. This looks a bit odd to me. If you just want to communicate that the class doesn't have logging for performance reasons then I think that should be stated in a comment without reference to removed code. -Alan. From serguei.spitsyn at oracle.com Fri Jan 2 22:23:11 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 02 Jan 2015 14:23:11 -0800 Subject: 2-nd round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54A44562.3090207@oracle.com> References: <54A43584.6050707@oracle.com> <54A44300.4010801@oracle.com> <54A44562.3090207@oracle.com> Message-ID: <54A71A4F.4050308@oracle.com> Coleen, Please, find new open webrev here: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.2/ I've added a separate helper class in the VM_RedefineClasses and new method in the klassItable klass. TBD: still need to run the SVC tests listed in the first email. I'm on vacation from today till Jan 9 but will try to reply on emails in non-active mode. Thanks, Serguei On 12/31/14 10:50 AM, serguei.spitsyn at oracle.com wrote: > Colleen, > > Thank you for a quick review. > You are right, this is a good catch! > I need to rework my fix as it is incorrect in general. > > > On 12/31/14 10:40 AM, Coleen Phillimore wrote: >> >> The adjustment should be in klassItable::adjust_method_entries() not >> the checking function. I don't think >> check_no_old_or_obsolete_entries is called in product mode. >> >> I still don't see how the first klassItable::adjust_method_entries() >> missed this function. > > The Unsafe::throw_illegal_access is added to other itables, not to the > one that belongs to the class Unsafe. > > Thanks, > Serguei > > >> >> Coleen >> >> On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ >>> >>> >>> >>> Summary: >>> >>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>> place of a default >>> interface method in the itable if a default method was not >>> defined in the interface. >>> >>> This approach creates a problem when the class sun.misc.Unsafe is >>> retransformed. >>> The Method* pointer to the old (redefined) method in the itable >>> triggers an assert >>> (see the hs_err log in the bug report). >>> >>> The fix is to replace the old method in the itable with the >>> latest method version. >>> >>> >>> Testing: >>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>> >>> >>> Thanks, >>> Serguei >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Jan 2 23:04:30 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 02 Jan 2015 18:04:30 -0500 Subject: 2-nd round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54A71A4F.4050308@oracle.com> References: <54A43584.6050707@oracle.com> <54A44300.4010801@oracle.com> <54A44562.3090207@oracle.com> <54A71A4F.4050308@oracle.com> Message-ID: <54A723FE.2080501@oracle.com> Hi Serguei, I don't see why you don't add a || the_class_oop == unsafe to the if statement I pointed out in the bug. Then you don't have to walk the CLDG classes again. Have a nice vacation! Thanks, Coleen On 1/2/15, 5:23 PM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Please, find new open webrev here: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.2/ > > I've added a separate helper class in the VM_RedefineClasses and new > method in the klassItable klass. > TBD: still need to run the SVC tests listed in the first email. > > I'm on vacation from today till Jan 9 but will try to reply on emails > in non-active mode. > > Thanks, > Serguei > > > On 12/31/14 10:50 AM, serguei.spitsyn at oracle.com wrote: >> Colleen, >> >> Thank you for a quick review. >> You are right, this is a good catch! >> I need to rework my fix as it is incorrect in general. >> >> >> On 12/31/14 10:40 AM, Coleen Phillimore wrote: >>> >>> The adjustment should be in klassItable::adjust_method_entries() not >>> the checking function. I don't think >>> check_no_old_or_obsolete_entries is called in product mode. >>> >>> I still don't see how the first klassItable::adjust_method_entries() >>> missed this function. >> >> The Unsafe::throw_illegal_access is added to other itables, not to >> the one that belongs to the class Unsafe. >> >> Thanks, >> Serguei >> >> >>> >>> Coleen >>> >>> On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>> place of a default >>>> interface method in the itable if a default method was not >>>> defined in the interface. >>>> >>>> This approach creates a problem when the class sun.misc.Unsafe >>>> is retransformed. >>>> The Method* pointer to the old (redefined) method in the itable >>>> triggers an assert >>>> (see the hs_err log in the bug report). >>>> >>>> The fix is to replace the old method in the itable with the >>>> latest method version. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Jan 3 00:13:19 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 02 Jan 2015 16:13:19 -0800 Subject: 2-nd round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54A723FE.2080501@oracle.com> References: <54A43584.6050707@oracle.com> <54A44300.4010801@oracle.com> <54A44562.3090207@oracle.com> <54A71A4F.4050308@oracle.com> <54A723FE.2080501@oracle.com> Message-ID: <54A7341F.50105@oracle.com> Hi Coleen, Thank you for the quick response! On 1/2/15 3:04 PM, Coleen Phillimore wrote: > > Hi Serguei, > > I don't see why you don't add a || the_class_oop == unsafe to the if > statement I pointed out in the bug. Then you don't have to walk the > CLDG classes again. Do you mean something like in the webrev below ? http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.3/ I like this! > > Have a nice vacation! Thanks! Serguei > > Thanks, > Coleen > > On 1/2/15, 5:23 PM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Please, find new open webrev here: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.2/ >> >> I've added a separate helper class in the VM_RedefineClasses and new >> method in the klassItable klass. >> TBD: still need to run the SVC tests listed in the first email. >> >> I'm on vacation from today till Jan 9 but will try to reply on emails >> in non-active mode. >> >> Thanks, >> Serguei >> >> >> On 12/31/14 10:50 AM, serguei.spitsyn at oracle.com wrote: >>> Colleen, >>> >>> Thank you for a quick review. >>> You are right, this is a good catch! >>> I need to rework my fix as it is incorrect in general. >>> >>> >>> On 12/31/14 10:40 AM, Coleen Phillimore wrote: >>>> >>>> The adjustment should be in klassItable::adjust_method_entries() >>>> not the checking function. I don't think >>>> check_no_old_or_obsolete_entries is called in product mode. >>>> >>>> I still don't see how the first >>>> klassItable::adjust_method_entries() missed this function. >>> >>> The Unsafe::throw_illegal_access is added to other itables, not to >>> the one that belongs to the class Unsafe. >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Coleen >>>> >>>> On 12/31/14, 12:42 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8068162-JVMTI-old.1/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>>> place of a default >>>>> interface method in the itable if a default method was not >>>>> defined in the interface. >>>>> >>>>> This approach creates a problem when the class sun.misc.Unsafe >>>>> is retransformed. >>>>> The Method* pointer to the old (redefined) method in the itable >>>>> triggers an assert >>>>> (see the hs_err log in the bug report). >>>>> >>>>> The fix is to replace the old method in the itable with the >>>>> latest method version. >>>>> >>>>> >>>>> Testing: >>>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shanliang.jiang at oracle.com Mon Jan 5 17:47:29 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Mon, 05 Jan 2015 18:47:29 +0100 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected Message-ID: <54AACE31.80402@oracle.com> Hi, Please review this fix: bug: https://bugs.openjdk.java.net/browse/JDK-8068418 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ This must be a timing issue in the test, the test called: t.join(5000L); to wait a thread's dying, I reproduced the bug by insert at line 202: try { Thread.sleep(5100); } catch (Exception ee) {} to delay the t's dying. The fix is to replace: t.join(5000L); by: t.join(); and replace: Object.wait(timeout); by CountDownLatch.countDown(); The test harness timeout will be used as the max waiting timeout. Shanliang From daniel.daugherty at oracle.com Tue Jan 6 01:12:36 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 05 Jan 2015 18:12:36 -0700 Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: <5491810F.6030900@oracle.com> References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com> <54914897.2050006@oracle.com> <54915304.4080503@oracle.com> <54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com> <5491810F.6030900@oracle.com> Message-ID: <54AB3684.1000300@oracle.com> > The default JTreg time out is 5 minutes... I believe the default JTREG timeout is 120 seconds or 2 minutes. Dan On 12/17/14 6:11 AM, Yekaterina Kantserova wrote: > > Hopefully the last version :) > > Erik has recommended to skip the whole timeout concept. Instead the > test will loop until a decreasing count is found. Otherwise the test > will timeout. The default JTreg time out is 5 minutes so it would be > enough even for slower configurations. > > The new webrev can be found here: > http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/ > > // Katja > > > > On 12/17/2014 12:33 PM, Daniel Fuchs wrote: >> On 17/12/14 12:05, Yekaterina Kantserova wrote: >>> Daniel, >>> >>> It's really funny to get such a feedback! >>> >>> (1) The output from test right now looks like: >>> >>> ----------System.out:(7/183)---------- >>> call count = 1000 >>> instance count: 1001 >>> call count = 2000 >>> instance count: 1001 >>> Finishing early due to non-increasing instance count >>> increasing count: 1 >>> decreasing or the same count: 1 >>> >>> so printing the value of 'count' is already in there: 'call count ='. >> >> I meant to print the final value for count - but OK - having the >> 'call count' printed every 1000 count should be enough :-) >> >> >>> (2) In the case we want to have an extra condition I think it should be >>> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000' >>> will result in having just one iteration (we will left the loop on >>> 1100) >>> and test will fail on assert. >> >> right. my mistake. you need at least two histograms. >> >>> The test timeout value should be increased as well. Right now it's >>> 120 + >>> 30 sec. >>> >>> * @run main/timeout=150 TestLoggerWeakRefLeak Logger >>> >>> If the test will not be completed in 120 s the extra 30 s will not make >>> the trick and JTreg will interrupt it. What do you think will be >>> enough? >> >> I am not sure - but I guess what you have now should be good enough >> for starter. In the problematic configurations there often is >> an additional timeout factor - so in such case the real jtreg timeout >> would I believe be something like 150*4 anyway - which should hopefully >> leave time enough for the while loop to take two histograms. Simply >> adding the extra condition to keep looping until we have at least two >> should do the trick. >> >> best regards, and thanks again for taking care of 6977426! >> >> -- daniel >> >>> >>> // Katja >>> >>> >>> >>> On 12/17/2014 10:55 AM, Daniel Fuchs wrote: >>>> Hi Katja, >>>> >>>> Sorry for not thinking of that when I replied earlier. >>>> Your new test is so much more readable than the old shell >>>> script :-) >>>> >>>> These are minor suggestions but they might help analysis >>>> if the test fails: >>>> >>>> On 17/12/14 10:10, Yekaterina Kantserova wrote: >>>>> Hi, >>>>> >>>>> Thanks for all reviews! >>>>> >>>>> The new webrev can be found here: >>>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/ >>>> >>>> Not that I believe it's very likely to happen, but I wonder >>>> if the condition to exit the while loop: >>>> >>>> 79 while (now < (startTime + (LOOP_TIME_SEC * 1000))) { >>>> >>>> should also make sure that count > 1000 - and continue if not. >>>> (Thinking of passed timeout related issues when tests where run >>>> with -Xcomp on fastdebug builds during integration nightlies) >>>> >>>> Possibly printing the value of 'count' before the assert >>>> at line 103 could help with debugging too, if the test actually >>>> fails (even though the combination of increasingCount >>>> + decreasingCount would give us a hint) >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>>> >>>>> // Katja >>>>> >>>>> >>>>> >>>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote: >>>>>> Hi Katja, >>>>>> >>>>>> This request should probably go to core-libs as well. >>>>>> >>>>>> Other than that I have just a few nits: >>>>>> >>>>>> test/java/util/logging/TestLoggerWeakRefLeak.java >>>>>> >>>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ? >>>>>> L127: // in LogManager.loggers that *arebeing* properly managed -> >>>>>> *are being* >>>>>> >>>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the >>>>>> 'count' variable to always return 100. Could they be made to >>>>>> return a >>>>>> constant instead? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I please have a review of this fix. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426 >>>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/ >>>>>>> >>>>>>> java/util/logging/LoggerWeakRefLeak.sh and >>>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and >>>>>>> rewritten in >>>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't >>>>>>> test >>>>>>> the product but sun/tool/common library functionality. >>>>>>> >>>>>>> Thanks, >>>>>>> Katja >>>>>> >>>>> >>>> >>> >> > > From david.holmes at oracle.com Tue Jan 6 02:46:20 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Jan 2015 12:46:20 +1000 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54AACE31.80402@oracle.com> References: <54AACE31.80402@oracle.com> Message-ID: <54AB4C7C.10208@oracle.com> Hi Shanliang, On 6/01/2015 3:47 AM, shanliang wrote: > Hi, > > Please review this fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8068418 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ > > This must be a timing issue in the test, the test called: > t.join(5000L); to wait a thread's dying, I reproduced the bug by > insert at line 202: > try { > Thread.sleep(5100); > } catch (Exception ee) {} > to delay the t's dying. > > The fix is to replace: > t.join(5000L); > by: > t.join(); > > and replace: > Object.wait(timeout); > by > CountDownLatch.countDown(); Okay - you could have just done wait() but the switch to CountDownLatch is somewhat cleaner. > The test harness timeout will be used as the max waiting timeout. So the test will now never report that it thinks it has hit a deadlock, it will just timeout. But you added some extra printout so okay I guess - but I suggest adding a comment at the top (where @run etc are) saying that if test times out then deadlock is suspected. Minor nit: System.out.println("DeadlockTest-addNotificationListener waiting the XXX thread to die. should say "waiting for the XXX thread ..." Thanks, David > Shanliang From shanliang.jiang at oracle.com Tue Jan 6 11:03:38 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 06 Jan 2015 12:03:38 +0100 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54AB4C7C.10208@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> Message-ID: <54ABC10A.6090707@oracle.com> David, Here is the new version, I have added the comments as you suggested, and I replaced the variable "sources" with a synchronized list. http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ Thanks for the review. Shanliang David Holmes wrote: > Hi Shanliang, > > On 6/01/2015 3:47 AM, shanliang wrote: >> Hi, >> >> Please review this fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >> >> This must be a timing issue in the test, the test called: >> t.join(5000L); to wait a thread's dying, I reproduced the bug by >> insert at line 202: >> try { >> Thread.sleep(5100); >> } catch (Exception ee) {} >> to delay the t's dying. >> >> The fix is to replace: >> t.join(5000L); >> by: >> t.join(); >> >> and replace: >> Object.wait(timeout); >> by >> CountDownLatch.countDown(); > > Okay - you could have just done wait() but the switch to > CountDownLatch is somewhat cleaner. > >> The test harness timeout will be used as the max waiting timeout. > > So the test will now never report that it thinks it has hit a > deadlock, it will just timeout. But you added some extra printout so > okay I guess - but I suggest adding a comment at the top (where @run > etc are) saying that if test times out then deadlock is suspected. > > Minor nit: > > System.out.println("DeadlockTest-addNotificationListener waiting the > XXX thread to die. > > should say "waiting for the XXX thread ..." > > Thanks, > David > >> Shanliang From david.holmes at oracle.com Tue Jan 6 12:08:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Jan 2015 22:08:40 +1000 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABC10A.6090707@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> Message-ID: <54ABD048.1040903@oracle.com> On 6/01/2015 9:03 PM, shanliang wrote: > David, > > Here is the new version, I have added the comments as you suggested, and > I replaced the variable "sources" with a synchronized list. Why did you do that ?? Vector is synchronized so it was fine for the job. David > http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ > > Thanks for the review. > Shanliang > > David Holmes wrote: >> Hi Shanliang, >> >> On 6/01/2015 3:47 AM, shanliang wrote: >>> Hi, >>> >>> Please review this fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>> >>> This must be a timing issue in the test, the test called: >>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>> insert at line 202: >>> try { >>> Thread.sleep(5100); >>> } catch (Exception ee) {} >>> to delay the t's dying. >>> >>> The fix is to replace: >>> t.join(5000L); >>> by: >>> t.join(); >>> >>> and replace: >>> Object.wait(timeout); >>> by >>> CountDownLatch.countDown(); >> >> Okay - you could have just done wait() but the switch to >> CountDownLatch is somewhat cleaner. >> >>> The test harness timeout will be used as the max waiting timeout. >> >> So the test will now never report that it thinks it has hit a >> deadlock, it will just timeout. But you added some extra printout so >> okay I guess - but I suggest adding a comment at the top (where @run >> etc are) saying that if test times out then deadlock is suspected. >> >> Minor nit: >> >> System.out.println("DeadlockTest-addNotificationListener waiting the >> XXX thread to die. >> >> should say "waiting for the XXX thread ..." >> >> Thanks, >> David >> >>> Shanliang > From shanliang.jiang at oracle.com Tue Jan 6 12:56:05 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 06 Jan 2015 13:56:05 +0100 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABD048.1040903@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> <54ABD048.1040903@oracle.com> Message-ID: <54ABDB65.2070109@oracle.com> David Holmes wrote: > On 6/01/2015 9:03 PM, shanliang wrote: >> David, >> >> Here is the new version, I have added the comments as you suggested, and >> I replaced the variable "sources" with a synchronized list. > > Why did you do that ?? Vector is synchronized so it was fine for the job. You are right! I have changed back to Vector: http://cr.openjdk.java.net/~sjiang/JDK-8068418/02/ I forgot Vetor is synchronized, so long time not use it. Thanks, Shanliang > > David > >> http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ >> >> Thanks for the review. >> Shanliang >> >> David Holmes wrote: >>> Hi Shanliang, >>> >>> On 6/01/2015 3:47 AM, shanliang wrote: >>>> Hi, >>>> >>>> Please review this fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>>> >>>> This must be a timing issue in the test, the test called: >>>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>>> insert at line 202: >>>> try { >>>> Thread.sleep(5100); >>>> } catch (Exception ee) {} >>>> to delay the t's dying. >>>> >>>> The fix is to replace: >>>> t.join(5000L); >>>> by: >>>> t.join(); >>>> >>>> and replace: >>>> Object.wait(timeout); >>>> by >>>> CountDownLatch.countDown(); >>> >>> Okay - you could have just done wait() but the switch to >>> CountDownLatch is somewhat cleaner. >>> >>>> The test harness timeout will be used as the max waiting timeout. >>> >>> So the test will now never report that it thinks it has hit a >>> deadlock, it will just timeout. But you added some extra printout so >>> okay I guess - but I suggest adding a comment at the top (where @run >>> etc are) saying that if test times out then deadlock is suspected. >>> >>> Minor nit: >>> >>> System.out.println("DeadlockTest-addNotificationListener waiting the >>> XXX thread to die. >>> >>> should say "waiting for the XXX thread ..." >>> >>> Thanks, >>> David >>> >>>> Shanliang >> From jaroslav.bachorik at oracle.com Tue Jan 6 20:25:30 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 06 Jan 2015 21:25:30 +0100 Subject: [ping] Re: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5492E4D1.7040501@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> Message-ID: <54AC44BA.9030309@oracle.com> On 18.12.2014 15:29, Jaroslav Bachorik wrote: > On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> You can set SO_LINGER to zero, in this case socket will be closed >> immediately without waiting in TIME_WAIT >> >> But there are no reliable way to predict whether you can take this port >> or not after you close it. >> >> So the only valid solution is to try to connect to a random port and if >> this attempt fails try another random port. Everything else will cause >> more or less frequent intermittent failures. > > Thanks for all the suggestions! > > http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 > > I've enhanced the original patch with the retry logic using different > random port if starting the JMX agent on the provided port fails with > BindException. > > I'm keeping there the changes for properly closing the ports opened for > the test purposes and also setting the SO_REUSEADDR - anyway, it does > not make sense to reuse the ephemeral test ports. > > I've split the original "test_06" test case in order to keep it readable > even with the new retry logic - and also to make each test case to test > just one scenario. > > Cheers, > > -JB- > >> >> -Dmitry >> >> >> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>> >>>>>> The test fails very intermittently when RMI registry is trying to >>>>>> bind >>>>>> to a port >>>>>> previously used in the test (via ServerSocket). >>>>>> >>>>>> This seems to be caused by the sockets created via `new >>>>>> ServerSocket(0)` and >>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>> explicitly >>>>>> forbidding the reusable mode. >>>>> >>>>> Hi Jaroslav, >>>>> >>>>> I happened to see this fly by, and there are (I think) some similar >>>>> issues going on in the RMI tests. >>>>> >>>>> But first I'll note that I don't think setReuseAddress() will have the >>>>> effect that you want. Typically it's set to true before binding a >>>>> socket, so that a subsequent bind operation will succeed even if the >>>>> address/port is already in use. ServerSockets created with new >>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>> setReuseAddress(false) will do on such sockets. The spec says behavior >>>>> is undefined, but my bet is that it does nothing. >>>>> >>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>> difference, >>>>> but I don't have much confidence it will help. >>>>> >>>>> The potential similarity to the RMI tests is exemplified by >>>>> JDK-8049202 >>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>> registry as follows: >>>>> >>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>>> RMI registry port] in order to ensure that 1099 isn't in use by >>>>> something else already; >>>>> >>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>> >>>>> 3. Then it creates a new RMI registry on port 1099. >>>>> >>>>> In principle, this should succeed, yet it fails around 10% of the time >>>>> on some systems. The error is "port already in use". My best theory is >>>>> that even though the socket has just been closed by a user program, >>>>> the >>>>> kernel has to run the socket through some of the socket states such as >>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>> closed >>>>> and is available for reuse. If a program -- even the same one -- >>>>> attempts to open a socket on the same port before the socket has >>>>> reached >>>>> its final state, it will get an "already in use error". >>>>> >>>>> If this is true I don't believe that setting SO_REUSEADDR will work if >>>>> the socket is in one of these final states. (I remember reading this >>>>> somewhere but I'm not sure where at the moment. I can try to dig it up >>>>> if there is interest.) >>>>> >>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>> also >>>>> open to hearing about ways to deal with this problem. >>>>> >>>>> Could something similar be going on with this JMX test? >>>> >>>> Hm, this is exactly what happened with this test :( >>>> >>>> The problem is that the port is reported as available while it is still >>>> occupied and RMI registry attempts to start using that port. >>>> >>>> If setting SO_REUSEADDR does not work then the only solution would >>>> be to >>>> retry the test case when this exception occurs. >>> >>> Further investigation shows that the problem was rather the client >>> connecting to a socket being shut down. >>> >>> It sounds like setting SO_REUSEADDR to false should prevent this >>> failure. >>> >>> From the ServerSocket javadoc: >>> "When a TCP connection is closed the connection may remain in a timeout >>> state for a period of time after the connection is closed (typically >>> known as the TIME_WAIT state or 2MSL wait state). For applications using >>> a well known socket address or port it may not be possible to bind a >>> socket to the required SocketAddress if there is a connection in the >>> timeout state involving the socket address or port." >>> >>> It also turns out that the test does not close the server sockets >>> properly so there might be several sockets being opened or timed out >>> dangling around. >>> >>> I've updated the test so it is setting SO_REUSEADDR for all the new >>> ServerSockets instances + introduced the mechanism to run the test code >>> while properly cleaning up any allocated ports. >>> >>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>> >>> -JB- >>> >>>> >>>> -JB- >>>> >>>>> >>>>> s'marks >>>> >>> >> >> > From dmitry.samersoff at oracle.com Tue Jan 6 22:00:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 07 Jan 2015 01:00:52 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <5492E4D1.7040501@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> Message-ID: <54AC5B14.1020001@oracle.com> Jaroslav, It might be better to just choose a random digit between 49152?65535 and attempt to use it. -Dmitry On 2014-12-18 17:29, Jaroslav Bachorik wrote: > On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> You can set SO_LINGER to zero, in this case socket will be closed >> immediately without waiting in TIME_WAIT >> >> But there are no reliable way to predict whether you can take this port >> or not after you close it. >> >> So the only valid solution is to try to connect to a random port and if >> this attempt fails try another random port. Everything else will cause >> more or less frequent intermittent failures. > > Thanks for all the suggestions! > > http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 > > I've enhanced the original patch with the retry logic using different > random port if starting the JMX agent on the provided port fails with > BindException. > > I'm keeping there the changes for properly closing the ports opened for > the test purposes and also setting the SO_REUSEADDR - anyway, it does > not make sense to reuse the ephemeral test ports. > > I've split the original "test_06" test case in order to keep it readable > even with the new retry logic - and also to make each test case to test > just one scenario. > > Cheers, > > -JB- > >> >> -Dmitry >> >> >> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>> Please, review the following test change >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>> >>>>>> The test fails very intermittently when RMI registry is trying to >>>>>> bind >>>>>> to a port >>>>>> previously used in the test (via ServerSocket). >>>>>> >>>>>> This seems to be caused by the sockets created via `new >>>>>> ServerSocket(0)` and >>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>> explicitly >>>>>> forbidding the reusable mode. >>>>> >>>>> Hi Jaroslav, >>>>> >>>>> I happened to see this fly by, and there are (I think) some similar >>>>> issues going on in the RMI tests. >>>>> >>>>> But first I'll note that I don't think setReuseAddress() will have the >>>>> effect that you want. Typically it's set to true before binding a >>>>> socket, so that a subsequent bind operation will succeed even if the >>>>> address/port is already in use. ServerSockets created with new >>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>> setReuseAddress(false) will do on such sockets. The spec says behavior >>>>> is undefined, but my bet is that it does nothing. >>>>> >>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>> difference, >>>>> but I don't have much confidence it will help. >>>>> >>>>> The potential similarity to the RMI tests is exemplified by >>>>> JDK-8049202 >>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>> registry as follows: >>>>> >>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>>> RMI registry port] in order to ensure that 1099 isn't in use by >>>>> something else already; >>>>> >>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>> >>>>> 3. Then it creates a new RMI registry on port 1099. >>>>> >>>>> In principle, this should succeed, yet it fails around 10% of the time >>>>> on some systems. The error is "port already in use". My best theory is >>>>> that even though the socket has just been closed by a user program, >>>>> the >>>>> kernel has to run the socket through some of the socket states such as >>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>> closed >>>>> and is available for reuse. If a program -- even the same one -- >>>>> attempts to open a socket on the same port before the socket has >>>>> reached >>>>> its final state, it will get an "already in use error". >>>>> >>>>> If this is true I don't believe that setting SO_REUSEADDR will work if >>>>> the socket is in one of these final states. (I remember reading this >>>>> somewhere but I'm not sure where at the moment. I can try to dig it up >>>>> if there is interest.) >>>>> >>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>> also >>>>> open to hearing about ways to deal with this problem. >>>>> >>>>> Could something similar be going on with this JMX test? >>>> >>>> Hm, this is exactly what happened with this test :( >>>> >>>> The problem is that the port is reported as available while it is still >>>> occupied and RMI registry attempts to start using that port. >>>> >>>> If setting SO_REUSEADDR does not work then the only solution would >>>> be to >>>> retry the test case when this exception occurs. >>> >>> Further investigation shows that the problem was rather the client >>> connecting to a socket being shut down. >>> >>> It sounds like setting SO_REUSEADDR to false should prevent this >>> failure. >>> >>> From the ServerSocket javadoc: >>> "When a TCP connection is closed the connection may remain in a timeout >>> state for a period of time after the connection is closed (typically >>> known as the TIME_WAIT state or 2MSL wait state). For applications using >>> a well known socket address or port it may not be possible to bind a >>> socket to the required SocketAddress if there is a connection in the >>> timeout state involving the socket address or port." >>> >>> It also turns out that the test does not close the server sockets >>> properly so there might be several sockets being opened or timed out >>> dangling around. >>> >>> I've updated the test so it is setting SO_REUSEADDR for all the new >>> ServerSockets instances + introduced the mechanism to run the test code >>> while properly cleaning up any allocated ports. >>> >>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>> >>> -JB- >>> >>>> >>>> -JB- >>>> >>>>> >>>>> s'marks >>>> >>> >> >> > -- 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 david.holmes at oracle.com Wed Jan 7 01:20:18 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Jan 2015 11:20:18 +1000 Subject: RFR 6720349: NotificationBufferDeadlockTest.java throw exception: java.lang.Exception: TEST FAILED: Deadlock detected In-Reply-To: <54ABDB65.2070109@oracle.com> References: <54AACE31.80402@oracle.com> <54AB4C7C.10208@oracle.com> <54ABC10A.6090707@oracle.com> <54ABD048.1040903@oracle.com> <54ABDB65.2070109@oracle.com> Message-ID: <54AC89D2.4060507@oracle.com> On 6/01/2015 10:56 PM, shanliang wrote: > David Holmes wrote: >> On 6/01/2015 9:03 PM, shanliang wrote: >>> David, >>> >>> Here is the new version, I have added the comments as you suggested, and >>> I replaced the variable "sources" with a synchronized list. >> >> Why did you do that ?? Vector is synchronized so it was fine for the job. > You are right! I have changed back to Vector: > http://cr.openjdk.java.net/~sjiang/JDK-8068418/02/ > > I forgot Vetor is synchronized, so long time not use it. :) Thanks - seems okay to me. David > Thanks, > Shanliang >> >> David >> >>> http://cr.openjdk.java.net/~sjiang/JDK-8068418/01/ >>> >>> Thanks for the review. >>> Shanliang >>> >>> David Holmes wrote: >>>> Hi Shanliang, >>>> >>>> On 6/01/2015 3:47 AM, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review this fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068418 >>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068418/00/ >>>>> >>>>> This must be a timing issue in the test, the test called: >>>>> t.join(5000L); to wait a thread's dying, I reproduced the bug by >>>>> insert at line 202: >>>>> try { >>>>> Thread.sleep(5100); >>>>> } catch (Exception ee) {} >>>>> to delay the t's dying. >>>>> >>>>> The fix is to replace: >>>>> t.join(5000L); >>>>> by: >>>>> t.join(); >>>>> >>>>> and replace: >>>>> Object.wait(timeout); >>>>> by >>>>> CountDownLatch.countDown(); >>>> >>>> Okay - you could have just done wait() but the switch to >>>> CountDownLatch is somewhat cleaner. >>>> >>>>> The test harness timeout will be used as the max waiting timeout. >>>> >>>> So the test will now never report that it thinks it has hit a >>>> deadlock, it will just timeout. But you added some extra printout so >>>> okay I guess - but I suggest adding a comment at the top (where @run >>>> etc are) saying that if test times out then deadlock is suspected. >>>> >>>> Minor nit: >>>> >>>> System.out.println("DeadlockTest-addNotificationListener waiting the >>>> XXX thread to die. >>>> >>>> should say "waiting for the XXX thread ..." >>>> >>>> Thanks, >>>> David >>>> >>>>> Shanliang >>> > From david.holmes at oracle.com Wed Jan 7 01:31:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Jan 2015 11:31:26 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54915894.3060101@oracle.com> References: <54915894.3060101@oracle.com> Message-ID: <54AC8C6E.5030702@oracle.com> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: > Please, review the following change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 > Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 > > This patch is a precursor for implementing > https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part > of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). > > Here, the code related to manipulating JVM flags is extracted to a > separate ManagedFlags class and the codebease is adjusted to use this > class. Not clear to me what this is addressing exactly - do we really need platform specific variants of "set flag" ?? All the new code seems incorrect: jint ManagedFlags::pd_set_flag(const char* flag_name, const char* flag_value, Flag::Flags origin, outputStream* out) { out->print_cr("flag '%s' cannot be changed", op->arg(0)); return JNI_ERR; }; op->arg(0) comes from the original code where op was an AttachOperation*. Here is should be using flag_name. David > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Jan 7 15:59:54 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 07 Jan 2015 16:59:54 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54AC8C6E.5030702@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> Message-ID: <54AD57FA.1070001@oracle.com> On 7.1.2015 02:31, David Holmes wrote: > On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >> Please, review the following change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >> >> This patch is a precursor for implementing >> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part >> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >> >> Here, the code related to manipulating JVM flags is extracted to a >> separate ManagedFlags class and the codebease is adjusted to use this >> class. > > Not clear to me what this is addressing exactly - do we really need > platform specific variants of "set flag" ?? It has just been moved from the corresponding attachListener_.cpp files. And it is 'pd_set_flag' what, I suppose, means "platform dependent"? > > All the new code seems incorrect: > > jint ManagedFlags::pd_set_flag(const char* flag_name, const char* > flag_value, Flag::Flags origin, outputStream* out) { > out->print_cr("flag '%s' cannot be changed", op->arg(0)); > return JNI_ERR; > }; > > op->arg(0) comes from the original code where op was an > AttachOperation*. Here is should be using flag_name. Correct. Slipped through and then replicated :/ Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 -JB- > > David > > >> Thanks, >> >> -JB- From jaroslav.bachorik at oracle.com Wed Jan 7 16:50:40 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 07 Jan 2015 17:50:40 +0100 Subject: RFR 8068600: Put java/lang/management/MemoryMXBean/LowMemoryTest.java on ProblemList Message-ID: <54AD63E0.5080401@oracle.com> Please, review this change to quarantine the intermittently failing test. Issue : https://bugs.openjdk.java.net/browse/JDK-8068600 Webrev: http://cr.openjdk.java.net/~jbachorik/8068600/webrev.00 Thanks, -JB- From jaroslav.bachorik at oracle.com Wed Jan 7 17:06:27 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 07 Jan 2015 18:06:27 +0100 Subject: RFR 8068600: Put java/lang/management/MemoryMXBean/LowMemoryTest.java on ProblemList In-Reply-To: <54AD63E0.5080401@oracle.com> References: <54AD63E0.5080401@oracle.com> Message-ID: <54AD6793.1030100@oracle.com> Please, disregard this review request. The review request for the proper fix of the original issue follows shortly. -JB- On 7.1.2015 17:50, Jaroslav Bachorik wrote: > Please, review this change to quarantine the intermittently failing test. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068600 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068600/webrev.00 > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Wed Jan 7 17:12:20 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 07 Jan 2015 18:12:20 +0100 Subject: RFR 8062450: Timeout in LowMemoryTest.java Message-ID: <54AD68F4.20709@oracle.com> Please, review the following test change Issue : https://bugs.openjdk.java.net/browse/JDK-8062450 Webrev: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.00 The test times out when "-XX:+ExplicitGCInvokesConcurrent" is specified. The test relies on the MemoryMXBean.gc() invocation returning only after the GC run has been completed. This is not true when "-XX:+ExplicitGCInvokesConcurrent" is set and the test timing is thrown off-balance resulting in deadlock. The proposed solution is to add an appropriate "@requires" JTREG stance to prevent running this test with incompatible settings. Thanks, -JB- From chris.plummer at oracle.com Wed Jan 7 23:29:22 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 07 Jan 2015 15:29:22 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy Message-ID: <54ADC152.6000706@oracle.com> Hi, Please review the following changes for the addition of the VM.class_hierarchy DCMD. Please read the bug first for some background information. Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 I expect there will be further restructuring or additional feature work. More discussion on that below. I'm not sure if that additional work will be done later with a separately bug filed or with this initial commit. That's one thing I want to work out with this review. Currently the bulk of the DCMD is implemented in heapInspection.cpp. The main purpose of this file is to implement the GC.class_stats and GC.class_histogram DCMDs. Both of them require walking the java heap to count live objects of each type, thus the name "heapInspection.cpp". This new VM.class_hierarchy DCMD does not require walking the heap, but is implemented in this file because it leverages the existing KlassInfoTable and related classes (KlassInfoEntry, KlassInfoBucket, and KlassClosure). KlassInfoTable makes it easy to build a database of all loaded classes, save additional info gathered for each class, iterate over them quickly, and also do quick lookups. This exactly what I needed for this DCMD, thus the reuse. There is some downside to this. For starters, heapInspection.cpp is not the proper place for a DCMD that has nothing to do with heap inspection. Also, KlassInfoEntry is being overloaded now to support 3 different DCMDs, as is KlassInfoTable. As a result each has a few fields and methods that are not used for all 3 DCMDs. Some subclassing might be in order here, but I'm not sure if it's worth it. Opinions welcomed. If I am going to refactor, I would prefer that be done as a next step so I'm not disturbing the existing DCMDs with this first implementation. I added some comments to code only used for GC.class_stats and GC.class_histogram. I did this when trying to figure them out so I could better understand how to implement VM.class_hierarchy. I can take them out if you think they are not appropriate for this commit. One other item I like to discuss is whether it is worth adding a class name argument to this DCMD. That would cause just the superclasses and subclasses of the named class to be printed. If you think that is useful, I think it can be added without too much trouble. At the moment not much testing has been done other than running the DCMD and looking at the output. I'll do more once it's clear the code has "settled". I would like to know if there are any existing tests for GC.class_stats and GC.class_histogram (there are none in the "test" directory). If so, possibly one could serve as the basis for a new test for VM.class_hierarchy. thanks, Chris From david.holmes at oracle.com Thu Jan 8 02:33:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Jan 2015 12:33:43 +1000 Subject: RFR 8062450: Timeout in LowMemoryTest.java In-Reply-To: <54AD68F4.20709@oracle.com> References: <54AD68F4.20709@oracle.com> Message-ID: <54ADEC87.3090407@oracle.com> On 8/01/2015 3:12 AM, Jaroslav Bachorik wrote: > Please, review the following test change > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062450 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.00 > > The test times out when "-XX:+ExplicitGCInvokesConcurrent" is specified. > The test relies on the MemoryMXBean.gc() invocation returning only after > the GC run has been completed. This is not true when > "-XX:+ExplicitGCInvokesConcurrent" is set and the test timing is thrown > off-balance resulting in deadlock. > > The proposed solution is to add an appropriate "@requires" JTREG stance > to prevent running this test with incompatible settings. Seems okay - though I'm wondering whether: @requires vm.opt.ExplicitGCInvokesConcurrent != "true" has the same affect? And do you also need to guard against ExplicitGCInvokesConcurrentAndUnloadsClasses ? David > Thanks, > > -JB- From david.holmes at oracle.com Thu Jan 8 02:45:43 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Jan 2015 12:45:43 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54AD57FA.1070001@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> Message-ID: <54ADEF57.5070804@oracle.com> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: > On 7.1.2015 02:31, David Holmes wrote: >> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>> Please, review the following change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>> >>> This patch is a precursor for implementing >>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part >>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>> >>> Here, the code related to manipulating JVM flags is extracted to a >>> separate ManagedFlags class and the codebease is adjusted to use this >>> class. >> >> Not clear to me what this is addressing exactly - do we really need >> platform specific variants of "set flag" ?? > > It has just been moved from the corresponding attachListener_.cpp > files. And it is 'pd_set_flag' what, I suppose, means "platform dependent"? Yes it does and it mostly made sense inside the already pd attachListener implementations, but it isn't obvious to me that it makes sense in the ManagedFlag context. It is the choice about whether the flag can be changed that is "pd" not the actual setting and those choices are inherent to the attachListener mechanism they are not inherent to ManagedFlags - so this refactoring seems wrong to me. What exactly is ManagedFlag supposed to represent? >> >> All the new code seems incorrect: >> >> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >> flag_value, Flag::Flags origin, outputStream* out) { >> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >> return JNI_ERR; >> }; >> >> op->arg(0) comes from the original code where op was an >> AttachOperation*. Here is should be using flag_name. > > Correct. Slipped through and then replicated :/ And obviously never compiled. RFRs should be for tested code. David ----- > Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 > > -JB- > >> >> David >> >> >>> Thanks, >>> >>> -JB- > From yekaterina.kantserova at oracle.com Thu Jan 8 08:17:17 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 08 Jan 2015 09:17:17 +0100 Subject: RFR(XXS): 8065226: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be quarantined Message-ID: <54AE3D0D.1020008@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8065226 webrev: http://cr.openjdk.java.net/~ykantser/8065226/webrev.00 Thanks, Katja From mikael.auno at oracle.com Thu Jan 8 08:49:21 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 08 Jan 2015 09:49:21 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54ADC152.6000706@oracle.com> References: <54ADC152.6000706@oracle.com> Message-ID: <54AE4491.2020700@oracle.com> On 2015-01-08 00:29, Chris Plummer wrote: > At the moment not much testing has been done other than running the DCMD > and looking at the output. I'll do more once it's clear the code has > "settled". I would like to know if there are any existing tests for > GC.class_stats and GC.class_histogram (there are none in the "test" > directory). If so, possibly one could serve as the basis for a new test > for VM.class_hierarchy. Unfortunately, there are no open tests either of them as of yet. There are, however, internal ones. I can give you the details offline. Mikael From staffan.larsen at oracle.com Thu Jan 8 09:09:49 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 8 Jan 2015 10:09:49 +0100 Subject: RFR(XXS): 8065226: sun/jvmstat/monitor/MonitoredVm/CR6672135.java should be quarantined In-Reply-To: <54AE3D0D.1020008@oracle.com> References: <54AE3D0D.1020008@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 8 jan 2015, at 09:17, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8065226 > webrev: http://cr.openjdk.java.net/~ykantser/8065226/webrev.00 > > Thanks, > Katja From jaroslav.bachorik at oracle.com Thu Jan 8 09:19:11 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 10:19:11 +0100 Subject: RFR 8062450: Timeout in LowMemoryTest.java In-Reply-To: <54ADEC87.3090407@oracle.com> References: <54AD68F4.20709@oracle.com> <54ADEC87.3090407@oracle.com> Message-ID: <54AE4B8F.6000209@oracle.com> On 8.1.2015 03:33, David Holmes wrote: > On 8/01/2015 3:12 AM, Jaroslav Bachorik wrote: >> Please, review the following test change >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062450 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.00 >> >> The test times out when "-XX:+ExplicitGCInvokesConcurrent" is specified. >> The test relies on the MemoryMXBean.gc() invocation returning only after >> the GC run has been completed. This is not true when >> "-XX:+ExplicitGCInvokesConcurrent" is set and the test timing is thrown >> off-balance resulting in deadlock. >> >> The proposed solution is to add an appropriate "@requires" JTREG stance >> to prevent running this test with incompatible settings. > > Seems okay - though I'm wondering whether: > > @requires vm.opt.ExplicitGCInvokesConcurrent != "true" > > has the same affect? Seems to have the same effect - I tried running the test with "-XX:+ExplicitGCInvokesConcurrent", "-XX:-ExplicitGCInvokesConcurrent" and without this flag all together and the test was properly ignored only when "-XX:+ExplicitGCInvokesConcurrent" is used. > > And do you also need to guard against > ExplicitGCInvokesConcurrentAndUnloadsClasses ? Didn't see this flag used in testing but it would be wise to guard against it as well, thanks. I would throw in DisableExplicitGC too. -JB- > > David > >> Thanks, >> >> -JB- From jaroslav.bachorik at oracle.com Thu Jan 8 09:22:22 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 10:22:22 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54ADEF57.5070804@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> Message-ID: <54AE4C4E.2000506@oracle.com> On 8.1.2015 03:45, David Holmes wrote: > On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >> On 7.1.2015 02:31, David Holmes wrote: >>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>> Please, review the following change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>> >>>> This patch is a precursor for implementing >>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a part >>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>> >>>> Here, the code related to manipulating JVM flags is extracted to a >>>> separate ManagedFlags class and the codebease is adjusted to use this >>>> class. >>> >>> Not clear to me what this is addressing exactly - do we really need >>> platform specific variants of "set flag" ?? >> >> It has just been moved from the corresponding attachListener_.cpp >> files. And it is 'pd_set_flag' what, I suppose, means "platform >> dependent"? > > Yes it does and it mostly made sense inside the already pd > attachListener implementations, but it isn't obvious to me that it makes > sense in the ManagedFlag context. It is the choice about whether the > flag can be changed that is "pd" not the actual setting and those > choices are inherent to the attachListener mechanism they are not Why would the ability to set Solaris specific flags via DTrace be specific to the attachListener mechanism? Also, AFAICS here it is the mechanism of setting the flag which is "pd" and not the choice (DTrace::* vs CommandLineFlags::*) > inherent to ManagedFlags - so this refactoring seems wrong to me. What > exactly is ManagedFlag supposed to represent? A shared functionality between attachListener.cpp, management.cpp and the new diagnostic commands to be introduced later (as mentioned in the original synopsis of this RFR). It did seem preferable over just copying the implementation over to a few more places. > >>> >>> All the new code seems incorrect: >>> >>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>> flag_value, Flag::Flags origin, outputStream* out) { >>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>> return JNI_ERR; >>> }; >>> >>> op->arg(0) comes from the original code where op was an >>> AttachOperation*. Here is should be using flag_name. >> >> Correct. Slipped through and then replicated :/ > > And obviously never compiled. RFRs should be for tested code. Yes, one should run always "make clean" first, just in case. I should remember this well to prevent further embarrassment. -JB- > > David > ----- > >> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >> >> -JB- >> >>> >>> David >>> >>> >>>> Thanks, >>>> >>>> -JB- >> From mattias.tobiasson at oracle.com Thu Jan 8 10:04:17 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Thu, 08 Jan 2015 11:04:17 +0100 Subject: RFR(XXS): 8068584: Compiler attach tests should be quarantined Message-ID: <54AE5621.5010300@oracle.com> Hi, Could I please have a review of this bug quarantine. bug: https://bugs.openjdk.java.net/browse/JDK-8068584 webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/ Thanks, Mattias From mikael.auno at oracle.com Thu Jan 8 10:21:39 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Thu, 08 Jan 2015 11:21:39 +0100 Subject: RFR(XXS): 8068584: Compiler attach tests should be quarantined In-Reply-To: <54AE5621.5010300@oracle.com> References: <54AE5621.5010300@oracle.com> Message-ID: <54AE5A33.6040206@oracle.com> On 2015-01-08 11:04, Mattias Tobiasson wrote: > Hi, > Could I please have a review of this bug quarantine. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068584 > webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/ > > Thanks, > Mattias > Mattias, In the two **/Launcher.java tests, you must place @ignore after the @library line, otherwise there will be a "Parse Exception: `@library' must appear before first `@run'". (The error message is, to say the least, a bit unintuitive until you figure out that "@ignore" is just an alias for "@run ignore".) Mikael From stefan.karlsson at oracle.com Thu Jan 8 10:50:33 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 08 Jan 2015 11:50:33 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54ADC152.6000706@oracle.com> References: <54ADC152.6000706@oracle.com> Message-ID: <54AE60F9.6000000@oracle.com> Hi Chris, On 2015-01-08 00:29, Chris Plummer wrote: > Hi, > > Please review the following changes for the addition of the > VM.class_hierarchy DCMD. Please read the bug first for some background > information. > > Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 This looks like a nice feature. I think your suggestion about supporting a class name argument as the root of the hierarchy would be a nice addition. Some comments: Why do you need / use the super_stack? To me it seems like you could simplify the could if you get rid of the super_stack and walk the Klass::super() chain instead. Why did you add this side-effect to KlassInfoHisto::print_class_state?: - super_index = super_e->index(); + e->set_super_index(super_e->index()); AFAICT, you are not using KlassInfoHisto::print_class_stats to implement the VM.class_hierarchy DCMD, right? Or am I missing something in your patch? A side-note, if it were not for the AnonymousClasses (created by Unsafe_DefineAnonymousClass), then this could have be implemented with less resources by just walking the Klass::subclass() and Klass::next_sibling() links. Which means that you wouldn't have to use any of the classes or functionality in heapInspection.hpp/cpp. But the anonymous classes is unfortunately not present in the subclass/next_sibling hierarchy. And some style comments: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/services/diagnosticCommand.cpp.frames.html Maybe it would be nice to move: 66 #if INCLUDE_SERVICES 67 DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); 68 #endif into the already existing INCLUDE_SERVICE block: 55 #if INCLUDE_SERVICES // Heap dumping/inspection supported 56 DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(DCmd_Source_Internal | DCmd_Source_AttachAPI, true, false)); 57 DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); 58 DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl(full_export, true, false)); 59 #endif // INCLUDE_SERVICES http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/memory/heapInspection.hpp.frames.html I would prefer if you moved the following implementation to the cpp file, so that we can keep our includes in our hpp files to a minimal. That helps lowering our include complexity. 218 inline void KlassInfoEntry::add_subclass(KlassInfoEntry* cie) { 219 if (_subclasses == NULL) { 220 _subclasses = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(4, true); 221 } 222 _subclasses->append(cie); 223 } 224 225 inline KlassInfoEntry::~KlassInfoEntry() { 226 if (_subclasses != NULL) { 227 delete _subclasses; 228 } 229 } http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/memory/heapInspection.cpp.frames.html Could you move the local variables to where they are used: 316 void KlassHierarchy::print_class_hierarchy(outputStream* st) { 317 ResourceMark rm; 318 int i; 319 Stack class_stack; 320 Stack super_stack; 321 GrowableArray elements; 322 For example, 'int i' into the for statements: 336 // Set the index for each class 337 for(i=0; i < elements.length(); i++) { 338 elements.at(i)->set_index(i+1); 339 } Could you add spaces around the operators (= and +): 337 for(i=0; i < elements.length(); i++) { 338 elements.at(i)->set_index(i+1); Some of your new comments are not capitalized and some lack a period. Example: 399 // print indentation with proper indicators of superclass. 454 // Add the stats for this class to the overall totals Thanks, StefanK > > I expect there will be further restructuring or additional feature > work. More discussion on that below. I'm not sure if that additional > work will be done later with a separately bug filed or with this > initial commit. That's one thing I want to work out with this review. > > Currently the bulk of the DCMD is implemented in heapInspection.cpp. > The main purpose of this file is to implement the GC.class_stats and > GC.class_histogram DCMDs. Both of them require walking the java heap > to count live objects of each type, thus the name > "heapInspection.cpp". This new VM.class_hierarchy DCMD does not > require walking the heap, but is implemented in this file because it > leverages the existing KlassInfoTable and related classes > (KlassInfoEntry, KlassInfoBucket, and KlassClosure). > > KlassInfoTable makes it easy to build a database of all loaded > classes, save additional info gathered for each class, iterate over > them quickly, and also do quick lookups. This exactly what I needed > for this DCMD, thus the reuse. There is some downside to this. For > starters, heapInspection.cpp is not the proper place for a DCMD that > has nothing to do with heap inspection. Also, KlassInfoEntry is being > overloaded now to support 3 different DCMDs, as is KlassInfoTable. As > a result each has a few fields and methods that are not used for all 3 > DCMDs. Some subclassing might be in order here, but I'm not sure if > it's worth it. Opinions welcomed. If I am going to refactor, I would > prefer that be done as a next step so I'm not disturbing the existing > DCMDs with this first implementation. > > I added some comments to code only used for GC.class_stats and > GC.class_histogram. I did this when trying to figure them out so I > could better understand how to implement VM.class_hierarchy. I can > take them out if you think they are not appropriate for this commit. > > One other item I like to discuss is whether it is worth adding a class > name argument to this DCMD. That would cause just the superclasses and > subclasses of the named class to be printed. If you think that is > useful, I think it can be added without too much trouble. > > At the moment not much testing has been done other than running the > DCMD and looking at the output. I'll do more once it's clear the code > has "settled". I would like to know if there are any existing tests > for GC.class_stats and GC.class_histogram (there are none in the > "test" directory). If so, possibly one could serve as the basis for a > new test for VM.class_hierarchy. > > thanks, > > Chris From david.holmes at oracle.com Thu Jan 8 11:12:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Jan 2015 21:12:47 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54AE4C4E.2000506@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> Message-ID: <54AE662F.7060208@oracle.com> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: > On 8.1.2015 03:45, David Holmes wrote: >> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>> On 7.1.2015 02:31, David Holmes wrote: >>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following change. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>> >>>>> This patch is a precursor for implementing >>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>> part >>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>> >>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>> separate ManagedFlags class and the codebease is adjusted to use this >>>>> class. >>>> >>>> Not clear to me what this is addressing exactly - do we really need >>>> platform specific variants of "set flag" ?? >>> >>> It has just been moved from the corresponding attachListener_.cpp >>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>> dependent"? >> >> Yes it does and it mostly made sense inside the already pd >> attachListener implementations, but it isn't obvious to me that it makes >> sense in the ManagedFlag context. It is the choice about whether the >> flag can be changed that is "pd" not the actual setting and those >> choices are inherent to the attachListener mechanism they are not > > Why would the ability to set Solaris specific flags via DTrace be > specific to the attachListener mechanism? Also, AFAICS here it is the > mechanism of setting the flag which is "pd" and not the choice > (DTrace::* vs CommandLineFlags::*) The attachListener allows for manipulating VM flags if the attach mechanism is used. In the Solaris case it turns on some DTrace flags. The attach mechanism factors that into a pd_set_flags method that is called for a given AttachOperation and so allows per platform behaviour. But this is all part of the attach mechanism it isn't part of some general flag management process. >> inherent to ManagedFlags - so this refactoring seems wrong to me. What >> exactly is ManagedFlag supposed to represent? > > A shared functionality between attachListener.cpp, management.cpp and > the new diagnostic commands to be introduced later (as mentioned in the > original synopsis of this RFR). It did seem preferable over just copying > the implementation over to a few more places. I need to see a clearer bigger picture. What I currently see doesn't look right to me - attach mechanism functionality doesn't belong in a general purpose ManagedFlags abstraction. David ----- >> >>>> >>>> All the new code seems incorrect: >>>> >>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>> flag_value, Flag::Flags origin, outputStream* out) { >>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>> return JNI_ERR; >>>> }; >>>> >>>> op->arg(0) comes from the original code where op was an >>>> AttachOperation*. Here is should be using flag_name. >>> >>> Correct. Slipped through and then replicated :/ >> >> And obviously never compiled. RFRs should be for tested code. > > Yes, one should run always "make clean" first, just in case. I should > remember this well to prevent further embarrassment. > > -JB- > >> >> David >> ----- >> >>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>> >>> -JB- >>> >>>> >>>> David >>>> >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From mattias.tobiasson at oracle.com Thu Jan 8 12:45:05 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Thu, 08 Jan 2015 13:45:05 +0100 Subject: RFR(XXS): 8068584: Compiler attach tests should be quarantined In-Reply-To: <54AE5A33.6040206@oracle.com> References: <54AE5621.5010300@oracle.com> <54AE5A33.6040206@oracle.com> Message-ID: <54AE7BD1.4010907@oracle.com> Thanks for the explanation. I have moved the @ignore tags to directly before the first @run tag. webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.01/ Mattias On 01/08/2015 11:21 AM, Mikael Auno wrote: > On 2015-01-08 11:04, Mattias Tobiasson wrote: >> Hi, >> Could I please have a review of this bug quarantine. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068584 >> webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/ >> >> Thanks, >> Mattias >> > Mattias, > > In the two **/Launcher.java tests, you must place @ignore after the > @library line, otherwise there will be a "Parse Exception: `@library' > must appear before first `@run'". (The error message is, to say the > least, a bit unintuitive until you figure out that "@ignore" is just an > alias for "@run ignore".) > > Mikael From jaroslav.bachorik at oracle.com Thu Jan 8 13:24:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 14:24:47 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54AE662F.7060208@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> Message-ID: <54AE851F.3000905@oracle.com> On 8.1.2015 12:12, David Holmes wrote: > On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >> On 8.1.2015 03:45, David Holmes wrote: >>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>> On 7.1.2015 02:31, David Holmes wrote: >>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>> Please, review the following change. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>> >>>>>> This patch is a precursor for implementing >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>> part >>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>> >>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>> separate ManagedFlags class and the codebease is adjusted to use this >>>>>> class. >>>>> >>>>> Not clear to me what this is addressing exactly - do we really need >>>>> platform specific variants of "set flag" ?? >>>> >>>> It has just been moved from the corresponding attachListener_.cpp >>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>> dependent"? >>> >>> Yes it does and it mostly made sense inside the already pd >>> attachListener implementations, but it isn't obvious to me that it makes >>> sense in the ManagedFlag context. It is the choice about whether the >>> flag can be changed that is "pd" not the actual setting and those >>> choices are inherent to the attachListener mechanism they are not >> >> Why would the ability to set Solaris specific flags via DTrace be >> specific to the attachListener mechanism? Also, AFAICS here it is the >> mechanism of setting the flag which is "pd" and not the choice >> (DTrace::* vs CommandLineFlags::*) > > The attachListener allows for manipulating VM flags if the attach > mechanism is used. In the Solaris case it turns on some DTrace flags. > The attach mechanism factors that into a pd_set_flags method that is > called for a given AttachOperation and so allows per platform behaviour. > But this is all part of the attach mechanism it isn't part of some > general flag management process. I think I see the problem. Sorry it took me so long. But, why the DTrace flags are only allowed to be set via the attachListener? Can we allow their manipulation via com.sun.Flag? Or they need to stay restricted to the attach mechanism only for whatever reason? > >>> inherent to ManagedFlags - so this refactoring seems wrong to me. What >>> exactly is ManagedFlag supposed to represent? >> >> A shared functionality between attachListener.cpp, management.cpp and >> the new diagnostic commands to be introduced later (as mentioned in the >> original synopsis of this RFR). It did seem preferable over just copying >> the implementation over to a few more places. > > I need to see a clearer bigger picture. What I currently see doesn't > look right to me - attach mechanism functionality doesn't belong in a > general purpose ManagedFlags abstraction. Bigger picture is that introducing yet another copy of the flag management code for the purpose of adding the "VM.set_flag" diagnostic command did seem unwieldy. The purpose of this refactoring was to get the shared parts to one place. -JB- > > David > ----- > >>> >>>>> >>>>> All the new code seems incorrect: >>>>> >>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>> return JNI_ERR; >>>>> }; >>>>> >>>>> op->arg(0) comes from the original code where op was an >>>>> AttachOperation*. Here is should be using flag_name. >>>> >>>> Correct. Slipped through and then replicated :/ >>> >>> And obviously never compiled. RFRs should be for tested code. >> >> Yes, one should run always "make clean" first, just in case. I should >> remember this well to prevent further embarrassment. >> >> -JB- >> >>> >>> David >>> ----- >>> >>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>> >> From shanliang.jiang at oracle.com Thu Jan 8 13:59:59 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 08 Jan 2015 14:59:59 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined Message-ID: <54AE8D5F.5070409@oracle.com> Hi, Please review this simple fix: bug: https://bugs.openjdk.java.net/browse/JDK-8068591 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ Thanks, Shanliang From jaroslav.bachorik at oracle.com Thu Jan 8 14:30:05 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 15:30:05 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined In-Reply-To: <54AE8D5F.5070409@oracle.com> References: <54AE8D5F.5070409@oracle.com> Message-ID: <54AE946D.10002@oracle.com> Hi Shanliang, On 8.1.2015 14:59, shanliang wrote: > Hi, > > Please review this simple fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8068591 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ The entry is missing the label (eg. "generic-all") -JB- > > Thanks, > Shanliang From shanliang.jiang at oracle.com Thu Jan 8 14:35:46 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 08 Jan 2015 15:35:46 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined In-Reply-To: <54AE946D.10002@oracle.com> References: <54AE8D5F.5070409@oracle.com> <54AE946D.10002@oracle.com> Message-ID: <54AE95C2.1000004@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > > On 8.1.2015 14:59, shanliang wrote: >> Hi, >> >> Please review this simple fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068591 >> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ > > The entry is missing the label (eg. "generic-all") Oops! http://cr.openjdk.java.net/~sjiang/JDK-8068591/01/ Thanks, Shanliang > > -JB- > >> >> Thanks, >> Shanliang > From karen.kinnear at oracle.com Thu Jan 8 16:07:28 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 8 Jan 2015 11:07:28 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54ADC152.6000706@oracle.com> References: <54ADC152.6000706@oracle.com> Message-ID: <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> Chris, Thank you for doing this. I had a couple of questions/comments. I like your idea of being able to start with a specific class to show all subclasses of. I think the way I read the code this shows the superclass hierarchy, not the superinterfaces. With the addition of default methods in interfaces, I think we have increased the value in seeing superinterfaces. So what I personally would find useful would be to be able to start with a specific class and find the superclasses and superinterfaces of that class - for the debugging I do, I usually am trying to look up and need both sets of information. Today if you run -XX:+TraceDefaultMethods there is one sample way to display all the supertypes of a single type, all the way up. I don't know the best way to make that consistent with the current output approach, e.g. using the |- syntax. e.g. Class java.util.Arrays$ArrayList requires default method processing java/util/Arrays$ArrayList java/util/AbstractList java/util/AbstractCollection java/lang/Object java/util/Collection java/lang/Object java/lang/Iterable java/lang/Object java/util/List java/lang/Object java/util/Collection java/lang/Object java/lang/Iterable java/lang/Object java/util/RandomAccess java/lang/Object java/io/Serializable java/lang/Object Do you think there could be value to others in the ability to walk up the hierarchy as well as to see superclasses and superinterfaces at least from that perspective? Is there value in printing the defining class loader for each class - maybe optionally? If so, I'm wondering if there might be value in future for the jigsaw project adding the module for each class - maybe optionally as well? Love opinions on that - especially from the serviceability folks thanks, Karen On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: > Hi, > > Please review the following changes for the addition of the VM.class_hierarchy DCMD. Please read the bug first for some background information. > > Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 > > I expect there will be further restructuring or additional feature work. More discussion on that below. I'm not sure if that additional work will be done later with a separately bug filed or with this initial commit. That's one thing I want to work out with this review. > > Currently the bulk of the DCMD is implemented in heapInspection.cpp. The main purpose of this file is to implement the GC.class_stats and GC.class_histogram DCMDs. Both of them require walking the java heap to count live objects of each type, thus the name "heapInspection.cpp". This new VM.class_hierarchy DCMD does not require walking the heap, but is implemented in this file because it leverages the existing KlassInfoTable and related classes (KlassInfoEntry, KlassInfoBucket, and KlassClosure). > > KlassInfoTable makes it easy to build a database of all loaded classes, save additional info gathered for each class, iterate over them quickly, and also do quick lookups. This exactly what I needed for this DCMD, thus the reuse. There is some downside to this. For starters, heapInspection.cpp is not the proper place for a DCMD that has nothing to do with heap inspection. Also, KlassInfoEntry is being overloaded now to support 3 different DCMDs, as is KlassInfoTable. As a result each has a few fields and methods that are not used for all 3 DCMDs. Some subclassing might be in order here, but I'm not sure if it's worth it. Opinions welcomed. If I am going to refactor, I would prefer that be done as a next step so I'm not disturbing the existing DCMDs with this first implementation. > > I added some comments to code only used for GC.class_stats and GC.class_histogram. I did this when trying to figure them out so I could better understand how to implement VM.class_hierarchy. I can take them out if you think they are not appropriate for this commit. > > One other item I like to discuss is whether it is worth adding a class name argument to this DCMD. That would cause just the superclasses and subclasses of the named class to be printed. If you think that is useful, I think it can be added without too much trouble. > > At the moment not much testing has been done other than running the DCMD and looking at the output. I'll do more once it's clear the code has "settled". I would like to know if there are any existing tests for GC.class_stats and GC.class_histogram (there are none in the "test" directory). If so, possibly one could serve as the basis for a new test for VM.class_hierarchy. > > thanks, > > Chris From jaroslav.bachorik at oracle.com Thu Jan 8 16:20:10 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 17:20:10 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined In-Reply-To: <54AE95C2.1000004@oracle.com> References: <54AE8D5F.5070409@oracle.com> <54AE946D.10002@oracle.com> <54AE95C2.1000004@oracle.com> Message-ID: <54AEAE3A.6040709@oracle.com> On 8.1.2015 15:35, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> >> On 8.1.2015 14:59, shanliang wrote: >>> Hi, >>> >>> Please review this simple fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068591 >>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ >> >> The entry is missing the label (eg. "generic-all") > Oops! > http://cr.openjdk.java.net/~sjiang/JDK-8068591/01/ Hm, shouldn't javax/management/remote/mandatory/connection/ReconnectTest.java be quarantined too? -JB- > > Thanks, > Shanliang >> >> -JB- >> >>> >>> Thanks, >>> Shanliang >> > From shanliang.jiang at oracle.com Thu Jan 8 16:37:13 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 08 Jan 2015 17:37:13 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined In-Reply-To: <54AEAE3A.6040709@oracle.com> References: <54AE8D5F.5070409@oracle.com> <54AE946D.10002@oracle.com> <54AE95C2.1000004@oracle.com> <54AEAE3A.6040709@oracle.com> Message-ID: <54AEB239.4020005@oracle.com> Jaroslav Bachorik wrote: > On 8.1.2015 15:35, shanliang wrote: >> Jaroslav Bachorik wrote: >>> Hi Shanliang, >>> >>> On 8.1.2015 14:59, shanliang wrote: >>>> Hi, >>>> >>>> Please review this simple fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068591 >>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ >>> >>> The entry is missing the label (eg. "generic-all") >> Oops! >> http://cr.openjdk.java.net/~sjiang/JDK-8068591/01/ > > Hm, shouldn't > javax/management/remote/mandatory/connection/ReconnectTest.java be > quarantined too? Maybe, but better to have a new sub-bug of JDK-8042215 to quarantine ReconnectTest.java? Shanliang > > -JB- > >> >> Thanks, >> Shanliang >>> >>> -JB- >>> >>>> >>>> Thanks, >>>> Shanliang >>> >> > From jaroslav.bachorik at oracle.com Thu Jan 8 16:43:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 08 Jan 2015 17:43:47 +0100 Subject: RFR 8068591: javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java should be quarantined In-Reply-To: <54AEB239.4020005@oracle.com> References: <54AE8D5F.5070409@oracle.com> <54AE946D.10002@oracle.com> <54AE95C2.1000004@oracle.com> <54AEAE3A.6040709@oracle.com> <54AEB239.4020005@oracle.com> Message-ID: <54AEB3C3.7070900@oracle.com> On 8.1.2015 17:37, shanliang wrote: > Jaroslav Bachorik wrote: >> On 8.1.2015 15:35, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> Hi Shanliang, >>>> >>>> On 8.1.2015 14:59, shanliang wrote: >>>>> Hi, >>>>> >>>>> Please review this simple fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8068591 >>>>> webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068591/00/ >>>> >>>> The entry is missing the label (eg. "generic-all") >>> Oops! >>> http://cr.openjdk.java.net/~sjiang/JDK-8068591/01/ >> >> Hm, shouldn't >> javax/management/remote/mandatory/connection/ReconnectTest.java be >> quarantined too? > Maybe, but better to have a new sub-bug of JDK-8042215 to quarantine > ReconnectTest.java? Well, it's up to you. But the error report is originally for ReconnectTest nd it already mixes those two failures together anyway so you could spare one round of one-liner review process. If you decide to to squeeze in the javax/management/remote/mandatory/connection/ReconnectTest.java exclusion just reply to this thread with the updated webrev. Otherwise this change is good to go. -JB- > > Shanliang >> >> -JB- >> >>> >>> Thanks, >>> Shanliang >>>> >>>> -JB- >>>> >>>>> >>>>> Thanks, >>>>> Shanliang >>>> >>> >> > From chris.plummer at oracle.com Thu Jan 8 19:15:10 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 08 Jan 2015 11:15:10 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54AE60F9.6000000@oracle.com> References: <54ADC152.6000706@oracle.com> <54AE60F9.6000000@oracle.com> Message-ID: <54AED73E.1060905@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Jan 8 21:29:26 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 08 Jan 2015 13:29:26 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> Message-ID: <54AEF6B6.6020404@oracle.com> Hi Karen, Comments inline. On 1/8/15 8:07 AM, Karen Kinnear wrote: > Chris, > > Thank you for doing this. I had a couple of questions/comments. > > I like your idea of being able to start with a specific class to show all subclasses of. Ok. I'll add that. > > I think the way I read the code this shows the superclass hierarchy, not the superinterfaces. With the addition > of default methods in interfaces, I think we have increased the value in seeing superinterfaces. It does include interfaces in the output, but not as part of any class hierarchy. Interfaces are just shown as regular classes that inherit from Object. This is the case if one interface extends another, I suppose because "extends" is just interpreted as "implements" in this case. > > So what I personally would find useful would be to be able to start with a specific class and > find the superclasses and superinterfaces of that class - for the debugging I do, I usually am > trying to look up and need both sets of information. Today if you run -XX:+TraceDefaultMethods > there is one sample way to display all the supertypes of a single type, all the way up. I don't know the > best way to make that consistent with the current output approach, e.g. using the |- syntax. > > e.g. > Class java.util.Arrays$ArrayList requires default method processing > java/util/Arrays$ArrayList > java/util/AbstractList > java/util/AbstractCollection > java/lang/Object > java/util/Collection > java/lang/Object > java/lang/Iterable > java/lang/Object > java/util/List > java/lang/Object > java/util/Collection > java/lang/Object > java/lang/Iterable > java/lang/Object > java/util/RandomAccess > java/lang/Object > java/io/Serializable > java/lang/Object > > Do you think there could be value to others in the ability to walk up the hierarchy as well as to > see superclasses and superinterfaces at least from that perspective? This is a inverted from how my dcmd prints the hierarchy, plus also includes interfaces. Inverting the hierarchy means a class is listed with every subclass of the class, which I don't think is desirable. Including interfaces has the same issue, but introduces a new issue even when not inverting the hierarchy. The same interface can be in more than one location in the hierarchy, so there is no avoiding printing it more than once, so we need to decide how to best include interfaces in the output. The could just be a simple list right after the class that implements them: java.lang.Object | ... |--MyBaseClass | | implements -> MyInterface1 | | implements -> MyInterface2 | |--MySubClass | implements -> MyInterface1 | implements -> MyInterface2 | ... |--MyInterface1 |--MyInterface2 The "implements" lines could be optional. I know cvm would distinguish between interfaces the Class declared it implemented, and those it inherited from the interfaces it declared it implemented. This was necessary for reflection, and I think also to properly build up interfaces tables. I assume hotspot does something similar. Is there any need for this information to be conveyed in the above output, or just list out every interface implemented, and not worry about how the class acquired it. > Is there value in printing the defining class loader for each class - maybe optionally? This is already available with GC.class_stats, although not in the default output. I suppose the reality is that it might be better handled by this DCMD. The main puprose of GC.class_stats is to print statistics (counts and sizes), so printing the ClassLoader name there is probably not appropriate, but then it's not really appropriate for VM.class_hierarchy either. I'm not sure how best to handle this. One or both DCMDs possibly should be re-purposed and more clearly define what type of data it displays. > If so, I'm wondering if there might be value in future for the jigsaw project adding the module for each class - maybe optionally as well? This relates to my above statement. We need to figure out what type of data is useful, and which dcmds should handle them. > Love opinions on that - especially from the serviceability folks > > thanks, > Karen Thanks for the input. Chris > > > On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: > >> Hi, >> >> Please review the following changes for the addition of the VM.class_hierarchy DCMD. Please read the bug first for some background information. >> >> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >> >> I expect there will be further restructuring or additional feature work. More discussion on that below. I'm not sure if that additional work will be done later with a separately bug filed or with this initial commit. That's one thing I want to work out with this review. >> >> Currently the bulk of the DCMD is implemented in heapInspection.cpp. The main purpose of this file is to implement the GC.class_stats and GC.class_histogram DCMDs. Both of them require walking the java heap to count live objects of each type, thus the name "heapInspection.cpp". This new VM.class_hierarchy DCMD does not require walking the heap, but is implemented in this file because it leverages the existing KlassInfoTable and related classes (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >> >> KlassInfoTable makes it easy to build a database of all loaded classes, save additional info gathered for each class, iterate over them quickly, and also do quick lookups. This exactly what I needed for this DCMD, thus the reuse. There is some downside to this. For starters, heapInspection.cpp is not the proper place for a DCMD that has nothing to do with heap inspection. Also, KlassInfoEntry is being overloaded now to support 3 different DCMDs, as is KlassInfoTable. As a result each has a few fields and methods that are not used for all 3 DCMDs. Some subclassing might be in order here, but I'm not sure if it's worth it. Opinions welcomed. If I am going to refactor, I would prefer that be done as a next step so I'm not disturbing the existing DCMDs with this first implementation. >> >> I added some comments to code only used for GC.class_stats and GC.class_histogram. I did this when trying to figure them out so I could better understand how to implement VM.class_hierarchy. I can take them out if you think they are not appropriate for this commit. >> >> One other item I like to discuss is whether it is worth adding a class name argument to this DCMD. That would cause just the superclasses and subclasses of the named class to be printed. If you think that is useful, I think it can be added without too much trouble. >> >> At the moment not much testing has been done other than running the DCMD and looking at the output. I'll do more once it's clear the code has "settled". I would like to know if there are any existing tests for GC.class_stats and GC.class_histogram (there are none in the "test" directory). If so, possibly one could serve as the basis for a new test for VM.class_hierarchy. >> >> thanks, >> >> Chris From stuart.marks at oracle.com Fri Jan 9 02:50:43 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 08 Jan 2015 18:50:43 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54AC5B14.1020001@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> Message-ID: <54AF4203.6040000@oracle.com> Hi Jaroslav, I'm distant enough from this code that I don't think I'm in a position to say "no you can't check this in," and I'm mindful of the fact that this bug is a high priority and you want to get a fix in. But having said that I think there's a surprising amount of complexity here for what it does. Implementing a retry-on-BindException policy seems to be fairly sensible, since I assume it would be fairly invasive to modify the code in the JVMs being forked to use an ephemeral port and send that information back to the test. My conjecture is however that the open/close/reopen logic is the primary cause of the BindExceptions that occur. If you're going to retry on BindException, you might as well choose a random port number instead of doing the open/close to get a port number from the system. The range that Dmitry suggests is reasonable, though I note that the actual ephemeral port range used by the kernel will differ from OS to OS and even from system to system. I don't know if that's really significant though. If you end up choosing a port outside the ephemeral range for some system, does it really matter? If you do decide to have PortAllocator open and close a ServerSocket (in order to find a previously unused port) I'd suggest removing the logic that leaves the socket open until the first call to get(). That logic reduces the possibility that some other process will open the socket after the close but before the reopen. In my experience that's not what's causing the BindExceptions. It could still happen, though, but you're protected by the retry logic anyway. Leaving the socket open longer actually hurts, I think, because it increases the chance that the kernel won't have cleaned up the port by the time the test wants to reopen it. If you change PortAllocator to close the socket immediately, you can get rid of the need to call release() in a finally-block of the caller. You could also change the type of the functional interface to be int[] -> void since the PortAllocator doesn't hold onto any resources that need to be cleaned up. It just calls the execute() method and passes an array of n port numbers. It's probably necessary to have the socket close() call in a retry loop. The socket is always closed immediately from the user process point of view, so isClosed() will always return true immediately after the close() call returns. You can verify this easily by looking in the ServerSocket.java source code. I believe the state that prevents the port from being reused immediately is private to the kernel and cannot be observed from a user process, at least not without attempting to reopen the socket. Side note: one of the jcmd() overloads says that parameter 'c' (a Consumer) may be null. It doesn't look like this is handled. If you really want to support this, I'd assign () -> { } to it if it's null so that it can be called unconditionally. (Or just disallow null.) s'marks On 1/6/15 2:00 PM, Dmitry Samersoff wrote: > Jaroslav, > > It might be better to just choose a random digit between 49152?65535 > and attempt to use it. > > -Dmitry > > > On 2014-12-18 17:29, Jaroslav Bachorik wrote: >> On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >>> Jaroslav, >>> >>> You can set SO_LINGER to zero, in this case socket will be closed >>> immediately without waiting in TIME_WAIT >>> >>> But there are no reliable way to predict whether you can take this port >>> or not after you close it. >>> >>> So the only valid solution is to try to connect to a random port and if >>> this attempt fails try another random port. Everything else will cause >>> more or less frequent intermittent failures. >> >> Thanks for all the suggestions! >> >> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 >> >> I've enhanced the original patch with the retry logic using different >> random port if starting the JMX agent on the provided port fails with >> BindException. >> >> I'm keeping there the changes for properly closing the ports opened for >> the test purposes and also setting the SO_REUSEADDR - anyway, it does >> not make sense to reuse the ephemeral test ports. >> >> I've split the original "test_06" test case in order to keep it readable >> even with the new retry logic - and also to make each test case to test >> just one scenario. >> >> Cheers, >> >> -JB- >> >>> >>> -Dmitry >>> >>> >>> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following test change >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>>> >>>>>>> The test fails very intermittently when RMI registry is trying to >>>>>>> bind >>>>>>> to a port >>>>>>> previously used in the test (via ServerSocket). >>>>>>> >>>>>>> This seems to be caused by the sockets created via `new >>>>>>> ServerSocket(0)` and >>>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>>> explicitly >>>>>>> forbidding the reusable mode. >>>>>> >>>>>> Hi Jaroslav, >>>>>> >>>>>> I happened to see this fly by, and there are (I think) some similar >>>>>> issues going on in the RMI tests. >>>>>> >>>>>> But first I'll note that I don't think setReuseAddress() will have the >>>>>> effect that you want. Typically it's set to true before binding a >>>>>> socket, so that a subsequent bind operation will succeed even if the >>>>>> address/port is already in use. ServerSockets created with new >>>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>>> setReuseAddress(false) will do on such sockets. The spec says behavior >>>>>> is undefined, but my bet is that it does nothing. >>>>>> >>>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>>> difference, >>>>>> but I don't have much confidence it will help. >>>>>> >>>>>> The potential similarity to the RMI tests is exemplified by >>>>>> JDK-8049202 >>>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>>> registry as follows: >>>>>> >>>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>>>> RMI registry port] in order to ensure that 1099 isn't in use by >>>>>> something else already; >>>>>> >>>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>>> >>>>>> 3. Then it creates a new RMI registry on port 1099. >>>>>> >>>>>> In principle, this should succeed, yet it fails around 10% of the time >>>>>> on some systems. The error is "port already in use". My best theory is >>>>>> that even though the socket has just been closed by a user program, >>>>>> the >>>>>> kernel has to run the socket through some of the socket states such as >>>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>>> closed >>>>>> and is available for reuse. If a program -- even the same one -- >>>>>> attempts to open a socket on the same port before the socket has >>>>>> reached >>>>>> its final state, it will get an "already in use error". >>>>>> >>>>>> If this is true I don't believe that setting SO_REUSEADDR will work if >>>>>> the socket is in one of these final states. (I remember reading this >>>>>> somewhere but I'm not sure where at the moment. I can try to dig it up >>>>>> if there is interest.) >>>>>> >>>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>>> also >>>>>> open to hearing about ways to deal with this problem. >>>>>> >>>>>> Could something similar be going on with this JMX test? >>>>> >>>>> Hm, this is exactly what happened with this test :( >>>>> >>>>> The problem is that the port is reported as available while it is still >>>>> occupied and RMI registry attempts to start using that port. >>>>> >>>>> If setting SO_REUSEADDR does not work then the only solution would >>>>> be to >>>>> retry the test case when this exception occurs. >>>> >>>> Further investigation shows that the problem was rather the client >>>> connecting to a socket being shut down. >>>> >>>> It sounds like setting SO_REUSEADDR to false should prevent this >>>> failure. >>>> >>>> From the ServerSocket javadoc: >>>> "When a TCP connection is closed the connection may remain in a timeout >>>> state for a period of time after the connection is closed (typically >>>> known as the TIME_WAIT state or 2MSL wait state). For applications using >>>> a well known socket address or port it may not be possible to bind a >>>> socket to the required SocketAddress if there is a connection in the >>>> timeout state involving the socket address or port." >>>> >>>> It also turns out that the test does not close the server sockets >>>> properly so there might be several sockets being opened or timed out >>>> dangling around. >>>> >>>> I've updated the test so it is setting SO_REUSEADDR for all the new >>>> ServerSockets instances + introduced the mechanism to run the test code >>>> while properly cleaning up any allocated ports. >>>> >>>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>>> >>>> -JB- >>>> >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> s'marks >>>>> >>>> >>> >>> >> > > From frederic.parain at oracle.com Fri Jan 9 08:53:02 2015 From: frederic.parain at oracle.com (Frederic Parain) Date: Fri, 09 Jan 2015 09:53:02 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54AEF6B6.6020404@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> Message-ID: <54AF96EE.1030808@oracle.com> On 01/08/2015 10:29 PM, Chris Plummer wrote: > Hi Karen, > > Comments inline. > > On 1/8/15 8:07 AM, Karen Kinnear wrote: >> Chris, >> >> Thank you for doing this. I had a couple of questions/comments. >> >> I like your idea of being able to start with a specific class to show >> all subclasses of. > Ok. I'll add that. >> >> I think the way I read the code this shows the superclass hierarchy, >> not the superinterfaces. With the addition >> of default methods in interfaces, I think we have increased the value >> in seeing superinterfaces. > It does include interfaces in the output, but not as part of any class > hierarchy. Interfaces are just shown as regular classes that inherit > from Object. This is the case if one interface extends another, I > suppose because "extends" is just interpreted as "implements" in this case. >> >> So what I personally would find useful would be to be able to start >> with a specific class and >> find the superclasses and superinterfaces of that class - for the >> debugging I do, I usually am >> trying to look up and need both sets of information. Today if you run >> -XX:+TraceDefaultMethods >> there is one sample way to display all the supertypes of a single >> type, all the way up. I don't know the >> best way to make that consistent with the current output approach, >> e.g. using the |- syntax. >> >> e.g. >> Class java.util.Arrays$ArrayList requires default method processing >> java/util/Arrays$ArrayList >> java/util/AbstractList >> java/util/AbstractCollection >> java/lang/Object >> java/util/Collection >> java/lang/Object >> java/lang/Iterable >> java/lang/Object >> java/util/List >> java/lang/Object >> java/util/Collection >> java/lang/Object >> java/lang/Iterable >> java/lang/Object >> java/util/RandomAccess >> java/lang/Object >> java/io/Serializable >> java/lang/Object >> >> Do you think there could be value to others in the ability to walk up >> the hierarchy as well as to >> see superclasses and superinterfaces at least from that perspective? > This is a inverted from how my dcmd prints the hierarchy, plus also > includes interfaces. Inverting the hierarchy means a class is listed > with every subclass of the class, which I don't think is desirable. > Including interfaces has the same issue, but introduces a new issue even > when not inverting the hierarchy. The same interface can be in more than > one location in the hierarchy, so there is no avoiding printing it more > than once, so we need to decide how to best include interfaces in the > output. It seems to me that we have two very different use cases here, each one best served with a different output format: 1 - Listing of all classes/interfaces hierarchy when the dcmd is invoked without arguments: -> Chris' output format as described below (with interfaces) 2 - Investigation on a particular class or interface when a class or interface is passed in argument to the dcmd -> Karen's output format, much easier to work with to track default methods. Because the output is limited to the hierarchy from a single class, there's no class duplication in output (single parent class inheritance) and limited interfaces duplication. If the implementations of the two features are too different, we could consider having two different dcmds. My 2 cents, Fred > The could just be a simple list right after the class that > implements them: > > java.lang.Object > | ... > |--MyBaseClass > | | implements -> MyInterface1 > | | implements -> MyInterface2 > | |--MySubClass > | implements -> MyInterface1 > | implements -> MyInterface2 > | ... > |--MyInterface1 > |--MyInterface2 > > The "implements" lines could be optional. > > I know cvm would distinguish between interfaces the Class declared it > implemented, and those it inherited from the interfaces it declared it > implemented. This was necessary for reflection, and I think also to > properly build up interfaces tables. I assume hotspot does something > similar. Is there any need for this information to be conveyed in the > above output, or just list out every interface implemented, and not > worry about how the class acquired it. >> Is there value in printing the defining class loader for each class - >> maybe optionally? > This is already available with GC.class_stats, although not in the > default output. I suppose the reality is that it might be better handled > by this DCMD. The main puprose of GC.class_stats is to print statistics > (counts and sizes), so printing the ClassLoader name there is probably > not appropriate, but then it's not really appropriate for > VM.class_hierarchy either. I'm not sure how best to handle this. One or > both DCMDs possibly should be re-purposed and more clearly define what > type of data it displays. >> If so, I'm wondering if there might be value in future for the jigsaw >> project adding the module for each class - maybe optionally as well? > This relates to my above statement. We need to figure out what type of > data is useful, and which dcmds should handle them. >> Love opinions on that - especially from the serviceability folks >> >> thanks, >> Karen > Thanks for the input. > > Chris >> >> >> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >> >>> Hi, >>> >>> Please review the following changes for the addition of the >>> VM.class_hierarchy DCMD. Please read the bug first for some >>> background information. >>> >>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>> >>> I expect there will be further restructuring or additional feature >>> work. More discussion on that below. I'm not sure if that additional >>> work will be done later with a separately bug filed or with this >>> initial commit. That's one thing I want to work out with this review. >>> >>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>> The main purpose of this file is to implement the GC.class_stats and >>> GC.class_histogram DCMDs. Both of them require walking the java heap >>> to count live objects of each type, thus the name >>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>> require walking the heap, but is implemented in this file because it >>> leverages the existing KlassInfoTable and related classes >>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>> >>> KlassInfoTable makes it easy to build a database of all loaded >>> classes, save additional info gathered for each class, iterate over >>> them quickly, and also do quick lookups. This exactly what I needed >>> for this DCMD, thus the reuse. There is some downside to this. For >>> starters, heapInspection.cpp is not the proper place for a DCMD that >>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>> a result each has a few fields and methods that are not used for all >>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>> prefer that be done as a next step so I'm not disturbing the existing >>> DCMDs with this first implementation. >>> >>> I added some comments to code only used for GC.class_stats and >>> GC.class_histogram. I did this when trying to figure them out so I >>> could better understand how to implement VM.class_hierarchy. I can >>> take them out if you think they are not appropriate for this commit. >>> >>> One other item I like to discuss is whether it is worth adding a >>> class name argument to this DCMD. That would cause just the >>> superclasses and subclasses of the named class to be printed. If you >>> think that is useful, I think it can be added without too much trouble. >>> >>> At the moment not much testing has been done other than running the >>> DCMD and looking at the output. I'll do more once it's clear the code >>> has "settled". I would like to know if there are any existing tests >>> for GC.class_stats and GC.class_histogram (there are none in the >>> "test" directory). If so, possibly one could serve as the basis for a >>> new test for VM.class_hierarchy. >>> >>> thanks, >>> >>> Chris > -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From stefan.karlsson at oracle.com Fri Jan 9 09:01:02 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 09 Jan 2015 10:01:02 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54AED73E.1060905@oracle.com> References: <54ADC152.6000706@oracle.com> <54AE60F9.6000000@oracle.com> <54AED73E.1060905@oracle.com> Message-ID: <54AF98CE.6050606@oracle.com> On 2015-01-08 20:15, Chris Plummer wrote: > Hi Stefan, > > Comments inline below: > > On 1/8/15 2:50 AM, Stefan Karlsson wrote: >> Hi Chris, >> >> On 2015-01-08 00:29, Chris Plummer wrote: >>> Hi, >>> >>> Please review the following changes for the addition of the >>> VM.class_hierarchy DCMD. Please read the bug first for some >>> background information. >>> >>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >> >> This looks like a nice feature. I think your suggestion about >> supporting a class name argument as the root of the hierarchy would >> be a nice addition. >> >> >> Some comments: >> >> Why do you need / use the super_stack? To me it seems like you could >> simplify the could if you get rid of the super_stack and walk the >> Klass::super() chain instead. > The initial implementation actually printed the superclass index as > the indentation, which required the super_stack, and I just ended up > keeping it. It looks like I could get rid of all the superclass > maintenance done in print_class_hierarchy() if I walk Klass:super() > in print_class(). I'll make that change. >> >> Why did you add this side-effect to KlassInfoHisto::print_class_state?: >> >> - super_index = super_e->index(); >> + e->set_super_index(super_e->index()); >> >> >> AFAICT, you are not using KlassInfoHisto::print_class_stats to >> implement the VM.class_hierarchy DCMD, right? Or am I missing >> something in your patch? > Originally I did overload print_class_stats to also handle > VM.class_hierarchy, but in the end decided not to due to the overhead > of it causing the java heap to be walked. So the above is a remnant, > but is also consistent with how print_class_hierarchy() sets the > super_index field of the KlassInfoEntry. However, it may not be > necessary anymore to maintain the super_index if I make the change > above to no longer maintain the super_stack. I'll look into that. > >> >> A side-note, if it were not for the AnonymousClasses (created by >> Unsafe_DefineAnonymousClass), then this could have be implemented >> with less resources by just walking the Klass::subclass() and >> Klass::next_sibling() links. Which means that you wouldn't have to >> use any of the classes or functionality in heapInspection.hpp/cpp. >> But the anonymous classes is unfortunately not present in the >> subclass/next_sibling hierarchy. > I didn't not realize subclass info was being maintained by Klass. > Still had CVM stuck in my head, which does not do that. I'm not sure > what the AnonymousClasses issue is. Can you explain more? The AnonymousClasses are supposed to be lightweight classes used by JSR292. They have a different lifecycle than ordinary Klasses, and are not registered in some of the data structures where the ordinary Klasses are registered, and one example is the subclass/next_sibling tree. Because these classes treated differently, they are a constant source of bugs. If you visit Klasses by iterating over a data structure in the JVM, you need to know if the AnonymousClasses are present our not. Your current code is safe because you walk the ClassLoaderDataGraph, which contains the AnonymousKlasses. But a simplified version relying on the subclass/next_sibling tree would unfortunately be broken. The SystemDictionary is another place where the AnonymousClasses are not registered. Note, that the term "anonymous class" is an overloaded term and I'm not referring to this kind of anonymous classes: http://docs.oracle.com/javase/tutorial/java/javaOO/anonymousclasses.html >> >> >> And some style comments: >> >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/services/diagnosticCommand.cpp.frames.html >> >> >> Maybe it would be nice to move: >> >> 66 #if INCLUDE_SERVICES >> 67 DCmdFactory::register_DCmdFactory(new >> DCmdFactoryImpl(full_export, true, false)); >> 68 #endif >> >> into the already existing INCLUDE_SERVICE block: >> >> 55 #if INCLUDE_SERVICES // Heap dumping/inspection supported >> 56 DCmdFactory::register_DCmdFactory(new >> DCmdFactoryImpl(DCmd_Source_Internal | >> DCmd_Source_AttachAPI, true, false)); >> 57 DCmdFactory::register_DCmdFactory(new >> DCmdFactoryImpl(full_export, true, false)); >> 58 DCmdFactory::register_DCmdFactory(new >> DCmdFactoryImpl(full_export, true, false)); >> 59 #endif // INCLUDE_SERVICES > Ok. >> >> >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/memory/heapInspection.hpp.frames.html >> >> >> >> I would prefer if you moved the following implementation to the cpp >> file, so that we can keep our includes in our hpp files to a minimal. >> That helps lowering our include complexity. >> >> 218 inline void KlassInfoEntry::add_subclass(KlassInfoEntry* cie) { >> 219 if (_subclasses == NULL) { >> 220 _subclasses = new (ResourceObj::C_HEAP, mtInternal) >> GrowableArray(4, true); >> 221 } >> 222 _subclasses->append(cie); >> 223 } >> 224 >> 225 inline KlassInfoEntry::~KlassInfoEntry() { >> 226 if (_subclasses != NULL) { >> 227 delete _subclasses; >> 228 } >> 229 } >> > I guess I'm a bit unclear on this, and had already pondered where this > code should go. I've seen methods embedded in the class definition, > inline in a separate "xxx_inline.hpp" file, inline like I have above, > and of course in the .cpp file. What are the guidelines for deciding > where to put them? There's a section written on: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files But typically, don't add the implementation in the hpp if the code depends on other hpp files. If the the code needs to be inlined for performance reasons, then you should put the declaration in a xxx.inline.hpp file. >> >> http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/src/share/vm/memory/heapInspection.cpp.frames.html >> >> >> Could you move the local variables to where they are used: >> >> 316 void KlassHierarchy::print_class_hierarchy(outputStream* st) { >> 317 ResourceMark rm; >> 318 int i; >> 319 Stack class_stack; >> 320 Stack super_stack; >> 321 GrowableArray elements; >> 322 >> > ok. >> >> For example, 'int i' into the for statements: >> >> 336 // Set the index for each class >> 337 for(i=0; i < elements.length(); i++) { >> 338 elements.at(i)->set_index(i+1); >> 339 } >> >> >> Could you add spaces around the operators (= and +): >> >> 337 for(i=0; i < elements.length(); i++) { >> 338 elements.at(i)->set_index(i+1); > ok. >> >> >> Some of your new comments are not capitalized and some lack a period. >> Example: >> >> 399 // print indentation with proper indicators of superclass. >> >> 454 // Add the stats for this class to the overall totals > Ok. >> >> >> Thanks, >> StefanK > Thanks for the review! Thanks for the feature! StefanK > > Chris >> >>> >>> I expect there will be further restructuring or additional feature >>> work. More discussion on that below. I'm not sure if that additional >>> work will be done later with a separately bug filed or with this >>> initial commit. That's one thing I want to work out with this review. >>> >>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>> The main purpose of this file is to implement the GC.class_stats >>> and GC.class_histogram DCMDs. Both of them require walking the java >>> heap to count live objects of each type, thus the name >>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>> require walking the heap, but is implemented in this file because it >>> leverages the existing KlassInfoTable and related classes >>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>> >>> KlassInfoTable makes it easy to build a database of all loaded >>> classes, save additional info gathered for each class, iterate over >>> them quickly, and also do quick lookups. This exactly what I needed >>> for this DCMD, thus the reuse. There is some downside to this. For >>> starters, heapInspection.cpp is not the proper place for a DCMD that >>> has nothing to do with heap inspection. Also, KlassInfoEntry is >>> being overloaded now to support 3 different DCMDs, as is >>> KlassInfoTable. As a result each has a few fields and methods that >>> are not used for all 3 DCMDs. Some subclassing might be in order >>> here, but I'm not sure if it's worth it. Opinions welcomed. If I am >>> going to refactor, I would prefer that be done as a next step so I'm >>> not disturbing the existing DCMDs with this first implementation. >>> >>> I added some comments to code only used for GC.class_stats and >>> GC.class_histogram. I did this when trying to figure them out so I >>> could better understand how to implement VM.class_hierarchy. I can >>> take them out if you think they are not appropriate for this commit. >>> >>> One other item I like to discuss is whether it is worth adding a >>> class name argument to this DCMD. That would cause just the >>> superclasses and subclasses of the named class to be printed. If you >>> think that is useful, I think it can be added without too much trouble. >>> >>> At the moment not much testing has been done other than running the >>> DCMD and looking at the output. I'll do more once it's clear the >>> code has "settled". I would like to know if there are any existing >>> tests for GC.class_stats and GC.class_histogram (there are none in >>> the "test" directory). If so, possibly one could serve as the basis >>> for a new test for VM.class_hierarchy. >>> >>> thanks, >>> >>> Chris >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Fri Jan 9 09:22:04 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 09 Jan 2015 12:22:04 +0300 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54AF4203.6040000@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> Message-ID: <54AF9DBC.9000800@oracle.com> Stuart, > The range that Dmitry suggests is reasonable, though I note that the > actual ephemeral port range used by the kernel will differ from OS to > OS and even from system to system. I don't know if that's really > significant though. If you end up choosing a port outside the > ephemeral range for some system, does it really matter? This range is assigned by IANA so it's a standard. -Dmitry On 2015-01-09 05:50, Stuart Marks wrote: > Hi Jaroslav, > > I'm distant enough from this code that I don't think I'm in a position > to say "no you can't check this in," and I'm mindful of the fact that > this bug is a high priority and you want to get a fix in. But having > said that I think there's a surprising amount of complexity here for > what it does. > > Implementing a retry-on-BindException policy seems to be fairly > sensible, since I assume it would be fairly invasive to modify the code > in the JVMs being forked to use an ephemeral port and send that > information back to the test. > > My conjecture is however that the open/close/reopen logic is the primary > cause of the BindExceptions that occur. If you're going to retry on > BindException, you might as well choose a random port number instead of > doing the open/close to get a port number from the system. > > The range that Dmitry suggests is reasonable, though I note that the > actual ephemeral port range used by the kernel will differ from OS to OS > and even from system to system. I don't know if that's really > significant though. If you end up choosing a port outside the ephemeral > range for some system, does it really matter? > > If you do decide to have PortAllocator open and close a ServerSocket (in > order to find a previously unused port) I'd suggest removing the logic > that leaves the socket open until the first call to get(). That logic > reduces the possibility that some other process will open the socket > after the close but before the reopen. In my experience that's not > what's causing the BindExceptions. It could still happen, though, but > you're protected by the retry logic anyway. Leaving the socket open > longer actually hurts, I think, because it increases the chance that the > kernel won't have cleaned up the port by the time the test wants to > reopen it. > > If you change PortAllocator to close the socket immediately, you can get > rid of the need to call release() in a finally-block of the caller. You > could also change the type of the functional interface to be > > int[] -> void > > since the PortAllocator doesn't hold onto any resources that need to be > cleaned up. It just calls the execute() method and passes an array of n > port numbers. > > It's probably necessary to have the socket close() call in a retry loop. > The socket is always closed immediately from the user process point of > view, so isClosed() will always return true immediately after the > close() call returns. You can verify this easily by looking in the > ServerSocket.java source code. I believe the state that prevents the > port from being reused immediately is private to the kernel and cannot > be observed from a user process, at least not without attempting to > reopen the socket. > > Side note: one of the jcmd() overloads says that parameter 'c' (a > Consumer) may be null. It doesn't look like this is handled. If you > really want to support this, I'd assign () -> { } to it if it's null so > that it can be called unconditionally. (Or just disallow null.) > > s'marks > > > On 1/6/15 2:00 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> It might be better to just choose a random digit between 49152?65535 >> and attempt to use it. >> >> -Dmitry >> >> >> On 2014-12-18 17:29, Jaroslav Bachorik wrote: >>> On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> You can set SO_LINGER to zero, in this case socket will be closed >>>> immediately without waiting in TIME_WAIT >>>> >>>> But there are no reliable way to predict whether you can take this port >>>> or not after you close it. >>>> >>>> So the only valid solution is to try to connect to a random port and if >>>> this attempt fails try another random port. Everything else will cause >>>> more or less frequent intermittent failures. >>> >>> Thanks for all the suggestions! >>> >>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 >>> >>> I've enhanced the original patch with the retry logic using different >>> random port if starting the JMX agent on the provided port fails with >>> BindException. >>> >>> I'm keeping there the changes for properly closing the ports opened for >>> the test purposes and also setting the SO_REUSEADDR - anyway, it does >>> not make sense to reuse the ephemeral test ports. >>> >>> I've split the original "test_06" test case in order to keep it readable >>> even with the new retry logic - and also to make each test case to test >>> just one scenario. >>> >>> Cheers, >>> >>> -JB- >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>>>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>>>> >>>>>>>> The test fails very intermittently when RMI registry is trying to >>>>>>>> bind >>>>>>>> to a port >>>>>>>> previously used in the test (via ServerSocket). >>>>>>>> >>>>>>>> This seems to be caused by the sockets created via `new >>>>>>>> ServerSocket(0)` and >>>>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>>>> explicitly >>>>>>>> forbidding the reusable mode. >>>>>>> >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> I happened to see this fly by, and there are (I think) some similar >>>>>>> issues going on in the RMI tests. >>>>>>> >>>>>>> But first I'll note that I don't think setReuseAddress() will >>>>>>> have the >>>>>>> effect that you want. Typically it's set to true before binding a >>>>>>> socket, so that a subsequent bind operation will succeed even if the >>>>>>> address/port is already in use. ServerSockets created with new >>>>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>>>> setReuseAddress(false) will do on such sockets. The spec says >>>>>>> behavior >>>>>>> is undefined, but my bet is that it does nothing. >>>>>>> >>>>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>>>> difference, >>>>>>> but I don't have much confidence it will help. >>>>>>> >>>>>>> The potential similarity to the RMI tests is exemplified by >>>>>>> JDK-8049202 >>>>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>>>> registry as follows: >>>>>>> >>>>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>>>>> RMI registry port] in order to ensure that 1099 isn't in >>>>>>> use by >>>>>>> something else already; >>>>>>> >>>>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>>>> >>>>>>> 3. Then it creates a new RMI registry on port 1099. >>>>>>> >>>>>>> In principle, this should succeed, yet it fails around 10% of the >>>>>>> time >>>>>>> on some systems. The error is "port already in use". My best >>>>>>> theory is >>>>>>> that even though the socket has just been closed by a user program, >>>>>>> the >>>>>>> kernel has to run the socket through some of the socket states >>>>>>> such as >>>>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>>>> closed >>>>>>> and is available for reuse. If a program -- even the same one -- >>>>>>> attempts to open a socket on the same port before the socket has >>>>>>> reached >>>>>>> its final state, it will get an "already in use error". >>>>>>> >>>>>>> If this is true I don't believe that setting SO_REUSEADDR will >>>>>>> work if >>>>>>> the socket is in one of these final states. (I remember reading this >>>>>>> somewhere but I'm not sure where at the moment. I can try to dig >>>>>>> it up >>>>>>> if there is interest.) >>>>>>> >>>>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>>>> also >>>>>>> open to hearing about ways to deal with this problem. >>>>>>> >>>>>>> Could something similar be going on with this JMX test? >>>>>> >>>>>> Hm, this is exactly what happened with this test :( >>>>>> >>>>>> The problem is that the port is reported as available while it is >>>>>> still >>>>>> occupied and RMI registry attempts to start using that port. >>>>>> >>>>>> If setting SO_REUSEADDR does not work then the only solution would >>>>>> be to >>>>>> retry the test case when this exception occurs. >>>>> >>>>> Further investigation shows that the problem was rather the client >>>>> connecting to a socket being shut down. >>>>> >>>>> It sounds like setting SO_REUSEADDR to false should prevent this >>>>> failure. >>>>> >>>>> From the ServerSocket javadoc: >>>>> "When a TCP connection is closed the connection may remain in a >>>>> timeout >>>>> state for a period of time after the connection is closed (typically >>>>> known as the TIME_WAIT state or 2MSL wait state). For applications >>>>> using >>>>> a well known socket address or port it may not be possible to bind a >>>>> socket to the required SocketAddress if there is a connection in the >>>>> timeout state involving the socket address or port." >>>>> >>>>> It also turns out that the test does not close the server sockets >>>>> properly so there might be several sockets being opened or timed out >>>>> dangling around. >>>>> >>>>> I've updated the test so it is setting SO_REUSEADDR for all the new >>>>> ServerSockets instances + introduced the mechanism to run the test >>>>> code >>>>> while properly cleaning up any allocated ports. >>>>> >>>>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> s'marks >>>>>> >>>>> >>>> >>>> >>> >> >> -- 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 mikael.auno at oracle.com Fri Jan 9 12:14:48 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 09 Jan 2015 13:14:48 +0100 Subject: RFR(XXS): 8068584: Compiler attach tests should be quarantined In-Reply-To: <54AE7BD1.4010907@oracle.com> References: <54AE5621.5010300@oracle.com> <54AE5A33.6040206@oracle.com> <54AE7BD1.4010907@oracle.com> Message-ID: <54AFC638.4000306@oracle.com> Looks good to me. I'm not a reviewer though. Mikael On 2015-01-08 13:45, Mattias Tobiasson wrote: > Thanks for the explanation. > I have moved the @ignore tags to directly before the first @run tag. > > webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.01/ > > > Mattias > > > On 01/08/2015 11:21 AM, Mikael Auno wrote: >> On 2015-01-08 11:04, Mattias Tobiasson wrote: >>> Hi, >>> Could I please have a review of this bug quarantine. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068584 >>> webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/ >>> >>> Thanks, >>> Mattias >>> >> Mattias, >> >> In the two **/Launcher.java tests, you must place @ignore after the >> @library line, otherwise there will be a "Parse Exception: `@library' >> must appear before first `@run'". (The error message is, to say the >> least, a bit unintuitive until you figure out that "@ignore" is just an >> alias for "@run ignore".) >> >> Mikael > From jaroslav.bachorik at oracle.com Fri Jan 9 12:17:46 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 09 Jan 2015 13:17:46 +0100 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54AF4203.6040000@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> Message-ID: <54AFC6EA.8080708@oracle.com> Thank you all for the valuable input! On 9.1.2015 03:50, Stuart Marks wrote: > Hi Jaroslav, > > I'm distant enough from this code that I don't think I'm in a position > to say "no you can't check this in," and I'm mindful of the fact that > this bug is a high priority and you want to get a fix in. But having > said that I think there's a surprising amount of complexity here for > what it does. > > Implementing a retry-on-BindException policy seems to be fairly > sensible, since I assume it would be fairly invasive to modify the code > in the JVMs being forked to use an ephemeral port and send that > information back to the test. > > My conjecture is however that the open/close/reopen logic is the primary > cause of the BindExceptions that occur. If you're going to retry on > BindException, you might as well choose a random port number instead of > doing the open/close to get a port number from the system. > > The range that Dmitry suggests is reasonable, though I note that the > actual ephemeral port range used by the kernel will differ from OS to OS > and even from system to system. I don't know if that's really > significant though. If you end up choosing a port outside the ephemeral > range for some system, does it really matter? > > If you do decide to have PortAllocator open and close a ServerSocket (in > order to find a previously unused port) I'd suggest removing the logic > that leaves the socket open until the first call to get(). That logic > reduces the possibility that some other process will open the socket > after the close but before the reopen. In my experience that's not > what's causing the BindExceptions. It could still happen, though, but > you're protected by the retry logic anyway. Leaving the socket open > longer actually hurts, I think, because it increases the chance that the > kernel won't have cleaned up the port by the time the test wants to > reopen it. > > If you change PortAllocator to close the socket immediately, you can get > rid of the need to call release() in a finally-block of the caller. You > could also change the type of the functional interface to be > > int[] -> void > > since the PortAllocator doesn't hold onto any resources that need to be > cleaned up. It just calls the execute() method and passes an array of n > port numbers. > > It's probably necessary to have the socket close() call in a retry loop. > The socket is always closed immediately from the user process point of > view, so isClosed() will always return true immediately after the > close() call returns. You can verify this easily by looking in the > ServerSocket.java source code. I believe the state that prevents the > port from being reused immediately is private to the kernel and cannot > be observed from a user process, at least not without attempting to > reopen the socket. > > Side note: one of the jcmd() overloads says that parameter 'c' (a > Consumer) may be null. It doesn't look like this is handled. If you > really want to support this, I'd assign () -> { } to it if it's null so > that it can be called unconditionally. (Or just disallow null.) I've changed the PortAllocator to allocate an array of unique random ports instead of letting ServerSocket to take care of it. I ran the test 200x in a tight loop without a failure. I hope this will resolve this test's intermittent failures due to port conflicts once and for all. Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.03 Thanks, -JB- > > s'marks > > > On 1/6/15 2:00 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> It might be better to just choose a random digit between 49152?65535 >> and attempt to use it. >> >> -Dmitry >> >> >> On 2014-12-18 17:29, Jaroslav Bachorik wrote: >>> On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >>>> Jaroslav, >>>> >>>> You can set SO_LINGER to zero, in this case socket will be closed >>>> immediately without waiting in TIME_WAIT >>>> >>>> But there are no reliable way to predict whether you can take this port >>>> or not after you close it. >>>> >>>> So the only valid solution is to try to connect to a random port and if >>>> this attempt fails try another random port. Everything else will cause >>>> more or less frequent intermittent failures. >>> >>> Thanks for all the suggestions! >>> >>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.02 >>> >>> I've enhanced the original patch with the retry logic using different >>> random port if starting the JMX agent on the provided port fails with >>> BindException. >>> >>> I'm keeping there the changes for properly closing the ports opened for >>> the test purposes and also setting the SO_REUSEADDR - anyway, it does >>> not make sense to reuse the ephemeral test ports. >>> >>> I've split the original "test_06" test case in order to keep it readable >>> even with the new retry logic - and also to make each test case to test >>> just one scenario. >>> >>> Cheers, >>> >>> -JB- >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2014-12-11 17:06, Jaroslav Bachorik wrote: >>>>> On 12/09/2014 01:25 PM, Jaroslav Bachorik wrote: >>>>>> On 12/09/2014 01:39 AM, Stuart Marks wrote: >>>>>>> On 12/8/14 12:35 PM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following test change >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8066708 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.00 >>>>>>>> >>>>>>>> The test fails very intermittently when RMI registry is trying to >>>>>>>> bind >>>>>>>> to a port >>>>>>>> previously used in the test (via ServerSocket). >>>>>>>> >>>>>>>> This seems to be caused by the sockets created via `new >>>>>>>> ServerSocket(0)` and >>>>>>>> being in reusable mode. The fix attempts to prevent this by >>>>>>>> explicitly >>>>>>>> forbidding the reusable mode. >>>>>>> >>>>>>> Hi Jaroslav, >>>>>>> >>>>>>> I happened to see this fly by, and there are (I think) some similar >>>>>>> issues going on in the RMI tests. >>>>>>> >>>>>>> But first I'll note that I don't think setReuseAddress() will >>>>>>> have the >>>>>>> effect that you want. Typically it's set to true before binding a >>>>>>> socket, so that a subsequent bind operation will succeed even if the >>>>>>> address/port is already in use. ServerSockets created with new >>>>>>> ServerSocket(0) are already bound, and I'm not sure what calling >>>>>>> setReuseAddress(false) will do on such sockets. The spec says >>>>>>> behavior >>>>>>> is undefined, but my bet is that it does nothing. >>>>>>> >>>>>>> I guess it doesn't hurt to try this out to see if it makes a >>>>>>> difference, >>>>>>> but I don't have much confidence it will help. >>>>>>> >>>>>>> The potential similarity to the RMI tests is exemplified by >>>>>>> JDK-8049202 >>>>>>> (sorry, this bug report isn't open) but briefly this tests the RMI >>>>>>> registry as follows: >>>>>>> >>>>>>> 1. Opens port 1099 using new ServerSocket(1099) [1099 is the default >>>>>>> RMI registry port] in order to ensure that 1099 isn't in >>>>>>> use by >>>>>>> something else already; >>>>>>> >>>>>>> 2. If this succeeds, it immediately closes the ServerSocket. >>>>>>> >>>>>>> 3. Then it creates a new RMI registry on port 1099. >>>>>>> >>>>>>> In principle, this should succeed, yet it fails around 10% of the >>>>>>> time >>>>>>> on some systems. The error is "port already in use". My best >>>>>>> theory is >>>>>>> that even though the socket has just been closed by a user program, >>>>>>> the >>>>>>> kernel has to run the socket through some of the socket states >>>>>>> such as >>>>>>> FIN_WAIT_1, FIN_WAIT_2, or CLOSING before the socket is actually >>>>>>> closed >>>>>>> and is available for reuse. If a program -- even the same one -- >>>>>>> attempts to open a socket on the same port before the socket has >>>>>>> reached >>>>>>> its final state, it will get an "already in use error". >>>>>>> >>>>>>> If this is true I don't believe that setting SO_REUSEADDR will >>>>>>> work if >>>>>>> the socket is in one of these final states. (I remember reading this >>>>>>> somewhere but I'm not sure where at the moment. I can try to dig >>>>>>> it up >>>>>>> if there is interest.) >>>>>>> >>>>>>> I admit this is just a theory and I'm open to alternatives, and I'm >>>>>>> also >>>>>>> open to hearing about ways to deal with this problem. >>>>>>> >>>>>>> Could something similar be going on with this JMX test? >>>>>> >>>>>> Hm, this is exactly what happened with this test :( >>>>>> >>>>>> The problem is that the port is reported as available while it is >>>>>> still >>>>>> occupied and RMI registry attempts to start using that port. >>>>>> >>>>>> If setting SO_REUSEADDR does not work then the only solution would >>>>>> be to >>>>>> retry the test case when this exception occurs. >>>>> >>>>> Further investigation shows that the problem was rather the client >>>>> connecting to a socket being shut down. >>>>> >>>>> It sounds like setting SO_REUSEADDR to false should prevent this >>>>> failure. >>>>> >>>>> From the ServerSocket javadoc: >>>>> "When a TCP connection is closed the connection may remain in a >>>>> timeout >>>>> state for a period of time after the connection is closed (typically >>>>> known as the TIME_WAIT state or 2MSL wait state). For applications >>>>> using >>>>> a well known socket address or port it may not be possible to bind a >>>>> socket to the required SocketAddress if there is a connection in the >>>>> timeout state involving the socket address or port." >>>>> >>>>> It also turns out that the test does not close the server sockets >>>>> properly so there might be several sockets being opened or timed out >>>>> dangling around. >>>>> >>>>> I've updated the test so it is setting SO_REUSEADDR for all the new >>>>> ServerSockets instances + introduced the mechanism to run the test >>>>> code >>>>> while properly cleaning up any allocated ports. >>>>> >>>>> http://cr.openjdk.java.net/~jbachorik/8066708/webrev.01/ >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> s'marks >>>>>> >>>>> >>>> >>>> >>> >> >> From staffan.larsen at oracle.com Fri Jan 9 12:38:09 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 Jan 2015 13:38:09 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54AF96EE.1030808@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> Message-ID: <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> It?s getting difficult to get all the information into the same output: hierarchy, interfaces, class loaders and modules. I took a stab at it and it could look like this: java.lang.Object |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) |--java.lang.Iterable (java.base, 0x00000007c00375f8, iface) | |--java.util.Collection (java.base, 0x00000007c00375f8, iface) | | |--java.util.List (java.base, 0x00000007c00375f8, iface) |--java.util.AbstractCollection (java.base, 0x00000007c00375f8) | | implements java.util.Collection | | implements java.lang.Iterable | |--java.util.AbstractList (java.base, 0x00000007c00375f8) | | implements java.util.List | | |--java.util.Arrays$ArrayList (java.base, 0x00000007c00375f8) | | | implements java.io.Serializable | | | implements java.util.RandomAccess But this is pushing what can be visualized in one place. We will need to add module and class loader information somehow to all the Diagnostic Commands that list classes. In addition we will need a way to see how modules relate to one another. Perhaps it isn?t possible to have all the information in one place, but instead make it possible to cross reference between different diagnostic commands. For example, GC.class_stats could have the module and class loader information, and GC.class_hierarchy would not have to include it. What is missing from making that possible is a unique way of identifying a class (since the name is not unique). All output would need to include that unique identifier and it would be possible to cross reference. The identifier has to be stable during a JVM run, but not between runs. The above would then become: java.lang.Object/0x12345600 |--java.io.Serializable/0x12345601 |--java.util.RandomAccess/0x12345602 |--java.lang.Iterable/0x12345603 | |--java.util.Collection/0x12345604 | | |--java.util.List/0x12345605 |--java.util.AbstractCollection/0x12345606 | | implements java.util.Collection/0x12345604 | | implements java.lang.Iterable/0x12345603 | |--java.util.AbstractList/0x12345607 | | implements java.util.List/0x12345605 | | |--java.util.Arrays$ArrayList/0x12345608 | | | implements java.io.Serializable/0x12345601 | | | implements java.util.RandomAccess/0x12345602 With additions to GC.class_stats: Index Super ClassLoader ClassName 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 2 1 0x00000007c0034c48 java.util.List/0x12345605 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 And GC.class_histogram: num #instances #bytes class name ---------------------------------------------- 1: 945 117736 java.lang.Object/0x12345600 2: 442 50352 java.util.List/0x12345605 3: 499 25288 java.util.AbstractList/0x12345607 /Staffan > On 9 jan 2015, at 09:53, Frederic Parain wrote: > > > > On 01/08/2015 10:29 PM, Chris Plummer wrote: >> Hi Karen, >> >> Comments inline. >> >> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>> Chris, >>> >>> Thank you for doing this. I had a couple of questions/comments. >>> >>> I like your idea of being able to start with a specific class to show >>> all subclasses of. >> Ok. I'll add that. >>> >>> I think the way I read the code this shows the superclass hierarchy, >>> not the superinterfaces. With the addition >>> of default methods in interfaces, I think we have increased the value >>> in seeing superinterfaces. >> It does include interfaces in the output, but not as part of any class >> hierarchy. Interfaces are just shown as regular classes that inherit >> from Object. This is the case if one interface extends another, I >> suppose because "extends" is just interpreted as "implements" in this case. >>> >>> So what I personally would find useful would be to be able to start >>> with a specific class and >>> find the superclasses and superinterfaces of that class - for the >>> debugging I do, I usually am >>> trying to look up and need both sets of information. Today if you run >>> -XX:+TraceDefaultMethods >>> there is one sample way to display all the supertypes of a single >>> type, all the way up. I don't know the >>> best way to make that consistent with the current output approach, >>> e.g. using the |- syntax. >>> >>> e.g. >>> Class java.util.Arrays$ArrayList requires default method processing >>> java/util/Arrays$ArrayList >>> java/util/AbstractList >>> java/util/AbstractCollection >>> java/lang/Object >>> java/util/Collection >>> java/lang/Object >>> java/lang/Iterable >>> java/lang/Object >>> java/util/List >>> java/lang/Object >>> java/util/Collection >>> java/lang/Object >>> java/lang/Iterable >>> java/lang/Object >>> java/util/RandomAccess >>> java/lang/Object >>> java/io/Serializable >>> java/lang/Object >>> >>> Do you think there could be value to others in the ability to walk up >>> the hierarchy as well as to >>> see superclasses and superinterfaces at least from that perspective? >> This is a inverted from how my dcmd prints the hierarchy, plus also >> includes interfaces. Inverting the hierarchy means a class is listed >> with every subclass of the class, which I don't think is desirable. >> Including interfaces has the same issue, but introduces a new issue even >> when not inverting the hierarchy. The same interface can be in more than >> one location in the hierarchy, so there is no avoiding printing it more >> than once, so we need to decide how to best include interfaces in the >> output. > > It seems to me that we have two very different use cases here, each one > best served with a different output format: > > 1 - Listing of all classes/interfaces hierarchy when the dcmd is > invoked without arguments: > -> Chris' output format as described below (with interfaces) > 2 - Investigation on a particular class or interface when a class > or interface is passed in argument to the dcmd > -> Karen's output format, much easier to work with to > track default methods. Because the output is limited to the > hierarchy from a single class, there's no class duplication > in output (single parent class inheritance) and limited > interfaces duplication. > > If the implementations of the two features are too different, we could > consider having two different dcmds. > > My 2 cents, > > Fred > >> The could just be a simple list right after the class that >> implements them: >> >> java.lang.Object >> | ... >> |--MyBaseClass >> | | implements -> MyInterface1 >> | | implements -> MyInterface2 >> | |--MySubClass >> | implements -> MyInterface1 >> | implements -> MyInterface2 >> | ... >> |--MyInterface1 >> |--MyInterface2 >> >> The "implements" lines could be optional. >> >> I know cvm would distinguish between interfaces the Class declared it >> implemented, and those it inherited from the interfaces it declared it >> implemented. This was necessary for reflection, and I think also to >> properly build up interfaces tables. I assume hotspot does something >> similar. Is there any need for this information to be conveyed in the >> above output, or just list out every interface implemented, and not >> worry about how the class acquired it. >>> Is there value in printing the defining class loader for each class - >>> maybe optionally? >> This is already available with GC.class_stats, although not in the >> default output. I suppose the reality is that it might be better handled >> by this DCMD. The main puprose of GC.class_stats is to print statistics >> (counts and sizes), so printing the ClassLoader name there is probably >> not appropriate, but then it's not really appropriate for >> VM.class_hierarchy either. I'm not sure how best to handle this. One or >> both DCMDs possibly should be re-purposed and more clearly define what >> type of data it displays. >>> If so, I'm wondering if there might be value in future for the jigsaw >>> project adding the module for each class - maybe optionally as well? >> This relates to my above statement. We need to figure out what type of >> data is useful, and which dcmds should handle them. >>> Love opinions on that - especially from the serviceability folks >>> >>> thanks, >>> Karen >> Thanks for the input. >> >> Chris >>> >>> >>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>> >>>> Hi, >>>> >>>> Please review the following changes for the addition of the >>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>> background information. >>>> >>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>> >>>> I expect there will be further restructuring or additional feature >>>> work. More discussion on that below. I'm not sure if that additional >>>> work will be done later with a separately bug filed or with this >>>> initial commit. That's one thing I want to work out with this review. >>>> >>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>> The main purpose of this file is to implement the GC.class_stats and >>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>> to count live objects of each type, thus the name >>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>> require walking the heap, but is implemented in this file because it >>>> leverages the existing KlassInfoTable and related classes >>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>> >>>> KlassInfoTable makes it easy to build a database of all loaded >>>> classes, save additional info gathered for each class, iterate over >>>> them quickly, and also do quick lookups. This exactly what I needed >>>> for this DCMD, thus the reuse. There is some downside to this. For >>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>> a result each has a few fields and methods that are not used for all >>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>> prefer that be done as a next step so I'm not disturbing the existing >>>> DCMDs with this first implementation. >>>> >>>> I added some comments to code only used for GC.class_stats and >>>> GC.class_histogram. I did this when trying to figure them out so I >>>> could better understand how to implement VM.class_hierarchy. I can >>>> take them out if you think they are not appropriate for this commit. >>>> >>>> One other item I like to discuss is whether it is worth adding a >>>> class name argument to this DCMD. That would cause just the >>>> superclasses and subclasses of the named class to be printed. If you >>>> think that is useful, I think it can be added without too much trouble. >>>> >>>> At the moment not much testing has been done other than running the >>>> DCMD and looking at the output. I'll do more once it's clear the code >>>> has "settled". I would like to know if there are any existing tests >>>> for GC.class_stats and GC.class_histogram (there are none in the >>>> "test" directory). If so, possibly one could serve as the basis for a >>>> new test for VM.class_hierarchy. >>>> >>>> thanks, >>>> >>>> Chris >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.auno at oracle.com Fri Jan 9 12:54:35 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 09 Jan 2015 13:54:35 +0100 Subject: RFR(XXS): 8068718: com/sun/jdi/CatchPatternTest.sh should be quarantined Message-ID: <54AFCF8B.5090209@oracle.com> Hi, Could I please have a review of addition to ProblemList. bug: https://bugs.openjdk.java.net/browse/JDK-8068718 webrev: http://cr.openjdk.java.net/~miauno/8068718/webrev.00/ Thanks, Mikael From jaroslav.bachorik at oracle.com Fri Jan 9 12:59:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 09 Jan 2015 13:59:48 +0100 Subject: RFR(XXS): 8068718: com/sun/jdi/CatchPatternTest.sh should be quarantined In-Reply-To: <54AFCF8B.5090209@oracle.com> References: <54AFCF8B.5090209@oracle.com> Message-ID: <54AFD0C4.8040000@oracle.com> Looks good! -JB- On 9.1.2015 13:54, Mikael Auno wrote: > Hi, > > Could I please have a review of addition to ProblemList. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068718 > webrev: http://cr.openjdk.java.net/~miauno/8068718/webrev.00/ > > Thanks, > Mikael > From mikael.auno at oracle.com Fri Jan 9 13:15:44 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 09 Jan 2015 14:15:44 +0100 Subject: RFR(XXS): 8068718: com/sun/jdi/CatchPatternTest.sh should be quarantined In-Reply-To: <54AFD0C4.8040000@oracle.com> References: <54AFCF8B.5090209@oracle.com> <54AFD0C4.8040000@oracle.com> Message-ID: <54AFD480.1040809@oracle.com> Thanks for the review! Mikael On 2015-01-09 13:59, Jaroslav Bachorik wrote: > Looks good! > > -JB- > > On 9.1.2015 13:54, Mikael Auno wrote: >> Hi, >> >> Could I please have a review of addition to ProblemList. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068718 >> webrev: http://cr.openjdk.java.net/~miauno/8068718/webrev.00/ >> >> Thanks, >> Mikael >> > From christian.tornqvist at oracle.com Fri Jan 9 16:37:14 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 9 Jan 2015 11:37:14 -0500 Subject: RFR(XXS): 8068584: Compiler attach tests should be quarantined In-Reply-To: <54AE7BD1.4010907@oracle.com> References: <54AE5621.5010300@oracle.com> <54AE5A33.6040206@oracle.com> <54AE7BD1.4010907@oracle.com> Message-ID: <01b801d02c2a$865b3fc0$9311bf40$@oracle.com> Looks good. Thanks, Christian -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Mattias Tobiasson Sent: Thursday, January 8, 2015 7:45 AM To: Mikael Auno; serviceability-dev at openjdk.java.net Subject: Re: RFR(XXS): 8068584: Compiler attach tests should be quarantined Thanks for the explanation. I have moved the @ignore tags to directly before the first @run tag. webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.01/ Mattias On 01/08/2015 11:21 AM, Mikael Auno wrote: > On 2015-01-08 11:04, Mattias Tobiasson wrote: >> Hi, >> Could I please have a review of this bug quarantine. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068584 >> webrev: http://cr.openjdk.java.net/~ykantser/8068584/webrev.00/ >> >> Thanks, >> Mattias >> > Mattias, > > In the two **/Launcher.java tests, you must place @ignore after the > @library line, otherwise there will be a "Parse Exception: `@library' > must appear before first `@run'". (The error message is, to say the > least, a bit unintuitive until you figure out that "@ignore" is just > an alias for "@run ignore".) > > Mikael From karen.kinnear at oracle.com Fri Jan 9 17:49:56 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 9 Jan 2015 12:49:56 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> Message-ID: Staffan, On Jan 9, 2015, at 7:38 AM, Staffan Larsen wrote: > It?s getting difficult to get all the information into the same output: hierarchy, interfaces, class loaders and modules. I took a stab at it and it could look like this: > > java.lang.Object > |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) > |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) > |--java.lang.Iterable (java.base, 0x00000007c00375f8, iface) > | |--java.util.Collection (java.base, 0x00000007c00375f8, iface) > | | |--java.util.List (java.base, 0x00000007c00375f8, iface) > |--java.util.AbstractCollection (java.base, 0x00000007c00375f8) > | | implements java.util.Collection > | | implements java.lang.Iterable > | |--java.util.AbstractList (java.base, 0x00000007c00375f8) > | | implements java.util.List > | | |--java.util.Arrays$ArrayList (java.base, 0x00000007c00375f8) > | | | implements java.io.Serializable > | | | implements java.util.RandomAccess > > > But this is pushing what can be visualized in one place. > > We will need to add module and class loader information somehow to all the Diagnostic Commands that list classes. In addition we will need a way to see how modules relate to one another. Perhaps it isn?t possible to have all the information in one place, but instead make it possible to cross reference between different diagnostic commands. For example, GC.class_stats could have the module and class loader information, and GC.class_hierarchy would not have to include it. What is missing from making that possible is a unique way of identifying a class (since the name is not unique). All output would need to include that unique identifier and it would be possible to cross reference. The identifier has to be stable during a JVM run, but not between runs. I like where you are going with this. Since a given module is within a class loader, putting the the loader/module/class information in class_stats would be helpful and then having other dcmds just need the class/class loader pair for uniqueness. Not sure what you are using below for unique identifier. I would be tempted to use the class loader hex value since otherwise you are introducing hex values that have no meaning other than as cross-references. And the class/class loader pair is guaranteed uniqueness. For any class loader you could list its hex value thereby giving the information in a single command that gives meaning to the loader value. java.lang.Object/null ... |-sun.misc.Launcher$AppClassLoader/null (0xyyy) |-myapp/0xyyy Just a thought. If you are not enthused - I am ok with your proposal. thanks, Karen > > The above would then become: > > java.lang.Object/0x12345600 > |--java.io.Serializable/0x12345601 > |--java.util.RandomAccess/0x12345602 > |--java.lang.Iterable/0x12345603 > | |--java.util.Collection/0x12345604 > | | |--java.util.List/0x12345605 > |--java.util.AbstractCollection/0x12345606 > | | implements java.util.Collection/0x12345604 > | | implements java.lang.Iterable/0x12345603 > | |--java.util.AbstractList/0x12345607 > | | implements java.util.List/0x12345605 > | | |--java.util.Arrays$ArrayList/0x12345608 > | | | implements java.io.Serializable/0x12345601 > | | | implements java.util.RandomAccess/0x12345602 > > With additions to GC.class_stats: > > Index Super ClassLoader ClassName > 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 > 2 1 0x00000007c0034c48 java.util.List/0x12345605 > 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 > > And GC.class_histogram: > > num #instances #bytes class name > ---------------------------------------------- > 1: 945 117736 java.lang.Object/0x12345600 > 2: 442 50352 java.util.List/0x12345605 > 3: 499 25288 java.util.AbstractList/0x12345607 > > > > /Staffan > >> On 9 jan 2015, at 09:53, Frederic Parain wrote: >> >> >> >> On 01/08/2015 10:29 PM, Chris Plummer wrote: >>> Hi Karen, >>> >>> Comments inline. >>> >>> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>>> Chris, >>>> >>>> Thank you for doing this. I had a couple of questions/comments. >>>> >>>> I like your idea of being able to start with a specific class to show >>>> all subclasses of. >>> Ok. I'll add that. >>>> >>>> I think the way I read the code this shows the superclass hierarchy, >>>> not the superinterfaces. With the addition >>>> of default methods in interfaces, I think we have increased the value >>>> in seeing superinterfaces. >>> It does include interfaces in the output, but not as part of any class >>> hierarchy. Interfaces are just shown as regular classes that inherit >>> from Object. This is the case if one interface extends another, I >>> suppose because "extends" is just interpreted as "implements" in this case. >>>> >>>> So what I personally would find useful would be to be able to start >>>> with a specific class and >>>> find the superclasses and superinterfaces of that class - for the >>>> debugging I do, I usually am >>>> trying to look up and need both sets of information. Today if you run >>>> -XX:+TraceDefaultMethods >>>> there is one sample way to display all the supertypes of a single >>>> type, all the way up. I don't know the >>>> best way to make that consistent with the current output approach, >>>> e.g. using the |- syntax. >>>> >>>> e.g. >>>> Class java.util.Arrays$ArrayList requires default method processing >>>> java/util/Arrays$ArrayList >>>> java/util/AbstractList >>>> java/util/AbstractCollection >>>> java/lang/Object >>>> java/util/Collection >>>> java/lang/Object >>>> java/lang/Iterable >>>> java/lang/Object >>>> java/util/List >>>> java/lang/Object >>>> java/util/Collection >>>> java/lang/Object >>>> java/lang/Iterable >>>> java/lang/Object >>>> java/util/RandomAccess >>>> java/lang/Object >>>> java/io/Serializable >>>> java/lang/Object >>>> >>>> Do you think there could be value to others in the ability to walk up >>>> the hierarchy as well as to >>>> see superclasses and superinterfaces at least from that perspective? >>> This is a inverted from how my dcmd prints the hierarchy, plus also >>> includes interfaces. Inverting the hierarchy means a class is listed >>> with every subclass of the class, which I don't think is desirable. >>> Including interfaces has the same issue, but introduces a new issue even >>> when not inverting the hierarchy. The same interface can be in more than >>> one location in the hierarchy, so there is no avoiding printing it more >>> than once, so we need to decide how to best include interfaces in the >>> output. >> >> It seems to me that we have two very different use cases here, each one >> best served with a different output format: >> >> 1 - Listing of all classes/interfaces hierarchy when the dcmd is >> invoked without arguments: >> -> Chris' output format as described below (with interfaces) >> 2 - Investigation on a particular class or interface when a class >> or interface is passed in argument to the dcmd >> -> Karen's output format, much easier to work with to >> track default methods. Because the output is limited to the >> hierarchy from a single class, there's no class duplication >> in output (single parent class inheritance) and limited >> interfaces duplication. >> >> If the implementations of the two features are too different, we could >> consider having two different dcmds. >> >> My 2 cents, >> >> Fred >> >>> The could just be a simple list right after the class that >>> implements them: >>> >>> java.lang.Object >>> | ... >>> |--MyBaseClass >>> | | implements -> MyInterface1 >>> | | implements -> MyInterface2 >>> | |--MySubClass >>> | implements -> MyInterface1 >>> | implements -> MyInterface2 >>> | ... >>> |--MyInterface1 >>> |--MyInterface2 >>> >>> The "implements" lines could be optional. >>> >>> I know cvm would distinguish between interfaces the Class declared it >>> implemented, and those it inherited from the interfaces it declared it >>> implemented. This was necessary for reflection, and I think also to >>> properly build up interfaces tables. I assume hotspot does something >>> similar. Is there any need for this information to be conveyed in the >>> above output, or just list out every interface implemented, and not >>> worry about how the class acquired it. >>>> Is there value in printing the defining class loader for each class - >>>> maybe optionally? >>> This is already available with GC.class_stats, although not in the >>> default output. I suppose the reality is that it might be better handled >>> by this DCMD. The main puprose of GC.class_stats is to print statistics >>> (counts and sizes), so printing the ClassLoader name there is probably >>> not appropriate, but then it's not really appropriate for >>> VM.class_hierarchy either. I'm not sure how best to handle this. One or >>> both DCMDs possibly should be re-purposed and more clearly define what >>> type of data it displays. >>>> If so, I'm wondering if there might be value in future for the jigsaw >>>> project adding the module for each class - maybe optionally as well? >>> This relates to my above statement. We need to figure out what type of >>> data is useful, and which dcmds should handle them. >>>> Love opinions on that - especially from the serviceability folks >>>> >>>> thanks, >>>> Karen >>> Thanks for the input. >>> >>> Chris >>>> >>>> >>>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the following changes for the addition of the >>>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>>> background information. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>>> >>>>> I expect there will be further restructuring or additional feature >>>>> work. More discussion on that below. I'm not sure if that additional >>>>> work will be done later with a separately bug filed or with this >>>>> initial commit. That's one thing I want to work out with this review. >>>>> >>>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>>> The main purpose of this file is to implement the GC.class_stats and >>>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>>> to count live objects of each type, thus the name >>>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>>> require walking the heap, but is implemented in this file because it >>>>> leverages the existing KlassInfoTable and related classes >>>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>>> >>>>> KlassInfoTable makes it easy to build a database of all loaded >>>>> classes, save additional info gathered for each class, iterate over >>>>> them quickly, and also do quick lookups. This exactly what I needed >>>>> for this DCMD, thus the reuse. There is some downside to this. For >>>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>>> a result each has a few fields and methods that are not used for all >>>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>>> prefer that be done as a next step so I'm not disturbing the existing >>>>> DCMDs with this first implementation. >>>>> >>>>> I added some comments to code only used for GC.class_stats and >>>>> GC.class_histogram. I did this when trying to figure them out so I >>>>> could better understand how to implement VM.class_hierarchy. I can >>>>> take them out if you think they are not appropriate for this commit. >>>>> >>>>> One other item I like to discuss is whether it is worth adding a >>>>> class name argument to this DCMD. That would cause just the >>>>> superclasses and subclasses of the named class to be printed. If you >>>>> think that is useful, I think it can be added without too much trouble. >>>>> >>>>> At the moment not much testing has been done other than running the >>>>> DCMD and looking at the output. I'll do more once it's clear the code >>>>> has "settled". I would like to know if there are any existing tests >>>>> for GC.class_stats and GC.class_histogram (there are none in the >>>>> "test" directory). If so, possibly one could serve as the basis for a >>>>> new test for VM.class_hierarchy. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karen.kinnear at oracle.com Fri Jan 9 17:53:24 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 9 Jan 2015 12:53:24 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54AF96EE.1030808@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> Message-ID: <6726A8FB-0F01-4398-97CB-5E33AABEA0C0@oracle.com> Thanks Frederic for suggesting two different dcmds - they could share a lot of the code logic. If folks generally prefer these as separate dcmds - I can file an rfe to add the inverted one - i.e. start at a given class/interface and tell me its supertypes. thanks, Karen On Jan 9, 2015, at 3:53 AM, Frederic Parain wrote: > > > On 01/08/2015 10:29 PM, Chris Plummer wrote: >> Hi Karen, >> >> Comments inline. >> >> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>> Chris, >>> >>> Thank you for doing this. I had a couple of questions/comments. >>> >>> I like your idea of being able to start with a specific class to show >>> all subclasses of. >> Ok. I'll add that. >>> >>> I think the way I read the code this shows the superclass hierarchy, >>> not the superinterfaces. With the addition >>> of default methods in interfaces, I think we have increased the value >>> in seeing superinterfaces. >> It does include interfaces in the output, but not as part of any class >> hierarchy. Interfaces are just shown as regular classes that inherit >> from Object. This is the case if one interface extends another, I >> suppose because "extends" is just interpreted as "implements" in this case. >>> >>> So what I personally would find useful would be to be able to start >>> with a specific class and >>> find the superclasses and superinterfaces of that class - for the >>> debugging I do, I usually am >>> trying to look up and need both sets of information. Today if you run >>> -XX:+TraceDefaultMethods >>> there is one sample way to display all the supertypes of a single >>> type, all the way up. I don't know the >>> best way to make that consistent with the current output approach, >>> e.g. using the |- syntax. >>> >>> e.g. >>> Class java.util.Arrays$ArrayList requires default method processing >>> java/util/Arrays$ArrayList >>> java/util/AbstractList >>> java/util/AbstractCollection >>> java/lang/Object >>> java/util/Collection >>> java/lang/Object >>> java/lang/Iterable >>> java/lang/Object >>> java/util/List >>> java/lang/Object >>> java/util/Collection >>> java/lang/Object >>> java/lang/Iterable >>> java/lang/Object >>> java/util/RandomAccess >>> java/lang/Object >>> java/io/Serializable >>> java/lang/Object >>> >>> Do you think there could be value to others in the ability to walk up >>> the hierarchy as well as to >>> see superclasses and superinterfaces at least from that perspective? >> This is a inverted from how my dcmd prints the hierarchy, plus also >> includes interfaces. Inverting the hierarchy means a class is listed >> with every subclass of the class, which I don't think is desirable. >> Including interfaces has the same issue, but introduces a new issue even >> when not inverting the hierarchy. The same interface can be in more than >> one location in the hierarchy, so there is no avoiding printing it more >> than once, so we need to decide how to best include interfaces in the >> output. > > It seems to me that we have two very different use cases here, each one > best served with a different output format: > > 1 - Listing of all classes/interfaces hierarchy when the dcmd is > invoked without arguments: > -> Chris' output format as described below (with interfaces) > 2 - Investigation on a particular class or interface when a class > or interface is passed in argument to the dcmd > -> Karen's output format, much easier to work with to > track default methods. Because the output is limited to the > hierarchy from a single class, there's no class duplication > in output (single parent class inheritance) and limited > interfaces duplication. > > If the implementations of the two features are too different, we could > consider having two different dcmds. > > My 2 cents, > > Fred > >> The could just be a simple list right after the class that >> implements them: >> >> java.lang.Object >> | ... >> |--MyBaseClass >> | | implements -> MyInterface1 >> | | implements -> MyInterface2 >> | |--MySubClass >> | implements -> MyInterface1 >> | implements -> MyInterface2 >> | ... >> |--MyInterface1 >> |--MyInterface2 >> >> The "implements" lines could be optional. >> >> I know cvm would distinguish between interfaces the Class declared it >> implemented, and those it inherited from the interfaces it declared it >> implemented. This was necessary for reflection, and I think also to >> properly build up interfaces tables. I assume hotspot does something >> similar. Is there any need for this information to be conveyed in the >> above output, or just list out every interface implemented, and not >> worry about how the class acquired it. >>> Is there value in printing the defining class loader for each class - >>> maybe optionally? >> This is already available with GC.class_stats, although not in the >> default output. I suppose the reality is that it might be better handled >> by this DCMD. The main puprose of GC.class_stats is to print statistics >> (counts and sizes), so printing the ClassLoader name there is probably >> not appropriate, but then it's not really appropriate for >> VM.class_hierarchy either. I'm not sure how best to handle this. One or >> both DCMDs possibly should be re-purposed and more clearly define what >> type of data it displays. >>> If so, I'm wondering if there might be value in future for the jigsaw >>> project adding the module for each class - maybe optionally as well? >> This relates to my above statement. We need to figure out what type of >> data is useful, and which dcmds should handle them. >>> Love opinions on that - especially from the serviceability folks >>> >>> thanks, >>> Karen >> Thanks for the input. >> >> Chris >>> >>> >>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>> >>>> Hi, >>>> >>>> Please review the following changes for the addition of the >>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>> background information. >>>> >>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>> >>>> I expect there will be further restructuring or additional feature >>>> work. More discussion on that below. I'm not sure if that additional >>>> work will be done later with a separately bug filed or with this >>>> initial commit. That's one thing I want to work out with this review. >>>> >>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>> The main purpose of this file is to implement the GC.class_stats and >>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>> to count live objects of each type, thus the name >>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>> require walking the heap, but is implemented in this file because it >>>> leverages the existing KlassInfoTable and related classes >>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>> >>>> KlassInfoTable makes it easy to build a database of all loaded >>>> classes, save additional info gathered for each class, iterate over >>>> them quickly, and also do quick lookups. This exactly what I needed >>>> for this DCMD, thus the reuse. There is some downside to this. For >>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>> a result each has a few fields and methods that are not used for all >>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>> prefer that be done as a next step so I'm not disturbing the existing >>>> DCMDs with this first implementation. >>>> >>>> I added some comments to code only used for GC.class_stats and >>>> GC.class_histogram. I did this when trying to figure them out so I >>>> could better understand how to implement VM.class_hierarchy. I can >>>> take them out if you think they are not appropriate for this commit. >>>> >>>> One other item I like to discuss is whether it is worth adding a >>>> class name argument to this DCMD. That would cause just the >>>> superclasses and subclasses of the named class to be printed. If you >>>> think that is useful, I think it can be added without too much trouble. >>>> >>>> At the moment not much testing has been done other than running the >>>> DCMD and looking at the output. I'll do more once it's clear the code >>>> has "settled". I would like to know if there are any existing tests >>>> for GC.class_stats and GC.class_histogram (there are none in the >>>> "test" directory). If so, possibly one could serve as the basis for a >>>> new test for VM.class_hierarchy. >>>> >>>> thanks, >>>> >>>> Chris >> > > -- > Frederic Parain - Oracle > Grenoble Engineering Center - France > Phone: +33 4 76 18 81 17 > Email: Frederic.Parain at oracle.com From staffan.larsen at oracle.com Fri Jan 9 18:00:01 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 9 Jan 2015 19:00:01 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> Message-ID: <7C557873-336A-42B4-9EB7-84D54C7CD785@oracle.com> > On 9 jan 2015, at 18:49, Karen Kinnear wrote: > > Staffan, > > On Jan 9, 2015, at 7:38 AM, Staffan Larsen wrote: > >> It?s getting difficult to get all the information into the same output: hierarchy, interfaces, class loaders and modules. I took a stab at it and it could look like this: >> >> java.lang.Object >> |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) >> |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) >> |--java.lang.Iterable (java.base, 0x00000007c00375f8, iface) >> | |--java.util.Collection (java.base, 0x00000007c00375f8, iface) >> | | |--java.util.List (java.base, 0x00000007c00375f8, iface) >> |--java.util.AbstractCollection (java.base, 0x00000007c00375f8) >> | | implements java.util.Collection >> | | implements java.lang.Iterable >> | |--java.util.AbstractList (java.base, 0x00000007c00375f8) >> | | implements java.util.List >> | | |--java.util.Arrays$ArrayList (java.base, 0x00000007c00375f8) >> | | | implements java.io.Serializable >> | | | implements java.util.RandomAccess >> >> >> But this is pushing what can be visualized in one place. >> >> We will need to add module and class loader information somehow to all the Diagnostic Commands that list classes. In addition we will need a way to see how modules relate to one another. Perhaps it isn?t possible to have all the information in one place, but instead make it possible to cross reference between different diagnostic commands. For example, GC.class_stats could have the module and class loader information, and GC.class_hierarchy would not have to include it. What is missing from making that possible is a unique way of identifying a class (since the name is not unique). All output would need to include that unique identifier and it would be possible to cross reference. The identifier has to be stable during a JVM run, but not between runs. > I like where you are going with this. Since a given module is within a class loader, putting the the loader/module/class information in class_stats would be helpful and then having > other dcmds just need the class/class loader pair for uniqueness. > > Not sure what you are using below for unique identifier. > I would be tempted to use the class loader hex value since otherwise you are introducing hex values that have no meaning other than as > cross-references. And the class/class loader pair is guaranteed uniqueness. I was actually thinking of a unique identifier for a class (the Klass* for example), not a {class name, class loader} combo, but as you say, the {class name, class loader} combo is also unique and gives more useful information. > For any class loader you could list its hex value thereby giving the information in a single command that gives meaning to the loader value. > > java.lang.Object/null > ... > |-sun.misc.Launcher$AppClassLoader/null (0xyyy) > |-myapp/0xyyy > > Just a thought. If you are not enthused - I am ok with your proposal. This looks good to me. /Staffan > > thanks, > Karen > >> >> The above would then become: >> >> java.lang.Object/0x12345600 >> |--java.io.Serializable/0x12345601 >> |--java.util.RandomAccess/0x12345602 >> |--java.lang.Iterable/0x12345603 >> | |--java.util.Collection/0x12345604 >> | | |--java.util.List/0x12345605 >> |--java.util.AbstractCollection/0x12345606 >> | | implements java.util.Collection/0x12345604 >> | | implements java.lang.Iterable/0x12345603 >> | |--java.util.AbstractList/0x12345607 >> | | implements java.util.List/0x12345605 >> | | |--java.util.Arrays$ArrayList/0x12345608 >> | | | implements java.io.Serializable/0x12345601 >> | | | implements java.util.RandomAccess/0x12345602 >> >> With additions to GC.class_stats: >> >> Index Super ClassLoader ClassName >> 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 >> 2 1 0x00000007c0034c48 java.util.List/0x12345605 >> 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 >> >> And GC.class_histogram: >> >> num #instances #bytes class name >> ---------------------------------------------- >> 1: 945 117736 java.lang.Object/0x12345600 >> 2: 442 50352 java.util.List/0x12345605 >> 3: 499 25288 java.util.AbstractList/0x12345607 >> >> >> >> /Staffan >> >>> On 9 jan 2015, at 09:53, Frederic Parain > wrote: >>> >>> >>> >>> On 01/08/2015 10:29 PM, Chris Plummer wrote: >>>> Hi Karen, >>>> >>>> Comments inline. >>>> >>>> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>>>> Chris, >>>>> >>>>> Thank you for doing this. I had a couple of questions/comments. >>>>> >>>>> I like your idea of being able to start with a specific class to show >>>>> all subclasses of. >>>> Ok. I'll add that. >>>>> >>>>> I think the way I read the code this shows the superclass hierarchy, >>>>> not the superinterfaces. With the addition >>>>> of default methods in interfaces, I think we have increased the value >>>>> in seeing superinterfaces. >>>> It does include interfaces in the output, but not as part of any class >>>> hierarchy. Interfaces are just shown as regular classes that inherit >>>> from Object. This is the case if one interface extends another, I >>>> suppose because "extends" is just interpreted as "implements" in this case. >>>>> >>>>> So what I personally would find useful would be to be able to start >>>>> with a specific class and >>>>> find the superclasses and superinterfaces of that class - for the >>>>> debugging I do, I usually am >>>>> trying to look up and need both sets of information. Today if you run >>>>> -XX:+TraceDefaultMethods >>>>> there is one sample way to display all the supertypes of a single >>>>> type, all the way up. I don't know the >>>>> best way to make that consistent with the current output approach, >>>>> e.g. using the |- syntax. >>>>> >>>>> e.g. >>>>> Class java.util.Arrays$ArrayList requires default method processing >>>>> java/util/Arrays$ArrayList >>>>> java/util/AbstractList >>>>> java/util/AbstractCollection >>>>> java/lang/Object >>>>> java/util/Collection >>>>> java/lang/Object >>>>> java/lang/Iterable >>>>> java/lang/Object >>>>> java/util/List >>>>> java/lang/Object >>>>> java/util/Collection >>>>> java/lang/Object >>>>> java/lang/Iterable >>>>> java/lang/Object >>>>> java/util/RandomAccess >>>>> java/lang/Object >>>>> java/io/Serializable >>>>> java/lang/Object >>>>> >>>>> Do you think there could be value to others in the ability to walk up >>>>> the hierarchy as well as to >>>>> see superclasses and superinterfaces at least from that perspective? >>>> This is a inverted from how my dcmd prints the hierarchy, plus also >>>> includes interfaces. Inverting the hierarchy means a class is listed >>>> with every subclass of the class, which I don't think is desirable. >>>> Including interfaces has the same issue, but introduces a new issue even >>>> when not inverting the hierarchy. The same interface can be in more than >>>> one location in the hierarchy, so there is no avoiding printing it more >>>> than once, so we need to decide how to best include interfaces in the >>>> output. >>> >>> It seems to me that we have two very different use cases here, each one >>> best served with a different output format: >>> >>> 1 - Listing of all classes/interfaces hierarchy when the dcmd is >>> invoked without arguments: >>> -> Chris' output format as described below (with interfaces) >>> 2 - Investigation on a particular class or interface when a class >>> or interface is passed in argument to the dcmd >>> -> Karen's output format, much easier to work with to >>> track default methods. Because the output is limited to the >>> hierarchy from a single class, there's no class duplication >>> in output (single parent class inheritance) and limited >>> interfaces duplication. >>> >>> If the implementations of the two features are too different, we could >>> consider having two different dcmds. >>> >>> My 2 cents, >>> >>> Fred >>> >>>> The could just be a simple list right after the class that >>>> implements them: >>>> >>>> java.lang.Object >>>> | ... >>>> |--MyBaseClass >>>> | | implements -> MyInterface1 >>>> | | implements -> MyInterface2 >>>> | |--MySubClass >>>> | implements -> MyInterface1 >>>> | implements -> MyInterface2 >>>> | ... >>>> |--MyInterface1 >>>> |--MyInterface2 >>>> >>>> The "implements" lines could be optional. >>>> >>>> I know cvm would distinguish between interfaces the Class declared it >>>> implemented, and those it inherited from the interfaces it declared it >>>> implemented. This was necessary for reflection, and I think also to >>>> properly build up interfaces tables. I assume hotspot does something >>>> similar. Is there any need for this information to be conveyed in the >>>> above output, or just list out every interface implemented, and not >>>> worry about how the class acquired it. >>>>> Is there value in printing the defining class loader for each class - >>>>> maybe optionally? >>>> This is already available with GC.class_stats, although not in the >>>> default output. I suppose the reality is that it might be better handled >>>> by this DCMD. The main puprose of GC.class_stats is to print statistics >>>> (counts and sizes), so printing the ClassLoader name there is probably >>>> not appropriate, but then it's not really appropriate for >>>> VM.class_hierarchy either. I'm not sure how best to handle this. One or >>>> both DCMDs possibly should be re-purposed and more clearly define what >>>> type of data it displays. >>>>> If so, I'm wondering if there might be value in future for the jigsaw >>>>> project adding the module for each class - maybe optionally as well? >>>> This relates to my above statement. We need to figure out what type of >>>> data is useful, and which dcmds should handle them. >>>>> Love opinions on that - especially from the serviceability folks >>>>> >>>>> thanks, >>>>> Karen >>>> Thanks for the input. >>>> >>>> Chris >>>>> >>>>> >>>>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the following changes for the addition of the >>>>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>>>> background information. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>>>> >>>>>> I expect there will be further restructuring or additional feature >>>>>> work. More discussion on that below. I'm not sure if that additional >>>>>> work will be done later with a separately bug filed or with this >>>>>> initial commit. That's one thing I want to work out with this review. >>>>>> >>>>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>>>> The main purpose of this file is to implement the GC.class_stats and >>>>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>>>> to count live objects of each type, thus the name >>>>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>>>> require walking the heap, but is implemented in this file because it >>>>>> leverages the existing KlassInfoTable and related classes >>>>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>>>> >>>>>> KlassInfoTable makes it easy to build a database of all loaded >>>>>> classes, save additional info gathered for each class, iterate over >>>>>> them quickly, and also do quick lookups. This exactly what I needed >>>>>> for this DCMD, thus the reuse. There is some downside to this. For >>>>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>>>> a result each has a few fields and methods that are not used for all >>>>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>>>> prefer that be done as a next step so I'm not disturbing the existing >>>>>> DCMDs with this first implementation. >>>>>> >>>>>> I added some comments to code only used for GC.class_stats and >>>>>> GC.class_histogram. I did this when trying to figure them out so I >>>>>> could better understand how to implement VM.class_hierarchy. I can >>>>>> take them out if you think they are not appropriate for this commit. >>>>>> >>>>>> One other item I like to discuss is whether it is worth adding a >>>>>> class name argument to this DCMD. That would cause just the >>>>>> superclasses and subclasses of the named class to be printed. If you >>>>>> think that is useful, I think it can be added without too much trouble. >>>>>> >>>>>> At the moment not much testing has been done other than running the >>>>>> DCMD and looking at the output. I'll do more once it's clear the code >>>>>> has "settled". I would like to know if there are any existing tests >>>>>> for GC.class_stats and GC.class_histogram (there are none in the >>>>>> "test" directory). If so, possibly one could serve as the basis for a >>>>>> new test for VM.class_hierarchy. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at oracle.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jan 9 20:06:38 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 09 Jan 2015 12:06:38 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> Message-ID: <54B034CE.9090805@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Jan 9 20:08:14 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 09 Jan 2015 12:08:14 -0800 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> Message-ID: <54B0352E.6010903@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jan 12 02:45:41 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Jan 2015 12:45:41 +1000 Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build In-Reply-To: <54AFE70C.3070208@oracle.com> References: <54AFE70C.3070208@oracle.com> Message-ID: <54B33555.8030206@oracle.com> Hi Erik, On 10/01/2015 12:34 AM, Erik Joelsson wrote: > Hello, > > Please review this patch which fixes the verify-modules target when > running bootcycle build, and also reenables verify-modules when running > "make images". > > There were two problems: > > * The bootcycle build configuration was broken so that both the normal > and the bootcycle build used the same HOTSPOT_DIST directory. The > consequence of this was that verify-modules worked when run on its own, > but not if bootcycle-images had been run before. This is fixed in > bootcycle-spec.gmk.in. > > * Since javac in JDK 9 no longer emits classes for implicitly compiled > sources, certain classes in sa-jdi.jar were not compiled during the > bootcycle build. I fixed this by adding the missing classes to sa.files. > Not having the classes there might have been intentional (in at least > some cases), but since they were compiled anyway, I felt it safer to > just add them to the list to fix this issue. If these classes shouldn't > be included, then they need to be properly removed in a followup fix. SA is owned by serviceability - cc'd. Changes seem okay as a solution to immediate problem, but I don't think anyone expects the IA64 stuff to still be needed. It is on the todo list to eradicate IA64 IIRC. Looks like there is limited awareness of the need to keep sa.files up to date. :( Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8067479 > Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/ > > Since this is changing hotspot, I assume it will need to go in through a > hotspot forest. Which one? > > /Erik From staffan.larsen at oracle.com Mon Jan 12 08:49:18 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 12 Jan 2015 09:49:18 +0100 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <54B0352E.6010903@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <8E0F6A54-42DB-4174-83F7-E78F9376FEA2@oracle.com> <54B0352E.6010903@oracle.com> Message-ID: <0B379D67-A8BF-458D-883C-5B43B90AB03D@oracle.com> > On 9 jan 2015, at 21:08, Chris Plummer wrote: > > On 1/9/15 4:38 AM, Staffan Larsen wrote: >> It?s getting difficult to get all the information into the same output: hierarchy, interfaces, class loaders and modules. I took a stab at it and it could look like this: >> >> java.lang.Object >> |--java.io.Serializable (java.base, 0x00000007c00375f8, iface) >> |--java.util.RandomAccess (java.base, 0x00000007c00375f8, iface) >> |--java.lang.Iterable (java.base, 0x00000007c00375f8, iface) >> | |--java.util.Collection (java.base, 0x00000007c00375f8, iface) >> | | |--java.util.List (java.base, 0x00000007c00375f8, iface) >> |--java.util.AbstractCollection (java.base, 0x00000007c00375f8) >> | | implements java.util.Collection >> | | implements java.lang.Iterable >> | |--java.util.AbstractList (java.base, 0x00000007c00375f8) >> | | implements java.util.List >> | | |--java.util.Arrays$ArrayList (java.base, 0x00000007c00375f8) >> | | | implements java.io.Serializable >> | | | implements java.util.RandomAccess > For the most part I like this. The one part I'm not too fond of is hex long which I assume represents the ClassLoader. Maybe we could just use a simple index, and at the end of the dump include a table of the referenced ClassLoaders. Possibly just hijack what VM.classloader_stats outputs, but include the simple index in the first column. >> >> >> But this is pushing what can be visualized in one place. >> >> We will need to add module and class loader information somehow to all the Diagnostic Commands that list classes. In addition we will need a way to see how modules relate to one another. Perhaps it isn?t possible to have all the information in one place, but instead make it possible to cross reference between different diagnostic commands. For example, GC.class_stats could have the module and class loader information, and GC.class_hierarchy would not have to include it. What is missing from making that possible is a unique way of identifying a class (since the name is not unique). All output would need to include that unique identifier and it would be possible to cross reference. The identifier has to be stable during a JVM run, but not between runs. > I don't know if there is some sort of simple stable ID for a class other than the address of the Klass instance. And of course this assumes there isn't any class unloading going on that could result in reuse of the address. Is that acceptable? Yeah, I was thinking about the Klass*, but as you say it isn?t guaranteed to be unique over time. Karen suggested using {class loader, class} which has the same problem, but includes more useful information, so I think that is preferable. (Ideally we should have a unique id assigned to classes and class loaders when they are created). >> >> The above would then become: >> >> java.lang.Object/0x12345600 >> |--java.io.Serializable/0x12345601 >> |--java.util.RandomAccess/0x12345602 >> |--java.lang.Iterable/0x12345603 >> | |--java.util.Collection/0x12345604 >> | | |--java.util.List/0x12345605 >> |--java.util.AbstractCollection/0x12345606 >> | | implements java.util.Collection/0x12345604 >> | | implements java.lang.Iterable/0x12345603 >> | |--java.util.AbstractList/0x12345607 >> | | implements java.util.List/0x12345605 >> | | |--java.util.Arrays$ArrayList/0x12345608 >> | | | implements java.io.Serializable/0x12345601 >> | | | implements java.util.RandomAccess/0x12345602 >> >> With additions to GC.class_stats: >> >> Index Super ClassLoader ClassName >> 1 -1 0x00000007c0034c48 java.lang.Object/0x12345600 >> 2 1 0x00000007c0034c48 java.util.List/0x12345605 >> 3 31 0x00000007c0034c48 java.util.AbstractList/0x12345607 >> >> And GC.class_histogram: >> >> num #instances #bytes class name >> ---------------------------------------------- >> 1: 945 117736 java.lang.Object/0x12345600 >> 2: 442 50352 java.util.List/0x12345605 >> 3: 499 25288 java.util.AbstractList/0x12345607 > Would it be better for the class identifier to be in a separate column from the class name, or is combining them intentional? In any case, it's easy enough to add to all of the above assuming we are talking about an existing value such as the address of the Klass instance. Perhaps better to separate them, yes. /Staffan > > Chris >> >> >> >> /Staffan >> >>> On 9 jan 2015, at 09:53, Frederic Parain > wrote: >>> >>> >>> >>> On 01/08/2015 10:29 PM, Chris Plummer wrote: >>>> Hi Karen, >>>> >>>> Comments inline. >>>> >>>> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>>>> Chris, >>>>> >>>>> Thank you for doing this. I had a couple of questions/comments. >>>>> >>>>> I like your idea of being able to start with a specific class to show >>>>> all subclasses of. >>>> Ok. I'll add that. >>>>> >>>>> I think the way I read the code this shows the superclass hierarchy, >>>>> not the superinterfaces. With the addition >>>>> of default methods in interfaces, I think we have increased the value >>>>> in seeing superinterfaces. >>>> It does include interfaces in the output, but not as part of any class >>>> hierarchy. Interfaces are just shown as regular classes that inherit >>>> from Object. This is the case if one interface extends another, I >>>> suppose because "extends" is just interpreted as "implements" in this case. >>>>> >>>>> So what I personally would find useful would be to be able to start >>>>> with a specific class and >>>>> find the superclasses and superinterfaces of that class - for the >>>>> debugging I do, I usually am >>>>> trying to look up and need both sets of information. Today if you run >>>>> -XX:+TraceDefaultMethods >>>>> there is one sample way to display all the supertypes of a single >>>>> type, all the way up. I don't know the >>>>> best way to make that consistent with the current output approach, >>>>> e.g. using the |- syntax. >>>>> >>>>> e.g. >>>>> Class java.util.Arrays$ArrayList requires default method processing >>>>> java/util/Arrays$ArrayList >>>>> java/util/AbstractList >>>>> java/util/AbstractCollection >>>>> java/lang/Object >>>>> java/util/Collection >>>>> java/lang/Object >>>>> java/lang/Iterable >>>>> java/lang/Object >>>>> java/util/List >>>>> java/lang/Object >>>>> java/util/Collection >>>>> java/lang/Object >>>>> java/lang/Iterable >>>>> java/lang/Object >>>>> java/util/RandomAccess >>>>> java/lang/Object >>>>> java/io/Serializable >>>>> java/lang/Object >>>>> >>>>> Do you think there could be value to others in the ability to walk up >>>>> the hierarchy as well as to >>>>> see superclasses and superinterfaces at least from that perspective? >>>> This is a inverted from how my dcmd prints the hierarchy, plus also >>>> includes interfaces. Inverting the hierarchy means a class is listed >>>> with every subclass of the class, which I don't think is desirable. >>>> Including interfaces has the same issue, but introduces a new issue even >>>> when not inverting the hierarchy. The same interface can be in more than >>>> one location in the hierarchy, so there is no avoiding printing it more >>>> than once, so we need to decide how to best include interfaces in the >>>> output. >>> >>> It seems to me that we have two very different use cases here, each one >>> best served with a different output format: >>> >>> 1 - Listing of all classes/interfaces hierarchy when the dcmd is >>> invoked without arguments: >>> -> Chris' output format as described below (with interfaces) >>> 2 - Investigation on a particular class or interface when a class >>> or interface is passed in argument to the dcmd >>> -> Karen's output format, much easier to work with to >>> track default methods. Because the output is limited to the >>> hierarchy from a single class, there's no class duplication >>> in output (single parent class inheritance) and limited >>> interfaces duplication. >>> >>> If the implementations of the two features are too different, we could >>> consider having two different dcmds. >>> >>> My 2 cents, >>> >>> Fred >>> >>>> The could just be a simple list right after the class that >>>> implements them: >>>> >>>> java.lang.Object >>>> | ... >>>> |--MyBaseClass >>>> | | implements -> MyInterface1 >>>> | | implements -> MyInterface2 >>>> | |--MySubClass >>>> | implements -> MyInterface1 >>>> | implements -> MyInterface2 >>>> | ... >>>> |--MyInterface1 >>>> |--MyInterface2 >>>> >>>> The "implements" lines could be optional. >>>> >>>> I know cvm would distinguish between interfaces the Class declared it >>>> implemented, and those it inherited from the interfaces it declared it >>>> implemented. This was necessary for reflection, and I think also to >>>> properly build up interfaces tables. I assume hotspot does something >>>> similar. Is there any need for this information to be conveyed in the >>>> above output, or just list out every interface implemented, and not >>>> worry about how the class acquired it. >>>>> Is there value in printing the defining class loader for each class - >>>>> maybe optionally? >>>> This is already available with GC.class_stats, although not in the >>>> default output. I suppose the reality is that it might be better handled >>>> by this DCMD. The main puprose of GC.class_stats is to print statistics >>>> (counts and sizes), so printing the ClassLoader name there is probably >>>> not appropriate, but then it's not really appropriate for >>>> VM.class_hierarchy either. I'm not sure how best to handle this. One or >>>> both DCMDs possibly should be re-purposed and more clearly define what >>>> type of data it displays. >>>>> If so, I'm wondering if there might be value in future for the jigsaw >>>>> project adding the module for each class - maybe optionally as well? >>>> This relates to my above statement. We need to figure out what type of >>>> data is useful, and which dcmds should handle them. >>>>> Love opinions on that - especially from the serviceability folks >>>>> >>>>> thanks, >>>>> Karen >>>> Thanks for the input. >>>> >>>> Chris >>>>> >>>>> >>>>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Please review the following changes for the addition of the >>>>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>>>> background information. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>>>> >>>>>> I expect there will be further restructuring or additional feature >>>>>> work. More discussion on that below. I'm not sure if that additional >>>>>> work will be done later with a separately bug filed or with this >>>>>> initial commit. That's one thing I want to work out with this review. >>>>>> >>>>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>>>> The main purpose of this file is to implement the GC.class_stats and >>>>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>>>> to count live objects of each type, thus the name >>>>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>>>> require walking the heap, but is implemented in this file because it >>>>>> leverages the existing KlassInfoTable and related classes >>>>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>>>> >>>>>> KlassInfoTable makes it easy to build a database of all loaded >>>>>> classes, save additional info gathered for each class, iterate over >>>>>> them quickly, and also do quick lookups. This exactly what I needed >>>>>> for this DCMD, thus the reuse. There is some downside to this. For >>>>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>>>> a result each has a few fields and methods that are not used for all >>>>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>>>> prefer that be done as a next step so I'm not disturbing the existing >>>>>> DCMDs with this first implementation. >>>>>> >>>>>> I added some comments to code only used for GC.class_stats and >>>>>> GC.class_histogram. I did this when trying to figure them out so I >>>>>> could better understand how to implement VM.class_hierarchy. I can >>>>>> take them out if you think they are not appropriate for this commit. >>>>>> >>>>>> One other item I like to discuss is whether it is worth adding a >>>>>> class name argument to this DCMD. That would cause just the >>>>>> superclasses and subclasses of the named class to be printed. If you >>>>>> think that is useful, I think it can be added without too much trouble. >>>>>> >>>>>> At the moment not much testing has been done other than running the >>>>>> DCMD and looking at the output. I'll do more once it's clear the code >>>>>> has "settled". I would like to know if there are any existing tests >>>>>> for GC.class_stats and GC.class_histogram (there are none in the >>>>>> "test" directory). If so, possibly one could serve as the basis for a >>>>>> new test for VM.class_hierarchy. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>> >>> -- >>> Frederic Parain - Oracle >>> Grenoble Engineering Center - France >>> Phone: +33 4 76 18 81 17 >>> Email: Frederic.Parain at oracle.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Mon Jan 12 10:33:47 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 12 Jan 2015 11:33:47 +0100 Subject: RFR 8062450: Timeout in LowMemoryTest.java In-Reply-To: <54AE4B8F.6000209@oracle.com> References: <54AD68F4.20709@oracle.com> <54ADEC87.3090407@oracle.com> <54AE4B8F.6000209@oracle.com> Message-ID: <54B3A30B.3000106@oracle.com> On 8.1.2015 10:19, Jaroslav Bachorik wrote: > On 8.1.2015 03:33, David Holmes wrote: >> On 8/01/2015 3:12 AM, Jaroslav Bachorik wrote: >>> Please, review the following test change >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062450 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.00 >>> >>> The test times out when "-XX:+ExplicitGCInvokesConcurrent" is specified. >>> The test relies on the MemoryMXBean.gc() invocation returning only after >>> the GC run has been completed. This is not true when >>> "-XX:+ExplicitGCInvokesConcurrent" is set and the test timing is thrown >>> off-balance resulting in deadlock. >>> >>> The proposed solution is to add an appropriate "@requires" JTREG stance >>> to prevent running this test with incompatible settings. >> >> Seems okay - though I'm wondering whether: >> >> @requires vm.opt.ExplicitGCInvokesConcurrent != "true" >> >> has the same affect? > > Seems to have the same effect - I tried running the test with > "-XX:+ExplicitGCInvokesConcurrent", "-XX:-ExplicitGCInvokesConcurrent" > and without this flag all together and the test was properly ignored > only when "-XX:+ExplicitGCInvokesConcurrent" is used. > >> >> And do you also need to guard against >> ExplicitGCInvokesConcurrentAndUnloadsClasses ? > > Didn't see this flag used in testing but it would be wise to guard > against it as well, thanks. I would throw in DisableExplicitGC too. Update: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.01 -JB- > > -JB- > >> >> David >> >>> Thanks, >>> >>> -JB- > From dmitry.samersoff at oracle.com Mon Jan 12 13:49:53 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 12 Jan 2015 16:49:53 +0300 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData Message-ID: <54B3D101.4090309@oracle.com> Hi Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ The fix explicitly checks for UsePerfData and if it's false make Perf:detach a NOP. -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 jeremymanson at google.com Mon Jan 12 18:32:45 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 12 Jan 2015 10:32:45 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo Message-ID: Hi folks, This was long forgotten, seems to have been lost in the shuffle. I've done it, since we could use it, too: https://bugs.openjdk.java.net/browse/JDK-6588467 http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ Since it is an API change (albeit an uncontroversial one), it will have to go through whatever the super-secret API change review process is that you folks do. Thanks! Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From karen.kinnear at oracle.com Mon Jan 12 19:54:37 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 12 Jan 2015 14:54:37 -0500 Subject: [9] RFR (M) 8054888: Runtime: Add Diagnostic Command that prints the class hierarchy In-Reply-To: <6726A8FB-0F01-4398-97CB-5E33AABEA0C0@oracle.com> References: <54ADC152.6000706@oracle.com> <632357BC-AC93-4DB6-9D25-ADB4B05E09DD@oracle.com> <54AEF6B6.6020404@oracle.com> <54AF96EE.1030808@oracle.com> <6726A8FB-0F01-4398-97CB-5E33AABEA0C0@oracle.com> Message-ID: <177D289A-DCAC-4854-9F5F-792A54802FFB@oracle.com> Chris, I filed JDK-8068830 to capture the request I had to print the super types of a given class - so you don't have to deal with that as part of this exercise. thanks, Karen On Jan 9, 2015, at 12:53 PM, Karen Kinnear wrote: > Thanks Frederic for suggesting two different dcmds - they could > share a lot of the code logic. > > If folks generally prefer these as separate dcmds - I can file an > rfe to add the inverted one - i.e. start at a given class/interface and > tell me its supertypes. > > thanks, > Karen > > On Jan 9, 2015, at 3:53 AM, Frederic Parain wrote: > >> >> >> On 01/08/2015 10:29 PM, Chris Plummer wrote: >>> Hi Karen, >>> >>> Comments inline. >>> >>> On 1/8/15 8:07 AM, Karen Kinnear wrote: >>>> Chris, >>>> >>>> Thank you for doing this. I had a couple of questions/comments. >>>> >>>> I like your idea of being able to start with a specific class to show >>>> all subclasses of. >>> Ok. I'll add that. >>>> >>>> I think the way I read the code this shows the superclass hierarchy, >>>> not the superinterfaces. With the addition >>>> of default methods in interfaces, I think we have increased the value >>>> in seeing superinterfaces. >>> It does include interfaces in the output, but not as part of any class >>> hierarchy. Interfaces are just shown as regular classes that inherit >>> from Object. This is the case if one interface extends another, I >>> suppose because "extends" is just interpreted as "implements" in this case. >>>> >>>> So what I personally would find useful would be to be able to start >>>> with a specific class and >>>> find the superclasses and superinterfaces of that class - for the >>>> debugging I do, I usually am >>>> trying to look up and need both sets of information. Today if you run >>>> -XX:+TraceDefaultMethods >>>> there is one sample way to display all the supertypes of a single >>>> type, all the way up. I don't know the >>>> best way to make that consistent with the current output approach, >>>> e.g. using the |- syntax. >>>> >>>> e.g. >>>> Class java.util.Arrays$ArrayList requires default method processing >>>> java/util/Arrays$ArrayList >>>> java/util/AbstractList >>>> java/util/AbstractCollection >>>> java/lang/Object >>>> java/util/Collection >>>> java/lang/Object >>>> java/lang/Iterable >>>> java/lang/Object >>>> java/util/List >>>> java/lang/Object >>>> java/util/Collection >>>> java/lang/Object >>>> java/lang/Iterable >>>> java/lang/Object >>>> java/util/RandomAccess >>>> java/lang/Object >>>> java/io/Serializable >>>> java/lang/Object >>>> >>>> Do you think there could be value to others in the ability to walk up >>>> the hierarchy as well as to >>>> see superclasses and superinterfaces at least from that perspective? >>> This is a inverted from how my dcmd prints the hierarchy, plus also >>> includes interfaces. Inverting the hierarchy means a class is listed >>> with every subclass of the class, which I don't think is desirable. >>> Including interfaces has the same issue, but introduces a new issue even >>> when not inverting the hierarchy. The same interface can be in more than >>> one location in the hierarchy, so there is no avoiding printing it more >>> than once, so we need to decide how to best include interfaces in the >>> output. >> >> It seems to me that we have two very different use cases here, each one >> best served with a different output format: >> >> 1 - Listing of all classes/interfaces hierarchy when the dcmd is >> invoked without arguments: >> -> Chris' output format as described below (with interfaces) >> 2 - Investigation on a particular class or interface when a class >> or interface is passed in argument to the dcmd >> -> Karen's output format, much easier to work with to >> track default methods. Because the output is limited to the >> hierarchy from a single class, there's no class duplication >> in output (single parent class inheritance) and limited >> interfaces duplication. >> >> If the implementations of the two features are too different, we could >> consider having two different dcmds. >> >> My 2 cents, >> >> Fred >> >>> The could just be a simple list right after the class that >>> implements them: >>> >>> java.lang.Object >>> | ... >>> |--MyBaseClass >>> | | implements -> MyInterface1 >>> | | implements -> MyInterface2 >>> | |--MySubClass >>> | implements -> MyInterface1 >>> | implements -> MyInterface2 >>> | ... >>> |--MyInterface1 >>> |--MyInterface2 >>> >>> The "implements" lines could be optional. >>> >>> I know cvm would distinguish between interfaces the Class declared it >>> implemented, and those it inherited from the interfaces it declared it >>> implemented. This was necessary for reflection, and I think also to >>> properly build up interfaces tables. I assume hotspot does something >>> similar. Is there any need for this information to be conveyed in the >>> above output, or just list out every interface implemented, and not >>> worry about how the class acquired it. >>>> Is there value in printing the defining class loader for each class - >>>> maybe optionally? >>> This is already available with GC.class_stats, although not in the >>> default output. I suppose the reality is that it might be better handled >>> by this DCMD. The main puprose of GC.class_stats is to print statistics >>> (counts and sizes), so printing the ClassLoader name there is probably >>> not appropriate, but then it's not really appropriate for >>> VM.class_hierarchy either. I'm not sure how best to handle this. One or >>> both DCMDs possibly should be re-purposed and more clearly define what >>> type of data it displays. >>>> If so, I'm wondering if there might be value in future for the jigsaw >>>> project adding the module for each class - maybe optionally as well? >>> This relates to my above statement. We need to figure out what type of >>> data is useful, and which dcmds should handle them. >>>> Love opinions on that - especially from the serviceability folks >>>> >>>> thanks, >>>> Karen >>> Thanks for the input. >>> >>> Chris >>>> >>>> >>>> On Jan 7, 2015, at 6:29 PM, Chris Plummer wrote: >>>> >>>>> Hi, >>>>> >>>>> Please review the following changes for the addition of the >>>>> VM.class_hierarchy DCMD. Please read the bug first for some >>>>> background information. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~cjplummer/8054888/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054888 >>>>> >>>>> I expect there will be further restructuring or additional feature >>>>> work. More discussion on that below. I'm not sure if that additional >>>>> work will be done later with a separately bug filed or with this >>>>> initial commit. That's one thing I want to work out with this review. >>>>> >>>>> Currently the bulk of the DCMD is implemented in heapInspection.cpp. >>>>> The main purpose of this file is to implement the GC.class_stats and >>>>> GC.class_histogram DCMDs. Both of them require walking the java heap >>>>> to count live objects of each type, thus the name >>>>> "heapInspection.cpp". This new VM.class_hierarchy DCMD does not >>>>> require walking the heap, but is implemented in this file because it >>>>> leverages the existing KlassInfoTable and related classes >>>>> (KlassInfoEntry, KlassInfoBucket, and KlassClosure). >>>>> >>>>> KlassInfoTable makes it easy to build a database of all loaded >>>>> classes, save additional info gathered for each class, iterate over >>>>> them quickly, and also do quick lookups. This exactly what I needed >>>>> for this DCMD, thus the reuse. There is some downside to this. For >>>>> starters, heapInspection.cpp is not the proper place for a DCMD that >>>>> has nothing to do with heap inspection. Also, KlassInfoEntry is being >>>>> overloaded now to support 3 different DCMDs, as is KlassInfoTable. As >>>>> a result each has a few fields and methods that are not used for all >>>>> 3 DCMDs. Some subclassing might be in order here, but I'm not sure if >>>>> it's worth it. Opinions welcomed. If I am going to refactor, I would >>>>> prefer that be done as a next step so I'm not disturbing the existing >>>>> DCMDs with this first implementation. >>>>> >>>>> I added some comments to code only used for GC.class_stats and >>>>> GC.class_histogram. I did this when trying to figure them out so I >>>>> could better understand how to implement VM.class_hierarchy. I can >>>>> take them out if you think they are not appropriate for this commit. >>>>> >>>>> One other item I like to discuss is whether it is worth adding a >>>>> class name argument to this DCMD. That would cause just the >>>>> superclasses and subclasses of the named class to be printed. If you >>>>> think that is useful, I think it can be added without too much trouble. >>>>> >>>>> At the moment not much testing has been done other than running the >>>>> DCMD and looking at the output. I'll do more once it's clear the code >>>>> has "settled". I would like to know if there are any existing tests >>>>> for GC.class_stats and GC.class_histogram (there are none in the >>>>> "test" directory). If so, possibly one could serve as the basis for a >>>>> new test for VM.class_hierarchy. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >> >> -- >> Frederic Parain - Oracle >> Grenoble Engineering Center - France >> Phone: +33 4 76 18 81 17 >> Email: Frederic.Parain at oracle.com > From david.holmes at oracle.com Tue Jan 13 02:39:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jan 2015 12:39:33 +1000 Subject: RFR 8062450: Timeout in LowMemoryTest.java In-Reply-To: <54B3A30B.3000106@oracle.com> References: <54AD68F4.20709@oracle.com> <54ADEC87.3090407@oracle.com> <54AE4B8F.6000209@oracle.com> <54B3A30B.3000106@oracle.com> Message-ID: <54B48565.8050106@oracle.com> Seems okay. Thanks, David On 12/01/2015 8:33 PM, Jaroslav Bachorik wrote: > On 8.1.2015 10:19, Jaroslav Bachorik wrote: >> On 8.1.2015 03:33, David Holmes wrote: >>> On 8/01/2015 3:12 AM, Jaroslav Bachorik wrote: >>>> Please, review the following test change >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062450 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.00 >>>> >>>> The test times out when "-XX:+ExplicitGCInvokesConcurrent" is >>>> specified. >>>> The test relies on the MemoryMXBean.gc() invocation returning only >>>> after >>>> the GC run has been completed. This is not true when >>>> "-XX:+ExplicitGCInvokesConcurrent" is set and the test timing is thrown >>>> off-balance resulting in deadlock. >>>> >>>> The proposed solution is to add an appropriate "@requires" JTREG stance >>>> to prevent running this test with incompatible settings. >>> >>> Seems okay - though I'm wondering whether: >>> >>> @requires vm.opt.ExplicitGCInvokesConcurrent != "true" >>> >>> has the same affect? >> >> Seems to have the same effect - I tried running the test with >> "-XX:+ExplicitGCInvokesConcurrent", "-XX:-ExplicitGCInvokesConcurrent" >> and without this flag all together and the test was properly ignored >> only when "-XX:+ExplicitGCInvokesConcurrent" is used. >> >>> >>> And do you also need to guard against >>> ExplicitGCInvokesConcurrentAndUnloadsClasses ? >> >> Didn't see this flag used in testing but it would be wise to guard >> against it as well, thanks. I would throw in DisableExplicitGC too. > > Update: http://cr.openjdk.java.net/~jbachorik/8062450/webrev.01 > > -JB- > >> >> -JB- >> >>> >>> David >>> >>>> Thanks, >>>> >>>> -JB- >> > From david.holmes at oracle.com Tue Jan 13 05:10:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jan 2015 15:10:42 +1000 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B3D101.4090309@oracle.com> References: <54B3D101.4090309@oracle.com> Message-ID: <54B4A8D2.70700@oracle.com> Hi Dmitry, Short version: okay but I'm going to file a bug to have sun.misc.Perf fixed properly. Long version ... read below :) Thanks, David On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ > > The fix explicitly checks for UsePerfData and if it's false make > Perf:detach a NOP. That sidesteps the assertion failure but there is a bigger semantic issue here I think - which is why the bug has remained open for so long. UsePerfData can disable a part of the backend of the "perf" functionality used via sun.misc.Perf, but sun.misc.Perf is completely oblivious to that. It isn't even really clear what UsePerfData pertains to. It impacts PerfMemory turning a number of methods into no-ops - but it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. What is a no-op is the initialization of PerfMemory (perfMemory_init) during VM startup, and also the teardown (perfMemory_exit) during VM shutdown (via at_exit handler). So the VM responds to the -UsePerfData flag (in part) by not initializing the PerfMemory subsystem, but the PerfMemory public apis are still enabled and invoked from the JDK code. That doesn't make sense to me - we should fail to attach and in doing so not put in place the Cleaner code that will attempt the detach. But sun.misc.Perf doesn't understand that anything can fail. :( Your workaround avoids calling PerfMemory::detach from the Perf_detach code by checking UsePerfData, but arguably the check should be inside PerfMemory::detach operation (which unfortunately is OS specific). > > -Dmitry > From david.holmes at oracle.com Tue Jan 13 05:28:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jan 2015 15:28:16 +1000 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: References: Message-ID: <54B4ACF0.1000900@oracle.com> Hi Jeremy, On 13/01/2015 4:32 AM, Jeremy Manson wrote: > Hi folks, > > This was long forgotten, seems to have been lost in the shuffle. I've > done it, since we could use it, too: > > https://bugs.openjdk.java.net/browse/JDK-6588467 > http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ Codewise this all appears fine to me. > Since it is an API change (albeit an uncontroversial one), it will have > to go through whatever the super-secret API change review process is > that you folks do. Not sure if this just needs an API tweak or a JMX spec revision. If the latter then this might be a big deal. But I'll leave that to the official serviceability folk :) Cheers, David > Thanks! > > Jeremy From jeremymanson at google.com Tue Jan 13 06:01:16 2015 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 12 Jan 2015 22:01:16 -0800 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54B4ACF0.1000900@oracle.com> References: <54B4ACF0.1000900@oracle.com> Message-ID: Thanks, David. The red tape sounds awful. Hopefully, it isn't as bad as all that. On Mon, Jan 12, 2015 at 9:28 PM, David Holmes wrote: > Hi Jeremy, > > On 13/01/2015 4:32 AM, Jeremy Manson wrote: > >> Hi folks, >> >> This was long forgotten, seems to have been lost in the shuffle. I've >> done it, since we could use it, too: >> >> https://bugs.openjdk.java.net/browse/JDK-6588467 >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ >> > > Codewise this all appears fine to me. > > Since it is an API change (albeit an uncontroversial one), it will have >> to go through whatever the super-secret API change review process is >> that you folks do. >> > > Not sure if this just needs an API tweak or a JMX spec revision. If the > latter then this might be a big deal. But I'll leave that to the official > serviceability folk :) > > Cheers, > David > > Thanks! >> >> Jeremy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Tue Jan 13 07:10:30 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 Jan 2015 08:10:30 +0100 Subject: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo In-Reply-To: <54B4ACF0.1000900@oracle.com> References: <54B4ACF0.1000900@oracle.com> Message-ID: <904297DE-D155-4FC1-AE9B-4B19F001523F@oracle.com> > On 13 jan 2015, at 06:28, David Holmes wrote: > > Hi Jeremy, > > On 13/01/2015 4:32 AM, Jeremy Manson wrote: >> Hi folks, >> >> This was long forgotten, seems to have been lost in the shuffle. I've >> done it, since we could use it, too: >> >> https://bugs.openjdk.java.net/browse/JDK-6588467 >> http://cr.openjdk.java.net/~jmanson/6588467/webrev.00/ > > Codewise this all appears fine to me. Thanks for doing this. I have only scanned the code, but did not see any test. Could you please add tests for the new API? >> Since it is an API change (albeit an uncontroversial one), it will have >> to go through whatever the super-secret API change review process is >> that you folks do. > > Not sure if this just needs an API tweak or a JMX spec revision. If the latter then this might be a big deal. But I'll leave that to the official serviceability folk :) No spec revision is needed, same process as for all API changes. Unfortunately I don?t have the time to drive that, so hoping someone else can jump in. /Staffan > > Cheers, > David > >> Thanks! >> >> Jeremy From staffan.larsen at oracle.com Tue Jan 13 07:26:09 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 Jan 2015 08:26:09 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54AE851F.3000905@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> Message-ID: <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> > On 8 jan 2015, at 14:24, Jaroslav Bachorik wrote: > > On 8.1.2015 12:12, David Holmes wrote: >> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>> On 8.1.2015 03:45, David Holmes wrote: >>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>> Please, review the following change. >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>> >>>>>>> This patch is a precursor for implementing >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>> part >>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>> >>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>> separate ManagedFlags class and the codebease is adjusted to use this >>>>>>> class. >>>>>> >>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>> platform specific variants of "set flag" ?? >>>>> >>>>> It has just been moved from the corresponding attachListener_.cpp >>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>> dependent"? >>>> >>>> Yes it does and it mostly made sense inside the already pd >>>> attachListener implementations, but it isn't obvious to me that it makes >>>> sense in the ManagedFlag context. It is the choice about whether the >>>> flag can be changed that is "pd" not the actual setting and those >>>> choices are inherent to the attachListener mechanism they are not >>> >>> Why would the ability to set Solaris specific flags via DTrace be >>> specific to the attachListener mechanism? Also, AFAICS here it is the >>> mechanism of setting the flag which is "pd" and not the choice >>> (DTrace::* vs CommandLineFlags::*) >> >> The attachListener allows for manipulating VM flags if the attach >> mechanism is used. In the Solaris case it turns on some DTrace flags. >> The attach mechanism factors that into a pd_set_flags method that is >> called for a given AttachOperation and so allows per platform behaviour. >> But this is all part of the attach mechanism it isn't part of some >> general flag management process. > > I think I see the problem. Sorry it took me so long. > > But, why the DTrace flags are only allowed to be set via the attachListener? Can we allow their manipulation via com.sun.Flag? Or they need to stay restricted to the attach mechanism only for whatever reason? I don?t think there is any reason these Dtrace flags should only ba changeable by the attach mechanism. They could just as well be changed from JMX or jcmd. I guess the code is in attach because attach was the only way of changing flags at the time. The only difference I can see for these Dtrace flags compared to other flags is that some action needs to be taken if the flag is changed (calls to DTrace::set_extended_dprobes()). I also think the Dtrace flags should be marked as ?manageable.? /Staffan > >> >>>> inherent to ManagedFlags - so this refactoring seems wrong to me. What >>>> exactly is ManagedFlag supposed to represent? >>> >>> A shared functionality between attachListener.cpp, management.cpp and >>> the new diagnostic commands to be introduced later (as mentioned in the >>> original synopsis of this RFR). It did seem preferable over just copying >>> the implementation over to a few more places. >> >> I need to see a clearer bigger picture. What I currently see doesn't >> look right to me - attach mechanism functionality doesn't belong in a >> general purpose ManagedFlags abstraction. > > Bigger picture is that introducing yet another copy of the flag management code for the purpose of adding the "VM.set_flag" diagnostic command did seem unwieldy. The purpose of this refactoring was to get the shared parts to one place. > > -JB- > >> >> David >> ----- >> >>>> >>>>>> >>>>>> All the new code seems incorrect: >>>>>> >>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>> return JNI_ERR; >>>>>> }; >>>>>> >>>>>> op->arg(0) comes from the original code where op was an >>>>>> AttachOperation*. Here is should be using flag_name. >>>>> >>>>> Correct. Slipped through and then replicated :/ >>>> >>>> And obviously never compiled. RFRs should be for tested code. >>> >>> Yes, one should run always "make clean" first, just in case. I should >>> remember this well to prevent further embarrassment. >>> >>> -JB- >>> >>>> >>>> David >>>> ----- >>>> >>>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -JB- >>>>> >>> > From dmitry.samersoff at oracle.com Tue Jan 13 09:00:57 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 13 Jan 2015 12:00:57 +0300 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B4A8D2.70700@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> Message-ID: <54B4DEC9.60209@oracle.com> David, On 2015-01-13 08:10, David Holmes wrote: > > Short version: okay but I'm going to file a bug to have sun.misc.Perf > fixed properly. Thank you and please, file a new bug (you can assign it to me directly). -Dmitry > > Long version ... read below :) > > Thanks, > David > > On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >> >> The fix explicitly checks for UsePerfData and if it's false make >> Perf:detach a NOP. > > That sidesteps the assertion failure but there is a bigger semantic > issue here I think - which is why the bug has remained open for so long. > UsePerfData can disable a part of the backend of the "perf" > functionality used via sun.misc.Perf, but sun.misc.Perf is completely > oblivious to that. It isn't even really clear what UsePerfData pertains > to. It impacts PerfMemory turning a number of methods into no-ops - but > it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. > What is a no-op is the initialization of PerfMemory (perfMemory_init) > during VM startup, and also the teardown (perfMemory_exit) during VM > shutdown (via at_exit handler). So the VM responds to the -UsePerfData > flag (in part) by not initializing the PerfMemory subsystem, but the > PerfMemory public apis are still enabled and invoked from the JDK code. > That doesn't make sense to me - we should fail to attach and in doing so > not put in place the Cleaner code that will attempt the detach. But > sun.misc.Perf doesn't understand that anything can fail. :( > > Your workaround avoids calling PerfMemory::detach from the Perf_detach > code by checking UsePerfData, but arguably the check should be inside > PerfMemory::detach operation (which unfortunately is OS specific). > >> >> -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 shanliang.jiang at oracle.com Tue Jan 13 09:28:31 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 13 Jan 2015 10:28:31 +0100 Subject: RFR: 8068774 CounterMonitorDeadlockTest.java timed out Message-ID: <54B4E53F.3020302@oracle.com> Hi Please review this test bug fix Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ The problem must be here: 98 monitorProxy.start(); 99 100 final int initGetCount = observedProxy.getGetCount(); The test calls initGetCount after starting the monitor, but the test case 1 is: "Remove monitored MBean within monitored getAttribute" that means if the monitor calls getAttribute before the test calls observedProxy.getGetCount(), then no more getAttribute will happen and the return of observedProxy.getGetCount() will not be changed any more. This is why the test is timeout. I reproduced the bug by inserting at line 99: Thread.sleep(1000); Thanks, Shanliang From jaroslav.bachorik at oracle.com Tue Jan 13 11:21:24 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 13 Jan 2015 12:21:24 +0100 Subject: jmx-dev RFR: 8068774 CounterMonitorDeadlockTest.java timed out In-Reply-To: <54B4E53F.3020302@oracle.com> References: <54B4E53F.3020302@oracle.com> Message-ID: <54B4FFB4.9050303@oracle.com> Looks good! Just don't forget to add "noreg-self" label to the issue. -JB- On 13.1.2015 10:28, shanliang wrote: > Hi > > Please review this test bug fix > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ > > > The problem must be here: > 98 monitorProxy.start(); > 99 > 100 final int initGetCount = observedProxy.getGetCount(); > > The test calls initGetCount after starting the monitor, but the test > case 1 is: > "Remove monitored MBean within monitored getAttribute" > > that means if the monitor calls getAttribute before the test calls > observedProxy.getGetCount(), then no more getAttribute will happen and > the return of observedProxy.getGetCount() will not be changed any more. > This is why the test is timeout. > > I reproduced the bug by inserting at line 99: > Thread.sleep(1000); > > Thanks, > Shanliang From daniel.fuchs at oracle.com Tue Jan 13 11:30:41 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Jan 2015 12:30:41 +0100 Subject: jmx-dev RFR: 8068774 CounterMonitorDeadlockTest.java timed out In-Reply-To: <54B4E53F.3020302@oracle.com> References: <54B4E53F.3020302@oracle.com> Message-ID: <54B501E1.2010702@oracle.com> On 13/01/15 10:28, shanliang wrote: > Hi > > Please review this test bug fix > > Bug: https://bugs.openjdk.java.net/browse/JDK-8068774 > Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8068774/00/ Looks good Shanliang! best regards, -- daniel > > > The problem must be here: > 98 monitorProxy.start(); > 99 > 100 final int initGetCount = observedProxy.getGetCount(); > > The test calls initGetCount after starting the monitor, but the test > case 1 is: > "Remove monitored MBean within monitored getAttribute" > > that means if the monitor calls getAttribute before the test calls > observedProxy.getGetCount(), then no more getAttribute will happen and > the return of observedProxy.getGetCount() will not be changed any more. > This is why the test is timeout. > > I reproduced the bug by inserting at line 99: > Thread.sleep(1000); > > Thanks, > Shanliang From alexander.kulyakhtin at oracle.com Tue Jan 13 11:44:28 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 13 Jan 2015 03:44:28 -0800 (PST) Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency Message-ID: <13171b03-198a-4b35-8efc-25c7374c254c@default> Hi, Could I please have a review of this fix. bug: https://bugs.openjdk.java.net/browse/JDK-8067945 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.00/ References to tools.jar are removed from the tests as jdk9 drops tools.jar Thanks, Alex From jaroslav.bachorik at oracle.com Tue Jan 13 12:09:07 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 13 Jan 2015 13:09:07 +0100 Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency In-Reply-To: <13171b03-198a-4b35-8efc-25c7374c254c@default> References: <13171b03-198a-4b35-8efc-25c7374c254c@default> Message-ID: <54B50AE3.6030403@oracle.com> Hi Alexander, test/com/sun/tools/attach/BasicTests.java L84 can be completely removed; no need to put on classpath test/com/sun/tools/attach/PermissionTest.java L77 can be completely removed; no need to put on classpath test/com/sun/tools/attach/TempDirTest.java L126 can be completely removed; no need to put on classpath test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java L149-154 can be completely removed; no need to put on classpath test/sun/management/jmxremote/bootstrap/LocalManagementTest.java L136-141 can be completely removed; no need to put on classpath -JB- On 13.1.2015 12:44, Alexander Kulyakhtin wrote: > Hi, > > Could I please have a review of this fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067945 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.00/ > > References to tools.jar are removed from the tests as jdk9 drops tools.jar > > > Thanks, > Alex > From david.holmes at oracle.com Tue Jan 13 12:21:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Jan 2015 22:21:47 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> Message-ID: <54B50DDB.3020502@oracle.com> Hi Staffan, On 13/01/2015 5:26 PM, Staffan Larsen wrote: > >> On 8 jan 2015, at 14:24, Jaroslav Bachorik wrote: >> >> On 8.1.2015 12:12, David Holmes wrote: >>> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>>> On 8.1.2015 03:45, David Holmes wrote: >>>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>>> Please, review the following change. >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>>> >>>>>>>> This patch is a precursor for implementing >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>>> part >>>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>>> >>>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>>> separate ManagedFlags class and the codebease is adjusted to use this >>>>>>>> class. >>>>>>> >>>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>>> platform specific variants of "set flag" ?? >>>>>> >>>>>> It has just been moved from the corresponding attachListener_.cpp >>>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>>> dependent"? >>>>> >>>>> Yes it does and it mostly made sense inside the already pd >>>>> attachListener implementations, but it isn't obvious to me that it makes >>>>> sense in the ManagedFlag context. It is the choice about whether the >>>>> flag can be changed that is "pd" not the actual setting and those >>>>> choices are inherent to the attachListener mechanism they are not >>>> >>>> Why would the ability to set Solaris specific flags via DTrace be >>>> specific to the attachListener mechanism? Also, AFAICS here it is the >>>> mechanism of setting the flag which is "pd" and not the choice >>>> (DTrace::* vs CommandLineFlags::*) >>> >>> The attachListener allows for manipulating VM flags if the attach >>> mechanism is used. In the Solaris case it turns on some DTrace flags. >>> The attach mechanism factors that into a pd_set_flags method that is >>> called for a given AttachOperation and so allows per platform behaviour. >>> But this is all part of the attach mechanism it isn't part of some >>> general flag management process. >> >> I think I see the problem. Sorry it took me so long. >> >> But, why the DTrace flags are only allowed to be set via the attachListener? Can we allow their manipulation via com.sun.Flag? Or they need to stay restricted to the attach mechanism only for whatever reason? > > I don?t think there is any reason these Dtrace flags should only ba changeable by the attach mechanism. They could just as well be changed from JMX or jcmd. I guess the code is in attach because attach was the only way of changing flags at the time. The only difference I can see for these Dtrace flags compared to other flags is that some action needs to be taken if the flag is changed (calls to DTrace::set_extended_dprobes()). I also think the Dtrace flags should be marked as ?manageable.? I'm having a separate discussion with Jaroslav via email. The key thing here (and it is wrong in the refactor) is that the pd_set_flag in the AttachListener only exists to allow for non-manageable flags to be set. That functionality is specific to the AttachListener code and makes no sense for a ManagedFlag abstraction. David > /Staffan > >> >>> >>>>> inherent to ManagedFlags - so this refactoring seems wrong to me. What >>>>> exactly is ManagedFlag supposed to represent? >>>> >>>> A shared functionality between attachListener.cpp, management.cpp and >>>> the new diagnostic commands to be introduced later (as mentioned in the >>>> original synopsis of this RFR). It did seem preferable over just copying >>>> the implementation over to a few more places. >>> >>> I need to see a clearer bigger picture. What I currently see doesn't >>> look right to me - attach mechanism functionality doesn't belong in a >>> general purpose ManagedFlags abstraction. >> >> Bigger picture is that introducing yet another copy of the flag management code for the purpose of adding the "VM.set_flag" diagnostic command did seem unwieldy. The purpose of this refactoring was to get the shared parts to one place. >> >> -JB- >> >>> >>> David >>> ----- >>> >>>>> >>>>>>> >>>>>>> All the new code seems incorrect: >>>>>>> >>>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>>> return JNI_ERR; >>>>>>> }; >>>>>>> >>>>>>> op->arg(0) comes from the original code where op was an >>>>>>> AttachOperation*. Here is should be using flag_name. >>>>>> >>>>>> Correct. Slipped through and then replicated :/ >>>>> >>>>> And obviously never compiled. RFRs should be for tested code. >>>> >>>> Yes, one should run always "make clean" first, just in case. I should >>>> remember this well to prevent further embarrassment. >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -JB- >>>>>> >>>> >> > From staffan.larsen at oracle.com Tue Jan 13 12:27:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 Jan 2015 13:27:17 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54B50DDB.3020502@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> <54B50DDB.3020502@oracle.com> Message-ID: <94135E81-D1D7-4444-A4E6-2620ADE57C31@oracle.com> > On 13 jan 2015, at 13:21, David Holmes wrote: > > Hi Staffan, > > On 13/01/2015 5:26 PM, Staffan Larsen wrote: >> >>> On 8 jan 2015, at 14:24, Jaroslav Bachorik wrote: >>> >>> On 8.1.2015 12:12, David Holmes wrote: >>>> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>>>> On 8.1.2015 03:45, David Holmes wrote: >>>>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>>>> Please, review the following change. >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>>>> >>>>>>>>> This patch is a precursor for implementing >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>>>> part >>>>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>>>> >>>>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>>>> separate ManagedFlags class and the codebease is adjusted to use this >>>>>>>>> class. >>>>>>>> >>>>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>>>> platform specific variants of "set flag" ?? >>>>>>> >>>>>>> It has just been moved from the corresponding attachListener_.cpp >>>>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>>>> dependent"? >>>>>> >>>>>> Yes it does and it mostly made sense inside the already pd >>>>>> attachListener implementations, but it isn't obvious to me that it makes >>>>>> sense in the ManagedFlag context. It is the choice about whether the >>>>>> flag can be changed that is "pd" not the actual setting and those >>>>>> choices are inherent to the attachListener mechanism they are not >>>>> >>>>> Why would the ability to set Solaris specific flags via DTrace be >>>>> specific to the attachListener mechanism? Also, AFAICS here it is the >>>>> mechanism of setting the flag which is "pd" and not the choice >>>>> (DTrace::* vs CommandLineFlags::*) >>>> >>>> The attachListener allows for manipulating VM flags if the attach >>>> mechanism is used. In the Solaris case it turns on some DTrace flags. >>>> The attach mechanism factors that into a pd_set_flags method that is >>>> called for a given AttachOperation and so allows per platform behaviour. >>>> But this is all part of the attach mechanism it isn't part of some >>>> general flag management process. >>> >>> I think I see the problem. Sorry it took me so long. >>> >>> But, why the DTrace flags are only allowed to be set via the attachListener? Can we allow their manipulation via com.sun.Flag? Or they need to stay restricted to the attach mechanism only for whatever reason? >> >> I don?t think there is any reason these Dtrace flags should only ba changeable by the attach mechanism. They could just as well be changed from JMX or jcmd. I guess the code is in attach because attach was the only way of changing flags at the time. The only difference I can see for these Dtrace flags compared to other flags is that some action needs to be taken if the flag is changed (calls to DTrace::set_extended_dprobes()). I also think the Dtrace flags should be marked as ?manageable.? > > I'm having a separate discussion with Jaroslav via email. The key thing here (and it is wrong in the refactor) is that the pd_set_flag in the AttachListener only exists to allow for non-manageable flags to be set. That functionality is specific to the AttachListener code and makes no sense for a ManagedFlag abstraction. I don?t agree - or perhaps I am misunderstanding. I thought ManagedFlag was supposed to be the common way for attach, jcmd, jmx or any other future API to change flags in runtime. The DTrace flags aren?t special to AttachListener - they should be changeable from jmx and jcmd as well. Thus, the special handling of them should be in ManagedFlag, no? /Staffan > > David > >> /Staffan >> >>> >>>> >>>>>> inherent to ManagedFlags - so this refactoring seems wrong to me. What >>>>>> exactly is ManagedFlag supposed to represent? >>>>> >>>>> A shared functionality between attachListener.cpp, management.cpp and >>>>> the new diagnostic commands to be introduced later (as mentioned in the >>>>> original synopsis of this RFR). It did seem preferable over just copying >>>>> the implementation over to a few more places. >>>> >>>> I need to see a clearer bigger picture. What I currently see doesn't >>>> look right to me - attach mechanism functionality doesn't belong in a >>>> general purpose ManagedFlags abstraction. >>> >>> Bigger picture is that introducing yet another copy of the flag management code for the purpose of adding the "VM.set_flag" diagnostic command did seem unwieldy. The purpose of this refactoring was to get the shared parts to one place. >>> >>> -JB- >>> >>>> >>>> David >>>> ----- >>>> >>>>>> >>>>>>>> >>>>>>>> All the new code seems incorrect: >>>>>>>> >>>>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>>>> return JNI_ERR; >>>>>>>> }; >>>>>>>> >>>>>>>> op->arg(0) comes from the original code where op was an >>>>>>>> AttachOperation*. Here is should be using flag_name. >>>>>>> >>>>>>> Correct. Slipped through and then replicated :/ >>>>>> >>>>>> And obviously never compiled. RFRs should be for tested code. >>>>> >>>>> Yes, one should run always "make clean" first, just in case. I should >>>>> remember this well to prevent further embarrassment. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Updated webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> -JB- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattias.tobiasson at oracle.com Tue Jan 13 12:55:51 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Tue, 13 Jan 2015 13:55:51 +0100 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start Message-ID: <54B515D7.8010902@oracle.com> Hi, Could I please have a review of this test bug fix. bug: https://bugs.openjdk.java.net/browse/JDK-8068613 webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.00/ On line 90 and on line 246 (in the old version) the test does a short wait between Runtime.getRuntime().runFinalization() and MemoryMXBean.getObjectPendingFinalizationCount() The test expects getObjectPendingFinalizationCount() to return 0, but that can fail on really slow servers. The fix will loop until getObjectPendingFinalizationCount() returns 0, or until it gives up after 100 tries. I have also moved all logging and finalization count verification to a function. This makes the diff look like everything have been changed, but it is mostly duplicate logging code that has been removed. I have tested it on all platforms, except embedded. Thanks, Mattias From martinrb at google.com Tue Jan 13 15:13:36 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 13 Jan 2015 07:13:36 -0800 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start In-Reply-To: <54B515D7.8010902@oracle.com> References: <54B515D7.8010902@oracle.com> Message-ID: Y'all should import GcFinalization for use as a testing utility. http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java On Tue, Jan 13, 2015 at 4:55 AM, Mattias Tobiasson < mattias.tobiasson at oracle.com> wrote: > Hi, > Could I please have a review of this test bug fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068613 > webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.00/ < > http://cr.openjdk.java.net/%7Eykantser/8068613/webrev.00/> > > On line 90 and on line 246 (in the old version) the test does a short wait > between > Runtime.getRuntime().runFinalization() and > MemoryMXBean.getObjectPendingFinalizationCount() > > The test expects getObjectPendingFinalizationCount() to return 0, > but that can fail on really slow servers. > > The fix will loop until getObjectPendingFinalizationCount() returns 0, > or until it gives up after 100 tries. > > I have also moved all logging and finalization count verification to a > function. > This makes the diff look like everything have been changed, but it is > mostly > duplicate logging code that has been removed. > > I have tested it on all platforms, except embedded. > > Thanks, > Mattias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Wed Jan 14 00:50:59 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 13 Jan 2015 16:50:59 -0800 Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error Message-ID: <54B5BD73.9070406@oracle.com> Hi, Please review the fix for JDK-8067982 (Some jcmd /gc/heap_dump tests failed: hprof output contains warning or error). The jcmd heap_dump tests failed due to incomplete symbol information in the dump output. The shared symbols are not included in the dump output because they are not in the SymbolTable, but in a separate table within the shared archive. The fix is to include the shared symbols when iterating all symbols in SymbolTable::symbols_do(SymbolClosure). http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests passed with the fix. Thanks, Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Jan 14 02:06:53 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Jan 2015 18:06:53 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5486CB9E.2090505@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> Message-ID: <54B5CF3D.4070307@oracle.com> Filed RFE: https://bugs.openjdk.java.net/browse/JDK-8068945 Regards, Vladimir On 12/9/14 2:14 AM, Erik Helin wrote: > I should also add that I don't have enough knowledge of the compiler > internals to review this patch, sorry. > > Thanks, > Erik > > On 2014-12-09 10:53, Erik Helin wrote: >> I applied the patch on top of jdk9/hs-comp and created a webrev: >> http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ >> >> I also successfully run the patch through JPRT. >> >> Thanks, >> Erik >> >> On 2014-12-05 20:57, Brendan Gregg wrote: >>> >>> >>> On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg >> > wrote: >>> >>> G'Day, >>> >>> I've hacked hotspot to return the frame pointer, in part to see what >>> this involves, and also to have a working prototype for analysis. >>> Along with an agent to resolve symbols, this has allowed full stack >>> profiling using Linux perf_events. The following flame graphs show >>> the resulting profiles. >>> >>> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >>> >>> Same thing, but this time disabling inlining, to show more frames: >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >>> >>> As expected, performance is worse without inlining. You can compare >>> the flame graphs side by side to see why. Less time spent doing work >>> / I/O! >>> >>> >>> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >>> >>> >>> is my patch, >>> >>> [...] >>> >>> >>> In case there's problems with the patch URL, the patch is: >>> >>> --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad >>> 2014-03-04 02:52:11.000000000 +0000 >>> +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad >>> 2014-11-08 01:10:49.686044933 +0000 >>> @@ -166,10 +166,9 @@ >>> // 3) reg_class stack_slots( /* one chunk of stack-based "registers" >>> */ ) >>> // >>> >>> -// Class for all pointer registers (including RSP) >>> +// Class for all pointer registers (including RSP, excluding RBP) >>> reg_class any_reg(RAX, RAX_H, >>> RDX, RDX_H, >>> - RBP, RBP_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -184,10 +183,9 @@ >>> R14, R14_H, >>> R15, R15_H); >>> >>> -// Class for all pointer registers except RSP >>> +// Class for all pointer registers except RSP and RBP >>> reg_class ptr_reg(RAX, RAX_H, >>> RDX, RDX_H, >>> - RBP, RBP_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -199,9 +197,8 @@ >>> R13, R13_H, >>> R14, R14_H); >>> >>> -// Class for all pointer registers except RAX and RSP >>> +// Class for all pointer registers except RAX, RSP and RBP >>> reg_class ptr_no_rax_reg(RDX, RDX_H, >>> - RBP, RBP_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -226,9 +223,8 @@ >>> R13, R13_H, >>> R14, R14_H); >>> >>> -// Class for all pointer registers except RAX, RBX and RSP >>> +// Class for all pointer registers except RAX, RBX, RSP and RBP >>> reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, >>> - RBP, RBP_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -260,10 +256,9 @@ >>> // Singleton class for TLS pointer >>> reg_class ptr_r15_reg(R15, R15_H); >>> >>> -// Class for all long registers (except RSP) >>> +// Class for all long registers (except RSP and RBP) >>> reg_class long_reg(RAX, RAX_H, >>> RDX, RDX_H, >>> - RBP, RBP_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -275,9 +270,8 @@ >>> R13, R13_H, >>> R14, R14_H); >>> >>> -// Class for all long registers except RAX, RDX (and RSP) >>> -reg_class long_no_rax_rdx_reg(RBP, RBP_H, >>> - RDI, RDI_H, >>> +// Class for all long registers except RAX, RDX (and RSP, RBP) >>> +reg_class long_no_rax_rdx_reg(RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> RBX, RBX_H, >>> @@ -288,9 +282,8 @@ >>> R13, R13_H, >>> R14, R14_H); >>> >>> -// Class for all long registers except RCX (and RSP) >>> -reg_class long_no_rcx_reg(RBP, RBP_H, >>> - RDI, RDI_H, >>> +// Class for all long registers except RCX (and RSP, RBP) >>> +reg_class long_no_rcx_reg(RDI, RDI_H, >>> RSI, RSI_H, >>> RAX, RAX_H, >>> RDX, RDX_H, >>> @@ -302,9 +295,8 @@ >>> R13, R13_H, >>> R14, R14_H); >>> >>> -// Class for all long registers except RAX (and RSP) >>> -reg_class long_no_rax_reg(RBP, RBP_H, >>> - RDX, RDX_H, >>> +// Class for all long registers except RAX (and RSP, RBP) >>> +reg_class long_no_rax_reg(RDX, RDX_H, >>> RDI, RDI_H, >>> RSI, RSI_H, >>> RCX, RCX_H, >>> @@ -325,10 +317,9 @@ >>> // Singleton class for RDX long register >>> reg_class long_rdx_reg(RDX, RDX_H); >>> >>> -// Class for all int registers (except RSP) >>> +// Class for all int registers (except RSP and RBP) >>> reg_class int_reg(RAX, >>> RDX, >>> - RBP, >>> RDI, >>> RSI, >>> RCX, >>> @@ -340,10 +331,9 @@ >>> R13, >>> R14); >>> >>> -// Class for all int registers except RCX (and RSP) >>> +// Class for all int registers except RCX (and RSP, RBP) >>> reg_class int_no_rcx_reg(RAX, >>> RDX, >>> - RBP, >>> RDI, >>> RSI, >>> RBX, >>> @@ -355,8 +345,7 @@ >>> R14); >>> >>> // Class for all int registers except RAX, RDX (and RSP) >>> -reg_class int_no_rax_rdx_reg(RBP, >>> - RDI, >>> +reg_class int_no_rax_rdx_reg(RDI, >>> RSI, >>> RCX, >>> RBX, >>> @@ -718,6 +707,7 @@ >>> st->print("# stack bang"); >>> st->print("\n\t"); >>> st->print("pushq rbp\t# Save rbp"); >>> + // BDG consider: st->print("movq rbp, rsp\t# "); >>> if (framesize) { >>> st->print("\n\t"); >>> st->print("subq rsp, #%d\t# Create frame",framesize); >>> --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp >>> 2014-03-04 02:52:11.000000000 +0000 >>> +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 >>> 23:57:11.589593723 +0000 >>> @@ -5236,6 +5236,7 @@ >>> // We always push rbp, so that on return to interpreter rbp, >>> will be >>> // restored correctly and we can correct the stack. >>> push(rbp); >>> + mov(rbp, rsp); >>> // Remove word for ebp >>> framesize -= wordSize; >>> >>> --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >>> 2014-03-04 02:52:10.000000000 +0000 >>> +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >>> 2014-11-07 23:57:21.933257882 +0000 >>> @@ -358,6 +358,7 @@ >>> generate_stack_overflow_check(frame_size_in_bytes); >>> >>> push(rbp); >>> + mov(rbp, rsp); >>> #ifdef TIERED >>> // c2 leaves fpu stack dirty. Clean it on entry >>> if (UseSSE < 2 ) { >>> >>> >>> Brendan > From yumin.qi at oracle.com Wed Jan 14 03:56:36 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Tue, 13 Jan 2015 19:56:36 -0800 Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error In-Reply-To: <54B5BD73.9070406@oracle.com> References: <54B5BD73.9070406@oracle.com> Message-ID: <54B5E8F4.7020404@oracle.com> Looks good to me. Could you update the copyright year? Thanks Yumin On 1/13/2015 4:50 PM, Jiangli Zhou wrote: > Hi, > > Please review the fix for JDK-8067982 > (Some jcmd > /gc/heap_dump tests failed: hprof output contains warning or error). > The jcmd heap_dump tests failed due to incomplete symbol information > in the dump output. The shared symbols are not included in the dump > output because they are not in the SymbolTable, but in a separate > table within the shared archive. The fix is to include the shared > symbols when iterating all symbols in > SymbolTable::symbols_do(SymbolClosure). > > http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ > > Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests > passed with the fix. > > Thanks, > Jiangli From serguei.spitsyn at oracle.com Wed Jan 14 05:47:52 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 13 Jan 2015 21:47:52 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found Message-ID: <54B60308.4000105@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8068162 Open webrevs: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ Summary: The sun.misc.Unsafe:throwIllegalAccessError() method is used in place of a default interface method in the itable if a default method was not defined in the interface. In fact, it happens for two interfaces that purhaps are auto-generated: java/nio/CharBuffer java/nio/HeapCharBuffer This approach creates a problem when the class sun.misc.Unsafe is retransformed. The Method* pointer to the old (redefined) method in the itable triggers an assert (see the hs_err log in the bug report). Coleen told me that a similar approach is going to be implemented for some vtable entries. Coleen, thanks for suggesting a better fix for this issue! The fix is to replace the old Unsafe method in the itable/vtable with the latest method version. Testing: In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests Thanks, Serguei From david.holmes at oracle.com Wed Jan 14 07:50:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Jan 2015 17:50:47 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <94135E81-D1D7-4444-A4E6-2620ADE57C31@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> <54B50DDB.3020502@oracle.com> <94135E81-D1D7-4444-A4E6-2620ADE57C31@oracle.com> Message-ID: <54B61FD7.3010707@oracle.com> Hi Staffan, On 13/01/2015 10:27 PM, Staffan Larsen wrote: > >> On 13 jan 2015, at 13:21, David Holmes > > wrote: >> >> Hi Staffan, >> >> On 13/01/2015 5:26 PM, Staffan Larsen wrote: >>> >>>> On 8 jan 2015, at 14:24, Jaroslav Bachorik >>>> > >>>> wrote: >>>> >>>> On 8.1.2015 12:12, David Holmes wrote: >>>>> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>>>>> On 8.1.2015 03:45, David Holmes wrote: >>>>>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>>>>> Please, review the following change. >>>>>>>>>> >>>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>>>>> >>>>>>>>>> This patch is a precursor for implementing >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>>>>> part >>>>>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>>>>> >>>>>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>>>>> separate ManagedFlags class and the codebease is adjusted to >>>>>>>>>> use this >>>>>>>>>> class. >>>>>>>>> >>>>>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>>>>> platform specific variants of "set flag" ?? >>>>>>>> >>>>>>>> It has just been moved from the corresponding >>>>>>>> attachListener_.cpp >>>>>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>>>>> dependent"? >>>>>>> >>>>>>> Yes it does and it mostly made sense inside the already pd >>>>>>> attachListener implementations, but it isn't obvious to me that >>>>>>> it makes >>>>>>> sense in the ManagedFlag context. It is the choice about whether the >>>>>>> flag can be changed that is "pd" not the actual setting and those >>>>>>> choices are inherent to the attachListener mechanism they are not >>>>>> >>>>>> Why would the ability to set Solaris specific flags via DTrace be >>>>>> specific to the attachListener mechanism? Also, AFAICS here it is the >>>>>> mechanism of setting the flag which is "pd" and not the choice >>>>>> (DTrace::* vs CommandLineFlags::*) >>>>> >>>>> The attachListener allows for manipulating VM flags if the attach >>>>> mechanism is used. In the Solaris case it turns on some DTrace flags. >>>>> The attach mechanism factors that into a pd_set_flags method that is >>>>> called for a given AttachOperation and so allows per platform >>>>> behaviour. >>>>> But this is all part of the attach mechanism it isn't part of some >>>>> general flag management process. >>>> >>>> I think I see the problem. Sorry it took me so long. >>>> >>>> But, why the DTrace flags are only allowed to be set via the >>>> attachListener? Can we allow their manipulation via com.sun.Flag? Or >>>> they need to stay restricted to the attach mechanism only for >>>> whatever reason? >>> >>> I don?t think there is any reason these Dtrace flags should only ba >>> changeable by the attach mechanism. They could just as well be >>> changed from JMX or jcmd. I guess the code is in attach because >>> attach was the only way of changing flags at the time. The only >>> difference I can see for these Dtrace flags compared to other flags >>> is that some action needs to be taken if the flag is changed (calls >>> to DTrace::set_extended_dprobes()). I also think the Dtrace flags >>> should be marked as ?manageable.? >> >> I'm having a separate discussion with Jaroslav via email. The key >> thing here (and it is wrong in the refactor) is that the pd_set_flag >> in the AttachListener only exists to allow for non-manageable flags to >> be set. That functionality is specific to the AttachListener code and >> makes no sense for a ManagedFlag abstraction. > > I don?t agree - or perhaps I am misunderstanding. I thought ManagedFlag > was supposed to be the common way for attach, jcmd, jmx or any other > future API to change flags in runtime. The DTrace flags aren?t special > to AttachListener - they should be changeable from jmx and jcmd as well. > Thus, the special handling of them should be in ManagedFlag, no? The DTrace flags are not manageable flags. If they change to be manageable then they can be modified via ManagedFlag. But the second problem with these flags is that setting them after VM initialization you have to not only change the value of the flag, you have to call the additional methods like AttachListener does. Maybe that prevents them from being "manageable"? - otherwise ManagedFlags has to know what actions occur in arguments.cpp when the flag is set during VM startup. This is what I wrote in the email (which Jaroslav has not had a chance to respond to yet): The "pd" specific part of AttachListener set_flag is to allow the attach_listener code to set none-manageable flags (the Dtrace flags are product not manageable), and as such should not form part of the ManagedFlags code. And you misfactored that part because you have it on an else that will only happen if an invalid flag name is passed in: 184 Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); 185 if (f) { 186 // only manageable flags are allowed to be set 187 if (f->is_external() && f->is_writeable()) { // ... set the flag 204 } else { 205 out->print_cr("Only 'manageable' flags can be set."); 206 res = JNI_ERR; 207 } 208 } else { // find_flag failed to find the flag 209 res = pd_set_flag(flag_name, flag_value, origin, out); 210 } whereas AttachListener has: Flag* f = Flag::find_flag((char*)name, strlen(name)); if (f && f->is_external() && f->is_writeable()) { // set flag } else { return AttachListener::pd_set_flag(op, out); } and this else part is for the non-manageable case (an invalid flag name will just be treated as an error by the pd_set_flag logic: "flag can not be changed"). So ManagedFlags::set_flag should not have a pd_set_flag at all but just: Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); if (f) { // only manageable flags are allowed to be set if (f->is_external() && f->is_writeable()) { // ... set the flag } else { out->print_cr("Only 'manageable' flags can be set."); res = JNI_ERR; } } else { out->print_cr("Flag not found"); res = JNI_ERR; } And AttachListener::set_flag should look like: static jint set_flag(AttachOperation* op, outputStream* out) { const char* name = NULL; if ((name = op->arg(0)) == NULL) { out->print_cr("flag name is missing"); return JNI_ERR; } if (ManagedFlags::set_flag(op->arg(0), op->arg(1), Flag::ATTACH_ON_DEMAND, out) == JNI_ERR) { // not a manageable flag - see if there is platform specific // logic for this flag return AttachListener::pd_set_flag(op, out); } else { return JNI_OK; } } The only issue with the above is that ManagedFlags::set_flag is going to write an error message to the outputstream, which is not wanted when processing a pd flag. In my opinion ManagedFlag::set_flag shouldn't be concerned with writing error messages as it doesn't know what constitutes an error. In which case the ManagedFlag::set_flag logic simplifies further, but AttachListener would have to do additional work itself if it want to produce error messages. ---- Cheers, David > /Staffan > >> >> David >> >>> /Staffan >>> >>>> >>>>> >>>>>>> inherent to ManagedFlags - so this refactoring seems wrong to me. >>>>>>> What >>>>>>> exactly is ManagedFlag supposed to represent? >>>>>> >>>>>> A shared functionality between attachListener.cpp, management.cpp and >>>>>> the new diagnostic commands to be introduced later (as mentioned >>>>>> in the >>>>>> original synopsis of this RFR). It did seem preferable over just >>>>>> copying >>>>>> the implementation over to a few more places. >>>>> >>>>> I need to see a clearer bigger picture. What I currently see doesn't >>>>> look right to me - attach mechanism functionality doesn't belong in a >>>>> general purpose ManagedFlags abstraction. >>>> >>>> Bigger picture is that introducing yet another copy of the flag >>>> management code for the purpose of adding the "VM.set_flag" >>>> diagnostic command did seem unwieldy. The purpose of this >>>> refactoring was to get the shared parts to one place. >>>> >>>> -JB- >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>>> >>>>>>>>> >>>>>>>>> All the new code seems incorrect: >>>>>>>>> >>>>>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>>>>> return JNI_ERR; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> op->arg(0) comes from the original code where op was an >>>>>>>>> AttachOperation*. Here is should be using flag_name. >>>>>>>> >>>>>>>> Correct. Slipped through and then replicated :/ >>>>>>> >>>>>>> And obviously never compiled. RFRs should be for tested code. >>>>>> >>>>>> Yes, one should run always "make clean" first, just in case. I should >>>>>> remember this well to prevent further embarrassment. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Updated webrev: >>>>>>>> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> -JB- > From fredrik.arvidsson at oracle.com Wed Jan 14 08:06:44 2015 From: fredrik.arvidsson at oracle.com (=?utf-8?B?ZnJlZHJpay5hcnZpZHNzb25Ab3JhY2xlLmNvbQ==?=) Date: Wed, 14 Jan 2015 09:06:44 +0100 Subject: =?utf-8?B?UmU6IFJGUiA4MDY3OTgyOiBzb21lIGpjbWQgL2djL2hlYXBfZHVtcCB0ZXN0cyBm?= =?utf-8?B?YWlsZWQ6IGhwcm9mIG91dHB1dCBjb250YWlucyB3YXJuaW5nIG9yIGVycm9y?= Message-ID: <201501140806.t0E86mjd021704@aserz7022.oracle.com> Hi Looks good to me (not a reviewer). Thanks for fixing this! /Fredrik Sent from my HTC ----- Reply message ----- From: "Yumin Qi" To: "Jiangli Zhou" , "hotspot-runtime-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error Date: Wed, Jan 14, 2015 04:56 Looks good to me. Could you update the copyright year? Thanks Yumin On 1/13/2015 4:50 PM, Jiangli Zhou wrote: > Hi, > > Please review the fix for JDK-8067982 > (Some jcmd > /gc/heap_dump tests failed: hprof output contains warning or error). > The jcmd heap_dump tests failed due to incomplete symbol information > in the dump output. The shared symbols are not included in the dump > output because they are not in the SymbolTable, but in a separate > table within the shared archive. The fix is to include the shared > symbols when iterating all symbols in > SymbolTable::symbols_do(SymbolClosure). > > http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ > > Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests > passed with the fix. > > Thanks, > Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Jan 14 13:31:12 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 14 Jan 2015 16:31:12 +0300 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B4A8D2.70700@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> Message-ID: <54B66FA0.7020108@oracle.com> Any other reviewers? -Dmitry On 2015-01-13 08:10, David Holmes wrote: > Hi Dmitry, > > Short version: okay but I'm going to file a bug to have sun.misc.Perf > fixed properly. > > Long version ... read below :) > > Thanks, > David > > On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >> >> The fix explicitly checks for UsePerfData and if it's false make >> Perf:detach a NOP. > > That sidesteps the assertion failure but there is a bigger semantic > issue here I think - which is why the bug has remained open for so long. > UsePerfData can disable a part of the backend of the "perf" > functionality used via sun.misc.Perf, but sun.misc.Perf is completely > oblivious to that. It isn't even really clear what UsePerfData pertains > to. It impacts PerfMemory turning a number of methods into no-ops - but > it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. > What is a no-op is the initialization of PerfMemory (perfMemory_init) > during VM startup, and also the teardown (perfMemory_exit) during VM > shutdown (via at_exit handler). So the VM responds to the -UsePerfData > flag (in part) by not initializing the PerfMemory subsystem, but the > PerfMemory public apis are still enabled and invoked from the JDK code. > That doesn't make sense to me - we should fail to attach and in doing so > not put in place the Cleaner code that will attempt the detach. But > sun.misc.Perf doesn't understand that anything can fail. :( > > Your workaround avoids calling PerfMemory::detach from the Perf_detach > code by checking UsePerfData, but arguably the check should be inside > PerfMemory::detach operation (which unfortunately is OS specific). > >> >> -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 jaroslav.bachorik at oracle.com Wed Jan 14 14:05:41 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Jan 2015 15:05:41 +0100 Subject: RFR 8068976: Remove JSDT implementation Message-ID: <54B677B5.3080809@oracle.com> Please, review the following removal of functionality. Issue : https://bugs.openjdk.java.net/browse/JDK-8068976 Webrev: http://cr.openjdk.java.net/~jbachorik/8068976/webrev.00 JDK-8062303 [1] requests the removal of com.sun.tracing API. This API was added as experimental in JDK7 [2][3] and haven't seen any significant uptake since then. JSDT builds on top of the com.sun.tracing API and provides the bridge to DTrace. It allows Java programs to fire custom DTrace probes. As an implementation of com.sun.tracing API it needs to be removed before proceeding with the removal of that API. This change is basically an anti-delta to [4] - minus the changes not related to JSDT and/or DTrace. This change passes all the regression and JCK tests. Thanks, -JB- [1] https://bugs.openjdk.java.net/browse/JDK-8062303 [2] https://bugs.openjdk.java.net/browse/JDK-6537506 [3] https://bugs.openjdk.java.net/browse/JDK-7037081 [4] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/018d5b58dd4f From jaroslav.bachorik at oracle.com Wed Jan 14 14:07:12 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Jan 2015 15:07:12 +0100 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B66FA0.7020108@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B66FA0.7020108@oracle.com> Message-ID: <54B67810.1070608@oracle.com> On 14.1.2015 14:31, Dmitry Samersoff wrote: > Any other reviewers? Speaking strictly about this change - it looks good. -JB- > > -Dmitry > > On 2015-01-13 08:10, David Holmes wrote: >> Hi Dmitry, >> >> Short version: okay but I'm going to file a bug to have sun.misc.Perf >> fixed properly. >> >> Long version ... read below :) >> >> Thanks, >> David >> >> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>> >>> The fix explicitly checks for UsePerfData and if it's false make >>> Perf:detach a NOP. >> >> That sidesteps the assertion failure but there is a bigger semantic >> issue here I think - which is why the bug has remained open for so long. >> UsePerfData can disable a part of the backend of the "perf" >> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >> oblivious to that. It isn't even really clear what UsePerfData pertains >> to. It impacts PerfMemory turning a number of methods into no-ops - but >> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >> What is a no-op is the initialization of PerfMemory (perfMemory_init) >> during VM startup, and also the teardown (perfMemory_exit) during VM >> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >> flag (in part) by not initializing the PerfMemory subsystem, but the >> PerfMemory public apis are still enabled and invoked from the JDK code. >> That doesn't make sense to me - we should fail to attach and in doing so >> not put in place the Cleaner code that will attempt the detach. But >> sun.misc.Perf doesn't understand that anything can fail. :( >> >> Your workaround avoids calling PerfMemory::detach from the Perf_detach >> code by checking UsePerfData, but arguably the check should be inside >> PerfMemory::detach operation (which unfortunately is OS specific). >> >>> >>> -Dmitry >>> > > From kmcguigan at twitter.com Wed Jan 14 14:13:23 2015 From: kmcguigan at twitter.com (Keith McGuigan) Date: Wed, 14 Jan 2015 09:13:23 -0500 Subject: RFR 8068976: Remove JSDT implementation In-Reply-To: <54B677B5.3080809@oracle.com> References: <54B677B5.3080809@oracle.com> Message-ID: What evidence do you have that no OpenJDK users are using this? On Wed, Jan 14, 2015 at 9:05 AM, Jaroslav Bachorik < jaroslav.bachorik at oracle.com> wrote: > Please, review the following removal of functionality. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068976 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068976/webrev.00 > > JDK-8062303 [1] requests the removal of com.sun.tracing API. This API was > added as experimental in JDK7 [2][3] and haven't seen any significant > uptake since then. > > JSDT builds on top of the com.sun.tracing API and provides the bridge to > DTrace. It allows Java programs to fire custom DTrace probes. As an > implementation of com.sun.tracing API it needs to be removed before > proceeding with the removal of that API. > > This change is basically an anti-delta to [4] - minus the changes not > related to JSDT and/or DTrace. > > This change passes all the regression and JCK tests. > > Thanks, > > -JB- > > > [1] https://bugs.openjdk.java.net/browse/JDK-8062303 > [2] https://bugs.openjdk.java.net/browse/JDK-6537506 > [3] https://bugs.openjdk.java.net/browse/JDK-7037081 > [4] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/018d5b58dd4f > -- [image: twitter-icon-large.png] Keith McGuigan @kamggg kmcguigan at twitter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Wed Jan 14 14:28:48 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 14 Jan 2015 15:28:48 +0100 Subject: RFR 8068976: Remove JSDT implementation In-Reply-To: References: <54B677B5.3080809@oracle.com> Message-ID: <54B67D20.4040406@oracle.com> On 14.1.2015 15:13, Keith McGuigan wrote: > What evidence do you have that no OpenJDK users are using this? A search from the snapshot of the maven central as of May 2014 finds only no reference to com.sun.tracing except it finds one artifact jsdt-compat (https://github.com/cmbntr/jsdt-compat) that redistributes com.sun.tracing APIs and implementation classes for pre-JDK7 usage. As there is no possible way to use JSDT without going through com.sun.tracing API the lack of references in maven central could be good enough indication of this functionality not being in use. AFAIK, there is no other reliable way to figure out whether an API is in active use or not :( -JB- > > On Wed, Jan 14, 2015 at 9:05 AM, Jaroslav Bachorik > > wrote: > > Please, review the following removal of functionality. > > Issue : https://bugs.openjdk.java.net/__browse/JDK-8068976 > > Webrev: http://cr.openjdk.java.net/~__jbachorik/8068976/webrev.00 > > > JDK-8062303 [1] requests the removal of com.sun.tracing API. This > API was added as experimental in JDK7 [2][3] and haven't seen any > significant uptake since then. > > JSDT builds on top of the com.sun.tracing API and provides the > bridge to DTrace. It allows Java programs to fire custom DTrace > probes. As an implementation of com.sun.tracing API it needs to be > removed before proceeding with the removal of that API. > > This change is basically an anti-delta to [4] - minus the changes > not related to JSDT and/or DTrace. > > This change passes all the regression and JCK tests. > > Thanks, > > -JB- > > > [1] https://bugs.openjdk.java.net/__browse/JDK-8062303 > > [2] https://bugs.openjdk.java.net/__browse/JDK-6537506 > > [3] https://bugs.openjdk.java.net/__browse/JDK-7037081 > > [4] > http://hg.openjdk.java.net/__jdk9/hs-rt/hotspot/rev/__018d5b58dd4f > > > > > > -- > > twitter-icon-large.png > > > > Keith McGuigan > > @kamggg > > kmcguigan at twitter.com > From bertrand.delsart at oracle.com Wed Jan 14 14:42:30 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 14 Jan 2015 15:42:30 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B5CF3D.4070307@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> Message-ID: <54B68056.3090706@oracle.com> Hi, I'm surprised not to see any change related to JSR292 in the webrev. While the fix looks safe (not breaking hotspot), it probably does not work as you expect... and this might make it useless. RBP is used by the JITs to memorize SP before it may be adapted during a call sequence (look for instance for method_handle_invoke_SP_save_opr or rbp_mh_SP_save in the code). Hence the value we push on the stack may not be the RBP of the caller. It can be its SP just before the call... which would probably confuse your profiler, possibly crashing it if you really assume this is the beginning of a frame. IMHO, the RFE does not break hotspot and profiling seems to work... but if you try to profile code which uses invoke dynamic, you will hit bugs in the profiler. I would not prevent the JITs from using RBP as long as the changeset is not sufficient to guarantee the profiling will work... and IMHO solving the JSR292 issue will be much more intrusive (impacting HotSpot stack walking code). Regards, Bertrand. On 14/01/2015 03:06, Vladimir Kozlov wrote: > Filed RFE: > > https://bugs.openjdk.java.net/browse/JDK-8068945 > > Regards, > Vladimir > > On 12/9/14 2:14 AM, Erik Helin wrote: >> I should also add that I don't have enough knowledge of the compiler >> internals to review this patch, sorry. >> >> Thanks, >> Erik >> >> On 2014-12-09 10:53, Erik Helin wrote: >>> I applied the patch on top of jdk9/hs-comp and created a webrev: >>> http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ >>> >>> I also successfully run the patch through JPRT. >>> >>> Thanks, >>> Erik >>> >>> On 2014-12-05 20:57, Brendan Gregg wrote: >>>> >>>> >>>> On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg >>>> >>> > wrote: >>>> >>>> G'Day, >>>> >>>> I've hacked hotspot to return the frame pointer, in part to see >>>> what >>>> this involves, and also to have a working prototype for analysis. >>>> Along with an agent to resolve symbols, this has allowed full stack >>>> profiling using Linux perf_events. The following flame graphs show >>>> the resulting profiles. >>>> >>>> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >>>> >>>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >>>> >>>> Same thing, but this time disabling inlining, to show more frames: >>>> >>>> >>>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >>>> >>>> As expected, performance is worse without inlining. You can compare >>>> the flame graphs side by side to see why. Less time spent doing >>>> work >>>> / I/O! >>>> >>>> >>>> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >>>> >>>> >>>> >>>> is my patch, >>>> >>>> [...] >>>> >>>> >>>> In case there's problems with the patch URL, the patch is: >>>> >>>> --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad >>>> 2014-03-04 02:52:11.000000000 +0000 >>>> +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad >>>> 2014-11-08 01:10:49.686044933 +0000 >>>> @@ -166,10 +166,9 @@ >>>> // 3) reg_class stack_slots( /* one chunk of stack-based "registers" >>>> */ ) >>>> // >>>> >>>> -// Class for all pointer registers (including RSP) >>>> +// Class for all pointer registers (including RSP, excluding RBP) >>>> reg_class any_reg(RAX, RAX_H, >>>> RDX, RDX_H, >>>> - RBP, RBP_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -184,10 +183,9 @@ >>>> R14, R14_H, >>>> R15, R15_H); >>>> >>>> -// Class for all pointer registers except RSP >>>> +// Class for all pointer registers except RSP and RBP >>>> reg_class ptr_reg(RAX, RAX_H, >>>> RDX, RDX_H, >>>> - RBP, RBP_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -199,9 +197,8 @@ >>>> R13, R13_H, >>>> R14, R14_H); >>>> >>>> -// Class for all pointer registers except RAX and RSP >>>> +// Class for all pointer registers except RAX, RSP and RBP >>>> reg_class ptr_no_rax_reg(RDX, RDX_H, >>>> - RBP, RBP_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -226,9 +223,8 @@ >>>> R13, R13_H, >>>> R14, R14_H); >>>> >>>> -// Class for all pointer registers except RAX, RBX and RSP >>>> +// Class for all pointer registers except RAX, RBX, RSP and RBP >>>> reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, >>>> - RBP, RBP_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -260,10 +256,9 @@ >>>> // Singleton class for TLS pointer >>>> reg_class ptr_r15_reg(R15, R15_H); >>>> >>>> -// Class for all long registers (except RSP) >>>> +// Class for all long registers (except RSP and RBP) >>>> reg_class long_reg(RAX, RAX_H, >>>> RDX, RDX_H, >>>> - RBP, RBP_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -275,9 +270,8 @@ >>>> R13, R13_H, >>>> R14, R14_H); >>>> >>>> -// Class for all long registers except RAX, RDX (and RSP) >>>> -reg_class long_no_rax_rdx_reg(RBP, RBP_H, >>>> - RDI, RDI_H, >>>> +// Class for all long registers except RAX, RDX (and RSP, RBP) >>>> +reg_class long_no_rax_rdx_reg(RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> RBX, RBX_H, >>>> @@ -288,9 +282,8 @@ >>>> R13, R13_H, >>>> R14, R14_H); >>>> >>>> -// Class for all long registers except RCX (and RSP) >>>> -reg_class long_no_rcx_reg(RBP, RBP_H, >>>> - RDI, RDI_H, >>>> +// Class for all long registers except RCX (and RSP, RBP) >>>> +reg_class long_no_rcx_reg(RDI, RDI_H, >>>> RSI, RSI_H, >>>> RAX, RAX_H, >>>> RDX, RDX_H, >>>> @@ -302,9 +295,8 @@ >>>> R13, R13_H, >>>> R14, R14_H); >>>> >>>> -// Class for all long registers except RAX (and RSP) >>>> -reg_class long_no_rax_reg(RBP, RBP_H, >>>> - RDX, RDX_H, >>>> +// Class for all long registers except RAX (and RSP, RBP) >>>> +reg_class long_no_rax_reg(RDX, RDX_H, >>>> RDI, RDI_H, >>>> RSI, RSI_H, >>>> RCX, RCX_H, >>>> @@ -325,10 +317,9 @@ >>>> // Singleton class for RDX long register >>>> reg_class long_rdx_reg(RDX, RDX_H); >>>> >>>> -// Class for all int registers (except RSP) >>>> +// Class for all int registers (except RSP and RBP) >>>> reg_class int_reg(RAX, >>>> RDX, >>>> - RBP, >>>> RDI, >>>> RSI, >>>> RCX, >>>> @@ -340,10 +331,9 @@ >>>> R13, >>>> R14); >>>> >>>> -// Class for all int registers except RCX (and RSP) >>>> +// Class for all int registers except RCX (and RSP, RBP) >>>> reg_class int_no_rcx_reg(RAX, >>>> RDX, >>>> - RBP, >>>> RDI, >>>> RSI, >>>> RBX, >>>> @@ -355,8 +345,7 @@ >>>> R14); >>>> >>>> // Class for all int registers except RAX, RDX (and RSP) >>>> -reg_class int_no_rax_rdx_reg(RBP, >>>> - RDI, >>>> +reg_class int_no_rax_rdx_reg(RDI, >>>> RSI, >>>> RCX, >>>> RBX, >>>> @@ -718,6 +707,7 @@ >>>> st->print("# stack bang"); >>>> st->print("\n\t"); >>>> st->print("pushq rbp\t# Save rbp"); >>>> + // BDG consider: st->print("movq rbp, rsp\t# "); >>>> if (framesize) { >>>> st->print("\n\t"); >>>> st->print("subq rsp, #%d\t# Create frame",framesize); >>>> --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp >>>> 2014-03-04 02:52:11.000000000 +0000 >>>> +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp >>>> 2014-11-07 >>>> 23:57:11.589593723 +0000 >>>> @@ -5236,6 +5236,7 @@ >>>> // We always push rbp, so that on return to interpreter rbp, >>>> will be >>>> // restored correctly and we can correct the stack. >>>> push(rbp); >>>> + mov(rbp, rsp); >>>> // Remove word for ebp >>>> framesize -= wordSize; >>>> >>>> --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >>>> 2014-03-04 02:52:10.000000000 +0000 >>>> +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >>>> 2014-11-07 23:57:21.933257882 +0000 >>>> @@ -358,6 +358,7 @@ >>>> generate_stack_overflow_check(frame_size_in_bytes); >>>> >>>> push(rbp); >>>> + mov(rbp, rsp); >>>> #ifdef TIERED >>>> // c2 leaves fpu stack dirty. Clean it on entry >>>> if (UseSSE < 2 ) { >>>> >>>> >>>> Brendan >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From jiangli.zhou at oracle.com Wed Jan 14 16:33:13 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 14 Jan 2015 08:33:13 -0800 Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error In-Reply-To: <54B5E8F4.7020404@oracle.com> References: <54B5BD73.9070406@oracle.com> <54B5E8F4.7020404@oracle.com> Message-ID: <54B69A49.60503@oracle.com> Hi Yumin, Thanks for the review! Will fix the copyright. Thanks, Jiangli On 01/13/2015 07:56 PM, Yumin Qi wrote: > Looks good to me. Could you update the copyright year? > > Thanks > Yumin > > On 1/13/2015 4:50 PM, Jiangli Zhou wrote: >> Hi, >> >> Please review the fix for JDK-8067982 >> (Some jcmd >> /gc/heap_dump tests failed: hprof output contains warning or error). >> The jcmd heap_dump tests failed due to incomplete symbol information >> in the dump output. The shared symbols are not included in the dump >> output because they are not in the SymbolTable, but in a separate >> table within the shared archive. The fix is to include the shared >> symbols when iterating all symbols in >> SymbolTable::symbols_do(SymbolClosure). >> >> http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ >> >> Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests >> passed with the fix. >> >> Thanks, >> Jiangli > From jiangli.zhou at oracle.com Wed Jan 14 16:34:17 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 14 Jan 2015 08:34:17 -0800 Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error Message-ID: <54B69A89.2080107@oracle.com> Thanks, Fredrik! Jiangli On 01/14/2015 12:06 AM, fredrik.arvidsson at oracle.com wrote: > Hi > Looks good to me (not a reviewer). > Thanks for fixing this! > /Fredrik > > Sent from my HTC > > ----- Reply message ----- > From: "Yumin Qi" > To: "Jiangli Zhou" , > "hotspot-runtime-dev at openjdk.java.net" > , > "serviceability-dev at openjdk.java.net" > > Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof > output contains warning or error > Date: Wed, Jan 14, 2015 04:56 > > Looks good to me. Could you update the copyright year? > > Thanks > Yumin > > On 1/13/2015 4:50 PM, Jiangli Zhou wrote: > > Hi, > > > > Please review the fix for JDK-8067982 > > (Some jcmd > > /gc/heap_dump tests failed: hprof output contains warning or error). > > The jcmd heap_dump tests failed due to incomplete symbol information > > in the dump output. The shared symbols are not included in the dump > > output because they are not in the SymbolTable, but in a separate > > table within the shared archive. The fix is to include the shared > > symbols when iterating all symbols in > > SymbolTable::symbols_do(SymbolClosure). > > > >http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ > > > > Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests > > passed with the fix. > > > > Thanks, > > Jiangli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Jan 14 16:38:47 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 14 Jan 2015 17:38:47 +0100 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <54B61FD7.3010707@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> <54B50DDB.3020502@oracle.com> <94135E81-D1D7-4444-A4E6-2620ADE57C31@oracle.com> <54B61FD7.3010707@oracle.com> Message-ID: <5734052E-E964-4780-90E3-A96C2B864152@oracle.com> > On 14 jan 2015, at 08:50, David Holmes wrote: > > Hi Staffan, > > On 13/01/2015 10:27 PM, Staffan Larsen wrote: >> >>> On 13 jan 2015, at 13:21, David Holmes >> > wrote: >>> >>> Hi Staffan, >>> >>> On 13/01/2015 5:26 PM, Staffan Larsen wrote: >>>> >>>>> On 8 jan 2015, at 14:24, Jaroslav Bachorik >>>>> > >>>>> wrote: >>>>> >>>>> On 8.1.2015 12:12, David Holmes wrote: >>>>>> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>>>>>> On 8.1.2015 03:45, David Holmes wrote: >>>>>>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>>>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>>>>>> Please, review the following change. >>>>>>>>>>> >>>>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>>>>>> >>>>>>>>>>> This patch is a precursor for implementing >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>>>>>> part >>>>>>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>>>>>> >>>>>>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>>>>>> separate ManagedFlags class and the codebease is adjusted to >>>>>>>>>>> use this >>>>>>>>>>> class. >>>>>>>>>> >>>>>>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>>>>>> platform specific variants of "set flag" ?? >>>>>>>>> >>>>>>>>> It has just been moved from the corresponding >>>>>>>>> attachListener_.cpp >>>>>>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>>>>>> dependent"? >>>>>>>> >>>>>>>> Yes it does and it mostly made sense inside the already pd >>>>>>>> attachListener implementations, but it isn't obvious to me that >>>>>>>> it makes >>>>>>>> sense in the ManagedFlag context. It is the choice about whether the >>>>>>>> flag can be changed that is "pd" not the actual setting and those >>>>>>>> choices are inherent to the attachListener mechanism they are not >>>>>>> >>>>>>> Why would the ability to set Solaris specific flags via DTrace be >>>>>>> specific to the attachListener mechanism? Also, AFAICS here it is the >>>>>>> mechanism of setting the flag which is "pd" and not the choice >>>>>>> (DTrace::* vs CommandLineFlags::*) >>>>>> >>>>>> The attachListener allows for manipulating VM flags if the attach >>>>>> mechanism is used. In the Solaris case it turns on some DTrace flags. >>>>>> The attach mechanism factors that into a pd_set_flags method that is >>>>>> called for a given AttachOperation and so allows per platform >>>>>> behaviour. >>>>>> But this is all part of the attach mechanism it isn't part of some >>>>>> general flag management process. >>>>> >>>>> I think I see the problem. Sorry it took me so long. >>>>> >>>>> But, why the DTrace flags are only allowed to be set via the >>>>> attachListener? Can we allow their manipulation via com.sun.Flag? Or >>>>> they need to stay restricted to the attach mechanism only for >>>>> whatever reason? >>>> >>>> I don?t think there is any reason these Dtrace flags should only ba >>>> changeable by the attach mechanism. They could just as well be >>>> changed from JMX or jcmd. I guess the code is in attach because >>>> attach was the only way of changing flags at the time. The only >>>> difference I can see for these Dtrace flags compared to other flags >>>> is that some action needs to be taken if the flag is changed (calls >>>> to DTrace::set_extended_dprobes()). I also think the Dtrace flags >>>> should be marked as ?manageable.? >>> >>> I'm having a separate discussion with Jaroslav via email. The key >>> thing here (and it is wrong in the refactor) is that the pd_set_flag >>> in the AttachListener only exists to allow for non-manageable flags to >>> be set. That functionality is specific to the AttachListener code and >>> makes no sense for a ManagedFlag abstraction. >> >> I don?t agree - or perhaps I am misunderstanding. I thought ManagedFlag >> was supposed to be the common way for attach, jcmd, jmx or any other >> future API to change flags in runtime. The DTrace flags aren?t special >> to AttachListener - they should be changeable from jmx and jcmd as well. >> Thus, the special handling of them should be in ManagedFlag, no? > > The DTrace flags are not manageable flags. I think that is a mistake. They should be. I do not understand why they are not - at the very least they should be ?product_rw?. Perhaps product_rw did not exist when they were introduced? > If they change to be manageable then they can be modified via ManagedFlag. But the second problem with these flags is that setting them after VM initialization you have to not only change the value of the flag, you have to call the additional methods like AttachListener does. Maybe that prevents them from being "manageable"? - otherwise ManagedFlags has to know what actions occur in arguments.cpp when the flag is set during VM startup. Yes, ManagedFlags should know what actions should be taken if a managed flag is changed. This is precisely why we want to introduce a ManagedFlags abstraction. Currently that logic is spread out in attachListener.cpp and management.cpp (see the code for ?MaxHeapFreeRatio?). We want to consolidate it into one place (and in the future add jcmd as an additional way to change flags). Most managed flags don?t need an action to be taken when they are changed, but the Dtrace and MaxHeapFreeRatio flags do. Perhaps ?ManagedFlags? should change name to WriteableFlags? Would that make it?s purpose clearer? We do have flags marked both ?manageble? and ?product_rw? in globals.hpp that can be changed. > > This is what I wrote in the email (which Jaroslav has not had a chance to respond to yet): > > The "pd" specific part of AttachListener set_flag is to allow the attach_listener code to set none-manageable flags (the Dtrace flags are product not manageable), and as such should not form part of the ManagedFlags code. And you misfactored that part because you have it on an else that will only happen if an invalid flag name is passed in: > > 184 Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); > 185 if (f) { > 186 // only manageable flags are allowed to be set > 187 if (f->is_external() && f->is_writeable()) { > // ... set the flag > 204 } else { > 205 out->print_cr("Only 'manageable' flags can be set."); > 206 res = JNI_ERR; > 207 } > 208 } else { > // find_flag failed to find the flag > 209 res = pd_set_flag(flag_name, flag_value, origin, out); > 210 } > > whereas AttachListener has: > > Flag* f = Flag::find_flag((char*)name, strlen(name)); > if (f && f->is_external() && f->is_writeable()) { > // set flag > } else { > return AttachListener::pd_set_flag(op, out); > } > > and this else part is for the non-manageable case (an invalid flag name will just be treated as an error by the pd_set_flag logic: "flag can not be changed"). > > So ManagedFlags::set_flag should not have a pd_set_flag at all but just: > > Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); > if (f) { > // only manageable flags are allowed to be set > if (f->is_external() && f->is_writeable()) { > // ... set the flag > } else { > out->print_cr("Only 'manageable' flags can be set."); > res = JNI_ERR; > } > } else { > out->print_cr("Flag not found"); > res = JNI_ERR; > } > Yes, agree on the above. > And AttachListener::set_flag should look like: > > static jint set_flag(AttachOperation* op, outputStream* out) { > > const char* name = NULL; > if ((name = op->arg(0)) == NULL) { > out->print_cr("flag name is missing"); > return JNI_ERR; > } > > if (ManagedFlags::set_flag(op->arg(0), op->arg(1), > Flag::ATTACH_ON_DEMAND, out) == JNI_ERR) { > // not a manageable flag - see if there is platform specific > // logic for this flag > return AttachListener::pd_set_flag(op, out); > } > else { > return JNI_OK; > } > } We should make the Dtrace flags into product_rw flags and then we can remove all the pd_set_flag() methods. I can?t see a reason for them. > > The only issue with the above is that ManagedFlags::set_flag is going to write an error message to the outputstream, which is not wanted when processing a pd flag. In my opinion ManagedFlag::set_flag shouldn't be concerned with writing error messages as it doesn't know what constitutes an error. In which case the ManagedFlag::set_flag logic simplifies further, but AttachListener would have to do additional work itself if it want to produce error messages. ManagedFlags should know what the errors are and the errors should be propagated to attachListener (and management.cpp) so that they can be further propagated to the user. I would also want jmm_SetVMGlobal() in management.cpp to call ManagedFlag::set_flag directly instead of doing it?s own type-switching. Thanks, /Staffan > > ---- > > Cheers, > David > > >> /Staffan >> >>> >>> David >>> >>>> /Staffan >>>> >>>>> >>>>>> >>>>>>>> inherent to ManagedFlags - so this refactoring seems wrong to me. >>>>>>>> What >>>>>>>> exactly is ManagedFlag supposed to represent? >>>>>>> >>>>>>> A shared functionality between attachListener.cpp, management.cpp and >>>>>>> the new diagnostic commands to be introduced later (as mentioned >>>>>>> in the >>>>>>> original synopsis of this RFR). It did seem preferable over just >>>>>>> copying >>>>>>> the implementation over to a few more places. >>>>>> >>>>>> I need to see a clearer bigger picture. What I currently see doesn't >>>>>> look right to me - attach mechanism functionality doesn't belong in a >>>>>> general purpose ManagedFlags abstraction. >>>>> >>>>> Bigger picture is that introducing yet another copy of the flag >>>>> management code for the purpose of adding the "VM.set_flag" >>>>> diagnostic command did seem unwieldy. The purpose of this >>>>> refactoring was to get the shared parts to one place. >>>>> >>>>> -JB- >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> All the new code seems incorrect: >>>>>>>>>> >>>>>>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>>>>>> return JNI_ERR; >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> op->arg(0) comes from the original code where op was an >>>>>>>>>> AttachOperation*. Here is should be using flag_name. >>>>>>>>> >>>>>>>>> Correct. Slipped through and then replicated :/ >>>>>>>> >>>>>>>> And obviously never compiled. RFRs should be for tested code. >>>>>>> >>>>>>> Yes, one should run always "make clean" first, just in case. I should >>>>>>> remember this well to prevent further embarrassment. >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>>>>>> >>>>>>>>> -JB- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> -JB- >> From yumin.qi at oracle.com Wed Jan 14 17:05:38 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 14 Jan 2015 09:05:38 -0800 Subject: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error In-Reply-To: <54B69A49.60503@oracle.com> References: <54B5BD73.9070406@oracle.com> <54B5E8F4.7020404@oracle.com> <54B69A49.60503@oracle.com> Message-ID: <54B6A1E2.3080009@oracle.com> I'm not a "R"eviewer, so you still need one. (Forgot to mention in my reply email). Thanks Yumin On 1/14/2015 8:33 AM, Jiangli Zhou wrote: > Hi Yumin, > > Thanks for the review! Will fix the copyright. > > Thanks, > Jiangli > > On 01/13/2015 07:56 PM, Yumin Qi wrote: >> Looks good to me. Could you update the copyright year? >> >> Thanks >> Yumin >> >> On 1/13/2015 4:50 PM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the fix for JDK-8067982 >>> (Some jcmd >>> /gc/heap_dump tests failed: hprof output contains warning or error). >>> The jcmd heap_dump tests failed due to incomplete symbol information >>> in the dump output. The shared symbols are not included in the dump >>> output because they are not in the SymbolTable, but in a separate >>> table within the shared archive. The fix is to include the shared >>> symbols when iterating all symbols in >>> SymbolTable::symbols_do(SymbolClosure). >>> >>> http://cr.openjdk.java.net/~jiangli/8067982/webrev.00/ >>> >>> Tested with vm.jcmd tests and jprt. All failed jcmd heap dump tests >>> passed with the fix. >>> >>> Thanks, >>> Jiangli >> > From serguei.spitsyn at oracle.com Wed Jan 14 18:20:12 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Jan 2015 10:20:12 -0800 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B66FA0.7020108@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B66FA0.7020108@oracle.com> Message-ID: <54B6B35C.3070600@oracle.com> It looks Ok (a copyright comment can be updated as well). However, there is still a major issue with this API per David H. Did you file new bug for this? Thanks, Serguei On 1/14/15 5:31 AM, Dmitry Samersoff wrote: > Any other reviewers? > > -Dmitry > > On 2015-01-13 08:10, David Holmes wrote: >> Hi Dmitry, >> >> Short version: okay but I'm going to file a bug to have sun.misc.Perf >> fixed properly. >> >> Long version ... read below :) >> >> Thanks, >> David >> >> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>> >>> The fix explicitly checks for UsePerfData and if it's false make >>> Perf:detach a NOP. >> That sidesteps the assertion failure but there is a bigger semantic >> issue here I think - which is why the bug has remained open for so long. >> UsePerfData can disable a part of the backend of the "perf" >> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >> oblivious to that. It isn't even really clear what UsePerfData pertains >> to. It impacts PerfMemory turning a number of methods into no-ops - but >> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >> What is a no-op is the initialization of PerfMemory (perfMemory_init) >> during VM startup, and also the teardown (perfMemory_exit) during VM >> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >> flag (in part) by not initializing the PerfMemory subsystem, but the >> PerfMemory public apis are still enabled and invoked from the JDK code. >> That doesn't make sense to me - we should fail to attach and in doing so >> not put in place the Cleaner code that will attempt the detach. But >> sun.misc.Perf doesn't understand that anything can fail. :( >> >> Your workaround avoids calling PerfMemory::detach from the Perf_detach >> code by checking UsePerfData, but arguably the check should be inside >> PerfMemory::detach operation (which unfortunately is OS specific). >> >>> -Dmitry >>> > From john.r.rose at oracle.com Wed Jan 14 19:12:30 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Jan 2015 11:12:30 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B68056.3090706@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> Message-ID: On Jan 14, 2015, at 6:42 AM, Bertrand Delsart wrote: > > I would not prevent the JITs from using RBP as long as the changeset is not sufficient to guarantee the profiling will work... and IMHO solving the JSR292 issue will be much more intrusive (impacting HotSpot stack walking code). Here are some thoughts on that. SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard requirement for x86 to take over RBP. (Deep background: This purpose, in method handle support, is to allow an adapter to make changes to the caller's SP. The adapter is the initial callee from the caller, but may change argument shape, and tail-calls the ultimate callee. Because it is a tail-call, the original caller must have a spot where his original SP can be preserved. The preservation works because the original caller knows he is calling a MH.invoke method, which requires the extra argument preservation. The repertoire of argument shape changes is quite small, actually; it is not a very general mechanism since the LF machinery was put in. Perhaps the whole thing could be removed somehow, by finding alternative techniques for the few remaining changes. OTOH, this SP-restoring mechanism may be helpful in doing more a general tail-call mechanism, and perhaps in managing int/comp mode changes more cleanly, so I'd like us to keep it. And document it better.) Any register or stack slot will do for this purpose, as long as (i) its value can be recovered after the MH.invoke call returns to the caller, and (ii) its value can be dug up somehow during stack walking. There are only a couple of places where stack walking code needs to sample the value, so they should be adjustable. Both x86 and SPARC use registers which are callee-save (or "non-volatile across calls") which satisfy properties (i) and (ii). A standard stack slot (addressed based on caller's RBP) would probably also satisfy those properties. A variably-positioned stack slot would also work, which would require registering the position in each CodeBlob. That's unpleasant extra detail, but it would align somewhat with the current logic which allows each CodeBlob (nmethod, actually) to advertise which call sites need the special processing (see the function is_method_handle_return(caller_pc)). I recommend reserving a dead word of space in every stack frame that makes MH.invoke calls, at a fixed position relative to that frame's RBP. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Thu Jan 15 01:14:53 2015 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 14 Jan 2015 17:14:53 -0800 Subject: RFR 8066708: JMXStartStopTest fails to connect to port 38112 In-Reply-To: <54AFC6EA.8080708@oracle.com> References: <54860B75.5070008@oracle.com> <548644A7.9040103@oracle.com> <5486EA27.800@oracle.com> <5489A4F4.5030600@oracle.com> <5489AD7F.7090200@oracle.com> <5492E4D1.7040501@oracle.com> <54AC5B14.1020001@oracle.com> <54AF4203.6040000@oracle.com> <54AFC6EA.8080708@oracle.com> Message-ID: <54B7148D.8000406@oracle.com> On 1/9/15 4:17 AM, Jaroslav Bachorik wrote: > I've changed the PortAllocator to allocate an array of unique random ports > instead of letting ServerSocket to take care of it. > > I ran the test 200x in a tight loop without a failure. > > I hope this will resolve this test's intermittent failures due to port conflicts > once and for all. > > Update: http://cr.openjdk.java.net/~jbachorik/8066708/webrev.03 Hi Jaroslav, Good to hear that the test seems to be running more reliably. (I'm assuming that you'd see failures before if you ran it 200x in a tight loop.) This is probably because you're avoiding the open/close/reopen approach that we've now thoroughly discredited. :-) That said, it still looks to me like the code is more complex than it needs to be. You're the one who's going to be maintaining it, but if it were me, I'd put more effort into simplifying it. Here are a few approaches I'd suggest. 1) It looks like occupyPort() is used only once. This is I think the only place in PortAllocator that actually opens a socket. It's used in test_09 where it looks like the intent is to keep a port busy by opening a socket, and then making sure that the JMX stuff in the child process does the right thing when it encounters a busy port. Since this is the only place that needs a real socket, you might as well move the ServerSocket creation stuff out of PortAllocator and create it directly here with new ServerSocket(0). This should never fail with a BindException, so you needn't worry about retries. Then get the local port, and pass it to the subprocess. You should put this within a try-with-resources in test_09 so that the socket will be closed properly. 2) If you do this, then PortAllocator gets a lot simpler. There's no need to keep a collection of sockets, so release() can go away, and the finally-block of withAllocatedPorts can go away too. 3) Now PortAllocator's only instance state is the array of random port numbers. But once this is generated, the only reason PortAllocator stays around is to host the getter for array elements; basically it's just a wrapper for the array. And the reset() method regenerates the array. The essence of this is now just a function that returns an array of N random port numbers. You can pass the array directly to the Task and it can just use the ports from the array, instead of calling a getter. If there's a BindException and a "reset" needs to be done, this is just another call to the function to generate another array. So there's really no longer a need to have PortAllocator instances. These is a bit farther afield from this particular change, but there are some other opportunities for simplification: 4) Each of the test_NN methods consists entirely of a println followed by a withAllocatedPorts() call which is passed a long multi-line lambda. (In my book, multi-line lambdas are a bit of a code smell.) The withAllocatedPorts() method essentially implements the retry-on-BindException policy. Since each test_NN method is invoked reflectively by a mini-framework in the test, you could merge that logic into the mini-framework. In turn, each test method would then call the random port generator method and get an array of the requested number of ports, and just use them. This would removing a level of nesting and a few lines of vertical space from every test method. 5) Most (but not all) of the tests call doSomething and then follow it with a try/finally block that calls stop(). It seems like this commonality could be extracted somehow, but it eludes me at the moment. 6) The internal jcmd() methods all have a void return value, but some of them take a Consumer, which is usually passed a lambda argument that performs some test and then sets an AtomicBoolean as a side effect. (This is another code smell. Sometimes it's necessary, but only sometimes.) This parameter really wants to be a Predicate. The jcmd() method can just call the predicate and keep track of the results, and return a final result boolean that, for example, indicates whether the predicate had ever returend true. I'm not sure that's exactly the semantic you want. But a preferable idiom is to return a value instead of calling a lambda that performs side effects on captured locals. -- This is quite a bit of stuff, and I don't necessarily expect you to fix it all. At least not in this changeset. But I've found that investing in refactoring of test code usually pays off, as it makes it easier to maintain the tests when you're forced to make changes to them again in six months. s'marks From david.holmes at oracle.com Thu Jan 15 07:23:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jan 2015 17:23:27 +1000 Subject: RFR 8067447: Factor out the shared implementation of the VM flags manipulation code In-Reply-To: <5734052E-E964-4780-90E3-A96C2B864152@oracle.com> References: <54915894.3060101@oracle.com> <54AC8C6E.5030702@oracle.com> <54AD57FA.1070001@oracle.com> <54ADEF57.5070804@oracle.com> <54AE4C4E.2000506@oracle.com> <54AE662F.7060208@oracle.com> <54AE851F.3000905@oracle.com> <8CF60A04-D1C1-4824-B9F1-8E53BADF4013@oracle.com> <54B50DDB.3020502@oracle.com> <94135E81-D1D7-4444-A4E6-2620ADE57C31@oracle.com> <54B61FD7.3010707@oracle.com> <5734052E-E964-4780-90E3-A96C2B864152@oracle.com> Message-ID: <54B76AEF.8050809@oracle.com> Hi Staffan On 15/01/2015 2:38 AM, Staffan Larsen wrote: > >> On 14 jan 2015, at 08:50, David Holmes wrote: >> >> Hi Staffan, >> >> On 13/01/2015 10:27 PM, Staffan Larsen wrote: >>> >>>> On 13 jan 2015, at 13:21, David Holmes >>> > wrote: >>>> >>>> Hi Staffan, >>>> >>>> On 13/01/2015 5:26 PM, Staffan Larsen wrote: >>>>> >>>>>> On 8 jan 2015, at 14:24, Jaroslav Bachorik >>>>>> > >>>>>> wrote: >>>>>> >>>>>> On 8.1.2015 12:12, David Holmes wrote: >>>>>>> On 8/01/2015 7:22 PM, Jaroslav Bachorik wrote: >>>>>>>> On 8.1.2015 03:45, David Holmes wrote: >>>>>>>>> On 8/01/2015 1:59 AM, Jaroslav Bachorik wrote: >>>>>>>>>> On 7.1.2015 02:31, David Holmes wrote: >>>>>>>>>>> On 17/12/2014 8:19 PM, Jaroslav Bachorik wrote: >>>>>>>>>>>> Please, review the following change. >>>>>>>>>>>> >>>>>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8067447 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8067447/webrev.00 >>>>>>>>>>>> >>>>>>>>>>>> This patch is a precursor for implementing >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054890 which itself is a >>>>>>>>>>>> part >>>>>>>>>>>> of JEP-228 (https://bugs.openjdk.java.net/browse/JDK-8043764). >>>>>>>>>>>> >>>>>>>>>>>> Here, the code related to manipulating JVM flags is extracted to a >>>>>>>>>>>> separate ManagedFlags class and the codebease is adjusted to >>>>>>>>>>>> use this >>>>>>>>>>>> class. >>>>>>>>>>> >>>>>>>>>>> Not clear to me what this is addressing exactly - do we really need >>>>>>>>>>> platform specific variants of "set flag" ?? >>>>>>>>>> >>>>>>>>>> It has just been moved from the corresponding >>>>>>>>>> attachListener_.cpp >>>>>>>>>> files. And it is 'pd_set_flag' what, I suppose, means "platform >>>>>>>>>> dependent"? >>>>>>>>> >>>>>>>>> Yes it does and it mostly made sense inside the already pd >>>>>>>>> attachListener implementations, but it isn't obvious to me that >>>>>>>>> it makes >>>>>>>>> sense in the ManagedFlag context. It is the choice about whether the >>>>>>>>> flag can be changed that is "pd" not the actual setting and those >>>>>>>>> choices are inherent to the attachListener mechanism they are not >>>>>>>> >>>>>>>> Why would the ability to set Solaris specific flags via DTrace be >>>>>>>> specific to the attachListener mechanism? Also, AFAICS here it is the >>>>>>>> mechanism of setting the flag which is "pd" and not the choice >>>>>>>> (DTrace::* vs CommandLineFlags::*) >>>>>>> >>>>>>> The attachListener allows for manipulating VM flags if the attach >>>>>>> mechanism is used. In the Solaris case it turns on some DTrace flags. >>>>>>> The attach mechanism factors that into a pd_set_flags method that is >>>>>>> called for a given AttachOperation and so allows per platform >>>>>>> behaviour. >>>>>>> But this is all part of the attach mechanism it isn't part of some >>>>>>> general flag management process. >>>>>> >>>>>> I think I see the problem. Sorry it took me so long. >>>>>> >>>>>> But, why the DTrace flags are only allowed to be set via the >>>>>> attachListener? Can we allow their manipulation via com.sun.Flag? Or >>>>>> they need to stay restricted to the attach mechanism only for >>>>>> whatever reason? >>>>> >>>>> I don?t think there is any reason these Dtrace flags should only ba >>>>> changeable by the attach mechanism. They could just as well be >>>>> changed from JMX or jcmd. I guess the code is in attach because >>>>> attach was the only way of changing flags at the time. The only >>>>> difference I can see for these Dtrace flags compared to other flags >>>>> is that some action needs to be taken if the flag is changed (calls >>>>> to DTrace::set_extended_dprobes()). I also think the Dtrace flags >>>>> should be marked as ?manageable.? >>>> >>>> I'm having a separate discussion with Jaroslav via email. The key >>>> thing here (and it is wrong in the refactor) is that the pd_set_flag >>>> in the AttachListener only exists to allow for non-manageable flags to >>>> be set. That functionality is specific to the AttachListener code and >>>> makes no sense for a ManagedFlag abstraction. >>> >>> I don?t agree - or perhaps I am misunderstanding. I thought ManagedFlag >>> was supposed to be the common way for attach, jcmd, jmx or any other >>> future API to change flags in runtime. The DTrace flags aren?t special >>> to AttachListener - they should be changeable from jmx and jcmd as well. >>> Thus, the special handling of them should be in ManagedFlag, no? >> >> The DTrace flags are not manageable flags. > > I think that is a mistake. They should be. I do not understand why they are not - at the very least they should be ?product_rw?. Perhaps product_rw did not exist when they were introduced? product_rw is only for internal private flags. The DTrace flags are not private, so Manageable seems like the way to go, taking into account: // A flag can be made as "manageable" only if // - the flag is defined in a CCC as an external exported interface. // - the VM implementation supports dynamic setting of the flag. // This implies that the VM must *always* query the flag variable // and not reuse state related to the flag state at any given time. // - you want the flag to be queried programmatically by the customers. > >> If they change to be manageable then they can be modified via ManagedFlag. But the second problem with these flags is that setting them after VM initialization you have to not only change the value of the flag, you have to call the additional methods like AttachListener does. Maybe that prevents them from being "manageable"? - otherwise ManagedFlags has to know what actions occur in arguments.cpp when the flag is set during VM startup. > > Yes, ManagedFlags should know what actions should be taken if a managed flag is changed. This is precisely why we want to introduce a ManagedFlags abstraction. Currently that logic is spread out in attachListener.cpp and management.cpp (see the code for ?MaxHeapFreeRatio?). We want to consolidate it into one place (and in the future add jcmd as an additional way to change flags). > > Most managed flags don?t need an action to be taken when they are changed, but the Dtrace and MaxHeapFreeRatio flags do. Not sure how you will use ManagedFlag in the context of argument processing, to keep these actions in one place ?? Also this doesn't seem clear cut in the case of ExtendedDTraceProbes as arguments.cpp simply does: } else if (match_option(option, "-XX:+ExtendedDTraceProbes")) { FLAG_SET_CMDLINE(bool, ExtendedDTraceProbes, true); FLAG_SET_CMDLINE(bool, DTraceMethodProbes, true); FLAG_SET_CMDLINE(bool, DTraceAllocProbes, true); FLAG_SET_CMDLINE(bool, DTraceMonitorProbes, true); whereas the attachListener code doesn't touch the actual ExtendedDTraceProbes flag value but calls: DTrace::set_extended_dprobes(flag); which potentially sets the other three DTrace* flags and if it did that it deoptimizes the world! None of which seems like code that ManagedFlag should have any knowledge of. So at best I think the attachlistener code might use the ManagedFlag abstraction rather than the direct calls to: CommandLineFlags::boolAtPut((char*)flag, strlen(flag), &value, Flag::ATTACH_ON_DEMAND); ?? > Perhaps ?ManagedFlags? should change name to WriteableFlags? Would that make it?s purpose clearer? We do have flags marked both ?manageble? and ?product_rw? in globals.hpp that can be changed. If you expand it to cover product_rw then a different name might be better. >> >> This is what I wrote in the email (which Jaroslav has not had a chance to respond to yet): >> >> The "pd" specific part of AttachListener set_flag is to allow the attach_listener code to set none-manageable flags (the Dtrace flags are product not manageable), and as such should not form part of the ManagedFlags code. And you misfactored that part because you have it on an else that will only happen if an invalid flag name is passed in: >> >> 184 Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); >> 185 if (f) { >> 186 // only manageable flags are allowed to be set >> 187 if (f->is_external() && f->is_writeable()) { >> // ... set the flag >> 204 } else { >> 205 out->print_cr("Only 'manageable' flags can be set."); >> 206 res = JNI_ERR; >> 207 } >> 208 } else { >> // find_flag failed to find the flag >> 209 res = pd_set_flag(flag_name, flag_value, origin, out); >> 210 } >> >> whereas AttachListener has: >> >> Flag* f = Flag::find_flag((char*)name, strlen(name)); >> if (f && f->is_external() && f->is_writeable()) { >> // set flag >> } else { >> return AttachListener::pd_set_flag(op, out); >> } >> >> and this else part is for the non-manageable case (an invalid flag name will just be treated as an error by the pd_set_flag logic: "flag can not be changed"). >> >> So ManagedFlags::set_flag should not have a pd_set_flag at all but just: >> >> Flag* f = Flag::find_flag((char*)flag_name, strlen(flag_name)); >> if (f) { >> // only manageable flags are allowed to be set >> if (f->is_external() && f->is_writeable()) { >> // ... set the flag >> } else { >> out->print_cr("Only 'manageable' flags can be set."); >> res = JNI_ERR; >> } >> } else { >> out->print_cr("Flag not found"); >> res = JNI_ERR; >> } >> > > Yes, agree on the above. Okay. I'll await a further webrev then. :) >> And AttachListener::set_flag should look like: >> >> static jint set_flag(AttachOperation* op, outputStream* out) { >> >> const char* name = NULL; >> if ((name = op->arg(0)) == NULL) { >> out->print_cr("flag name is missing"); >> return JNI_ERR; >> } >> >> if (ManagedFlags::set_flag(op->arg(0), op->arg(1), >> Flag::ATTACH_ON_DEMAND, out) == JNI_ERR) { >> // not a manageable flag - see if there is platform specific >> // logic for this flag >> return AttachListener::pd_set_flag(op, out); >> } >> else { >> return JNI_OK; >> } >> } > > We should make the Dtrace flags into product_rw flags and then we can remove all the pd_set_flag() methods. I can?t see a reason for them. As per above I don't think what attach listener does in this case is really something that belong in ManagedFlags. >> >> The only issue with the above is that ManagedFlags::set_flag is going to write an error message to the outputstream, which is not wanted when processing a pd flag. In my opinion ManagedFlag::set_flag shouldn't be concerned with writing error messages as it doesn't know what constitutes an error. In which case the ManagedFlag::set_flag logic simplifies further, but AttachListener would have to do additional work itself if it want to produce error messages. > > ManagedFlags should know what the errors are and the errors should be propagated to attachListener (and management.cpp) so that they can be further propagated to the user. If we no longer pass non-manageable flags that would be okay. The problem I was alluding is where ManagedFlag writes an error "Not a manageable flag" when it isn't actually an error. > I would also want jmm_SetVMGlobal() in management.cpp to call ManagedFlag::set_flag directly instead of doing it?s own type-switching. Haven't looked at that code so don't know how amenable it will be to this. Thanks, David > Thanks, > /Staffan > > >> >> ---- >> >> Cheers, >> David >> >> >>> /Staffan >>> >>>> >>>> David >>>> >>>>> /Staffan >>>>> >>>>>> >>>>>>> >>>>>>>>> inherent to ManagedFlags - so this refactoring seems wrong to me. >>>>>>>>> What >>>>>>>>> exactly is ManagedFlag supposed to represent? >>>>>>>> >>>>>>>> A shared functionality between attachListener.cpp, management.cpp and >>>>>>>> the new diagnostic commands to be introduced later (as mentioned >>>>>>>> in the >>>>>>>> original synopsis of this RFR). It did seem preferable over just >>>>>>>> copying >>>>>>>> the implementation over to a few more places. >>>>>>> >>>>>>> I need to see a clearer bigger picture. What I currently see doesn't >>>>>>> look right to me - attach mechanism functionality doesn't belong in a >>>>>>> general purpose ManagedFlags abstraction. >>>>>> >>>>>> Bigger picture is that introducing yet another copy of the flag >>>>>> management code for the purpose of adding the "VM.set_flag" >>>>>> diagnostic command did seem unwieldy. The purpose of this >>>>>> refactoring was to get the shared parts to one place. >>>>>> >>>>>> -JB- >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> All the new code seems incorrect: >>>>>>>>>>> >>>>>>>>>>> jint ManagedFlags::pd_set_flag(const char* flag_name, const char* >>>>>>>>>>> flag_value, Flag::Flags origin, outputStream* out) { >>>>>>>>>>> out->print_cr("flag '%s' cannot be changed", op->arg(0)); >>>>>>>>>>> return JNI_ERR; >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> op->arg(0) comes from the original code where op was an >>>>>>>>>>> AttachOperation*. Here is should be using flag_name. >>>>>>>>>> >>>>>>>>>> Correct. Slipped through and then replicated :/ >>>>>>>>> >>>>>>>>> And obviously never compiled. RFRs should be for tested code. >>>>>>>> >>>>>>>> Yes, one should run always "make clean" first, just in case. I should >>>>>>>> remember this well to prevent further embarrassment. >>>>>>>> >>>>>>>> -JB- >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Updated webrev: >>>>>>>>>> http://cr.openjdk.java.net/~jbachorik/8067447/webrev.01 >>>>>>>>>> >>>>>>>>>> -JB- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> -JB- >>> > From david.holmes at oracle.com Thu Jan 15 07:36:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jan 2015 17:36:16 +1000 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B6B35C.3070600@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B66FA0.7020108@oracle.com> <54B6B35C.3070600@oracle.com> Message-ID: <54B76DF0.1030807@oracle.com> On 15/01/2015 4:20 AM, serguei.spitsyn at oracle.com wrote: > It looks Ok (a copyright comment can be updated as well). > However, there is still a major issue with this API per David H. > Did you file new bug for this? I will file one but haven't got to it yet. David > Thanks, > Serguei > > On 1/14/15 5:31 AM, Dmitry Samersoff wrote: >> Any other reviewers? >> >> -Dmitry >> >> On 2015-01-13 08:10, David Holmes wrote: >>> Hi Dmitry, >>> >>> Short version: okay but I'm going to file a bug to have sun.misc.Perf >>> fixed properly. >>> >>> Long version ... read below :) >>> >>> Thanks, >>> David >>> >>> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>>> >>>> The fix explicitly checks for UsePerfData and if it's false make >>>> Perf:detach a NOP. >>> That sidesteps the assertion failure but there is a bigger semantic >>> issue here I think - which is why the bug has remained open for so long. >>> UsePerfData can disable a part of the backend of the "perf" >>> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >>> oblivious to that. It isn't even really clear what UsePerfData pertains >>> to. It impacts PerfMemory turning a number of methods into no-ops - but >>> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >>> What is a no-op is the initialization of PerfMemory (perfMemory_init) >>> during VM startup, and also the teardown (perfMemory_exit) during VM >>> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >>> flag (in part) by not initializing the PerfMemory subsystem, but the >>> PerfMemory public apis are still enabled and invoked from the JDK code. >>> That doesn't make sense to me - we should fail to attach and in doing so >>> not put in place the Cleaner code that will attempt the detach. But >>> sun.misc.Perf doesn't understand that anything can fail. :( >>> >>> Your workaround avoids calling PerfMemory::detach from the Perf_detach >>> code by checking UsePerfData, but arguably the check should be inside >>> PerfMemory::detach operation (which unfortunately is OS specific). >>> >>>> -Dmitry >>>> >> > From serguei.spitsyn at oracle.com Thu Jan 15 07:40:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 14 Jan 2015 23:40:14 -0800 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B76DF0.1030807@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B66FA0.7020108@oracle.com> <54B6B35C.3070600@oracle.com> <54B76DF0.1030807@oracle.com> Message-ID: <54B76EDE.1010001@oracle.com> On 1/14/15 11:36 PM, David Holmes wrote: > On 15/01/2015 4:20 AM, serguei.spitsyn at oracle.com wrote: >> It looks Ok (a copyright comment can be updated as well). >> However, there is still a major issue with this API per David H. >> Did you file new bug for this? > > I will file one but haven't got to it yet. Ok, thanks. Just wanted to make sure it was not forgotten. Thanks, Serguei > > David > >> Thanks, >> Serguei >> >> On 1/14/15 5:31 AM, Dmitry Samersoff wrote: >>> Any other reviewers? >>> >>> -Dmitry >>> >>> On 2015-01-13 08:10, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> Short version: okay but I'm going to file a bug to have sun.misc.Perf >>>> fixed properly. >>>> >>>> Long version ... read below :) >>>> >>>> Thanks, >>>> David >>>> >>>> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>>>> Hi Everybody, >>>>> >>>>> Please review the fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>>>> >>>>> The fix explicitly checks for UsePerfData and if it's false make >>>>> Perf:detach a NOP. >>>> That sidesteps the assertion failure but there is a bigger semantic >>>> issue here I think - which is why the bug has remained open for so >>>> long. >>>> UsePerfData can disable a part of the backend of the "perf" >>>> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >>>> oblivious to that. It isn't even really clear what UsePerfData >>>> pertains >>>> to. It impacts PerfMemory turning a number of methods into no-ops - >>>> but >>>> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >>>> What is a no-op is the initialization of PerfMemory (perfMemory_init) >>>> during VM startup, and also the teardown (perfMemory_exit) during VM >>>> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >>>> flag (in part) by not initializing the PerfMemory subsystem, but the >>>> PerfMemory public apis are still enabled and invoked from the JDK >>>> code. >>>> That doesn't make sense to me - we should fail to attach and in >>>> doing so >>>> not put in place the Cleaner code that will attempt the detach. But >>>> sun.misc.Perf doesn't understand that anything can fail. :( >>>> >>>> Your workaround avoids calling PerfMemory::detach from the Perf_detach >>>> code by checking UsePerfData, but arguably the check should be inside >>>> PerfMemory::detach operation (which unfortunately is OS specific). >>>> >>>>> -Dmitry >>>>> >>> >> From bertrand.delsart at oracle.com Thu Jan 15 11:13:08 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Thu, 15 Jan 2015 12:13:08 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> Message-ID: <54B7A0C4.6040009@oracle.com> On 14/01/2015 20:12, John Rose wrote: > On Jan 14, 2015, at 6:42 AM, Bertrand Delsart > > wrote: >> >> I would not prevent the JITs from using RBP as long as the changeset >> is not sufficient to guarantee the profiling will work... and IMHO >> solving the JSR292 issue will be much more intrusive (impacting >> HotSpot stack walking code). > > Here are some thoughts on that. > > SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle > support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard > requirement for x86 to take over RBP. > > (Deep background: This purpose, in method handle support, is to allow > an adapter to make changes to the caller's SP. The adapter is the > initial callee from the caller, but may change argument shape, and > tail-calls the ultimate callee. Because it is a tail-call, the original > caller must have a spot where his original SP can be preserved. The > preservation works because the original caller knows he is calling a > MH.invoke method, which requires the extra argument preservation. The > repertoire of argument shape changes is quite small, actually; it is not > a very general mechanism since the LF machinery was put in. Perhaps the > whole thing could be removed somehow, by finding alternative techniques > for the few remaining changes. OTOH, this SP-restoring mechanism may be > helpful in doing more a general tail-call mechanism, and perhaps in > managing int/comp mode changes more cleanly, so I'd like us to keep it. > And document it better.) > > Any register or stack slot will do for this purpose, as long as (i) its > value can be recovered after the MH.invoke call returns to the caller, > and (ii) its value can be dug up somehow during stack walking. There > are only a couple of places where stack walking code needs to sample the > value, so they should be adjustable. > > Both x86 and SPARC use registers which are callee-save (or "non-volatile > across calls") which satisfy properties (i) and (ii). A standard stack > slot (addressed based on caller's RBP) would probably also satisfy those > properties. > > A variably-positioned stack slot would also work, which would require > registering the position in each CodeBlob. That's unpleasant extra > detail, but it would align somewhat with the current logic which allows > each CodeBlob (nmethod, actually) to advertise which call sites need the > special processing (see the function is_method_handle_return(caller_pc)). > > I recommend reserving a dead word of space in every stack frame that > makes MH.invoke calls, at a fixed position relative to that frame's RBP. > > ? John I perfectly agree that it is doable (and with your proposed approach). I just wanted to be sure people were aware that the RFE is more complex than what the current changeset may suggest. We are not just taking about reviewing and integrating a complete changeset contributed by the community. There is more work needed, either by the community or by Oracle. This will require changes at least in C1 and C2 call sequences, in the stack walking, in the creation and sizing of compiled frames... Regards, Bertrand. -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ivan.gerasimov at oracle.com Thu Jan 15 12:09:15 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 15 Jan 2015 15:09:15 +0300 Subject: RFR 8069048: (process) Suspend finishing threads when process exits [win] Message-ID: <54B7ADEB.3000506@oracle.com> Hello everyone! This is yet another iteration in the attempt to solve the 'wrong exit code' bug on Windows [1]. The wrong exit code has been observed once again with one of the regression tests. The suspicion is that this might be due to the critical section had been destroyed before all the children threads were terminated. In that case, one of the threads had been unblocked and called _endthreadex(), which resulted in a race. To address this scenario, it is proposed to make the thread that is about to exit the process raise a flag. If the flag is raised, any threads wishing to exit should instead suspend themselves. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8069048 WEBREV: http://cr.openjdk.java.net/~igerasim/8069048/0/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-6573254 Sincerely yours, Ivan From david.holmes at oracle.com Thu Jan 15 12:20:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Jan 2015 22:20:52 +1000 Subject: RFR 8069048: (process) Suspend finishing threads when process exits [win] In-Reply-To: <54B7ADEB.3000506@oracle.com> References: <54B7ADEB.3000506@oracle.com> Message-ID: <54B7B0A4.6000107@oracle.com> Let's give it another shot :) Reviewed. Thanks, David On 15/01/2015 10:09 PM, Ivan Gerasimov wrote: > Hello everyone! > > This is yet another iteration in the attempt to solve the 'wrong exit > code' bug on Windows [1]. > The wrong exit code has been observed once again with one of the > regression tests. > > The suspicion is that this might be due to the critical section had been > destroyed before all the children threads were terminated. > In that case, one of the threads had been unblocked and called > _endthreadex(), which resulted in a race. > > To address this scenario, it is proposed to make the thread that is > about to exit the process raise a flag. > If the flag is raised, any threads wishing to exit should instead > suspend themselves. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8069048 > WEBREV: http://cr.openjdk.java.net/~igerasim/8069048/0/webrev/ > > [1] https://bugs.openjdk.java.net/browse/JDK-6573254 > > Sincerely yours, > Ivan From kevin.walls at oracle.com Thu Jan 15 14:18:19 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 15 Jan 2015 14:18:19 +0000 Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool Message-ID: <54B7CC2B.4070702@oracle.com> Hi, This is a review request for a change in JVMTI, where we os::free() some objects where we should delete them. The problem was logged against 7, though it exists up to the present day, below is a diff in current latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot Testing: I've used a native JVMTI agent to call GetConstantPool() during an object allocation callback. Memory usage does appear less after the change, it can be 5-6MB in a trivial testcase with a small number of allocations monitored, each inoking GetConstantlPool(). (In my test agent the GetConstantPool() call returns a JVMTI error 101 after a fairly short time and a relatively small number of allocations are monitored.) If this is OK to submit without testcase that's great. I don't see other examples of native agents in the standard hotspot tests. bug https://bugs.openjdk.java.net/browse/JDK-8035938 diff: $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp @@ -68,11 +68,11 @@ ~JvmtiConstantPoolReconstituter() { if (_symmap != NULL) { - os::free(_symmap); + delete _symmap; _symmap = NULL; } if (_classmap != NULL) { - os::free(_classmap); + delete _classmap; _classmap = NULL; } } Thanks Kevin From vladimir.kozlov at oracle.com Thu Jan 15 17:50:01 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Jan 2015 09:50:01 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B7A0C4.6040009@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> Message-ID: <54B7FDC9.8020103@oracle.com> Thank you, Bertrand and John I added this conversation to the bug report. Thanks, Vladimir On 1/15/15 3:13 AM, Bertrand Delsart wrote: > On 14/01/2015 20:12, John Rose wrote: >> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart >> > wrote: >>> >>> I would not prevent the JITs from using RBP as long as the changeset >>> is not sufficient to guarantee the profiling will work... and IMHO >>> solving the JSR292 issue will be much more intrusive (impacting >>> HotSpot stack walking code). >> >> Here are some thoughts on that. >> >> SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle >> support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard >> requirement for x86 to take over RBP. >> >> (Deep background: This purpose, in method handle support, is to allow >> an adapter to make changes to the caller's SP. The adapter is the >> initial callee from the caller, but may change argument shape, and >> tail-calls the ultimate callee. Because it is a tail-call, the original >> caller must have a spot where his original SP can be preserved. The >> preservation works because the original caller knows he is calling a >> MH.invoke method, which requires the extra argument preservation. The >> repertoire of argument shape changes is quite small, actually; it is not >> a very general mechanism since the LF machinery was put in. Perhaps the >> whole thing could be removed somehow, by finding alternative techniques >> for the few remaining changes. OTOH, this SP-restoring mechanism may be >> helpful in doing more a general tail-call mechanism, and perhaps in >> managing int/comp mode changes more cleanly, so I'd like us to keep it. >> And document it better.) >> >> Any register or stack slot will do for this purpose, as long as (i) its >> value can be recovered after the MH.invoke call returns to the caller, >> and (ii) its value can be dug up somehow during stack walking. There >> are only a couple of places where stack walking code needs to sample the >> value, so they should be adjustable. >> >> Both x86 and SPARC use registers which are callee-save (or "non-volatile >> across calls") which satisfy properties (i) and (ii). A standard stack >> slot (addressed based on caller's RBP) would probably also satisfy those >> properties. >> >> A variably-positioned stack slot would also work, which would require >> registering the position in each CodeBlob. That's unpleasant extra >> detail, but it would align somewhat with the current logic which allows >> each CodeBlob (nmethod, actually) to advertise which call sites need the >> special processing (see the function is_method_handle_return(caller_pc)). >> >> I recommend reserving a dead word of space in every stack frame that >> makes MH.invoke calls, at a fixed position relative to that frame's RBP. >> >> ? John > > I perfectly agree that it is doable (and with your proposed approach). > > I just wanted to be sure people were aware that the RFE is more complex > than what the current changeset may suggest. We are not just taking > about reviewing and integrating a complete changeset contributed by the > community. There is more work needed, either by the community or by > Oracle. This will require changes at least in C1 and C2 call sequences, > in the stack walking, in the creation and sizing of compiled frames... > > Regards, > > Bertrand. From serguei.spitsyn at oracle.com Thu Jan 15 21:26:19 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 15 Jan 2015 13:26:19 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <54B7A0C4.6040009@oracle.com> References: <5486C67C.2030302@oracle.com> <5486CB9E.2090505@oracle.com> <54B5CF3D.4070307@oracle.com> <54B68056.3090706@oracle.com> <54B7A0C4.6040009@oracle.com> Message-ID: <54B8307B.5040208@oracle.com> On 1/15/15 3:13 AM, Bertrand Delsart wrote: > On 14/01/2015 20:12, John Rose wrote: >> On Jan 14, 2015, at 6:42 AM, Bertrand Delsart >> > >> wrote: >>> >>> I would not prevent the JITs from using RBP as long as the changeset >>> is not sufficient to guarantee the profiling will work... and IMHO >>> solving the JSR292 issue will be much more intrusive (impacting >>> HotSpot stack walking code). >> >> Here are some thoughts on that. >> >> SPARC uses L7 (L7_mh_SP_save) for the same purpose of method handle >> support as x86 uses RBP (rbp_mh_SP_save). So there's not a hard >> requirement for x86 to take over RBP. >> >> (Deep background: This purpose, in method handle support, is to allow >> an adapter to make changes to the caller's SP. The adapter is the >> initial callee from the caller, but may change argument shape, and >> tail-calls the ultimate callee. Because it is a tail-call, the original >> caller must have a spot where his original SP can be preserved. The >> preservation works because the original caller knows he is calling a >> MH.invoke method, which requires the extra argument preservation. The >> repertoire of argument shape changes is quite small, actually; it is not >> a very general mechanism since the LF machinery was put in. Perhaps the >> whole thing could be removed somehow, by finding alternative techniques >> for the few remaining changes. OTOH, this SP-restoring mechanism may be >> helpful in doing more a general tail-call mechanism, and perhaps in >> managing int/comp mode changes more cleanly, so I'd like us to keep it. >> And document it better.) >> >> Any register or stack slot will do for this purpose, as long as (i) its >> value can be recovered after the MH.invoke call returns to the caller, >> and (ii) its value can be dug up somehow during stack walking. There >> are only a couple of places where stack walking code needs to sample the >> value, so they should be adjustable. >> >> Both x86 and SPARC use registers which are callee-save (or "non-volatile >> across calls") which satisfy properties (i) and (ii). A standard stack >> slot (addressed based on caller's RBP) would probably also satisfy those >> properties. >> >> A variably-positioned stack slot would also work, which would require >> registering the position in each CodeBlob. That's unpleasant extra >> detail, but it would align somewhat with the current logic which allows >> each CodeBlob (nmethod, actually) to advertise which call sites need the >> special processing (see the function >> is_method_handle_return(caller_pc)). >> >> I recommend reserving a dead word of space in every stack frame that >> makes MH.invoke calls, at a fixed position relative to that frame's RBP. >> >> ? John > > I perfectly agree that it is doable (and with your proposed approach). > > I just wanted to be sure people were aware that the RFE is more > complex than what the current changeset may suggest. We are not just > taking about reviewing and integrating a complete changeset > contributed by the community. There is more work needed, either by the > community or by Oracle. This will require changes at least in C1 and > C2 call sequences, in the stack walking, in the creation and sizing of > compiled frames... Just want to note about the stack walking... It also impacts some places that people are normally unaware of: - SA-based stack walking (jstack utility) - Solaris-specific: jhelper.d (dtrace jstack action support) and libjvm_db.so (pstack utility support) Thanks, Serguei > > Regards, > > Bertrand. > From daniel.daugherty at oracle.com Fri Jan 16 00:01:08 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 15 Jan 2015 17:01:08 -0700 Subject: RFR 8069048: (process) Suspend finishing threads when process exits [win] In-Reply-To: <54B7ADEB.3000506@oracle.com> References: <54B7ADEB.3000506@oracle.com> Message-ID: <54B854C4.1010907@oracle.com> On 1/15/15 5:09 AM, Ivan Gerasimov wrote: > Hello everyone! > > This is yet another iteration in the attempt to solve the 'wrong exit > code' bug on Windows [1]. > The wrong exit code has been observed once again with one of the > regression tests. > > The suspicion is that this might be due to the critical section had > been destroyed before all the children threads were terminated. > In that case, one of the threads had been unblocked and called > _endthreadex(), which resulted in a race. > > To address this scenario, it is proposed to make the thread that is > about to exit the process raise a flag. > If the flag is raised, any threads wishing to exit should instead > suspend themselves. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8069048 > WEBREV: http://cr.openjdk.java.net/~igerasim/8069048/0/webrev/ src/os/windows/vm/os_windows.cpp line 3895: // don't let the current thread to proceed to _endthreadex() Typo: 'let the current thread to proceed to' -> 'let the current thread proceed to' Just making sure that I understand the revised algorithm: - before the EPT_PROCESS thread gets here, EPT_THREAD threads will work as before and call line 3909 _endthreadex() - after the EPT_PROCESS thread gets here and sets the flag on line 3886: OrderAccess::release_store(&process_exiting, 1); - an EPT_THREAD thread may have made it past flag check on line 3802: } else if (OrderAccess::load_acquire(&process_exiting) == 0) { but it will be blocked on line 3803: EnterCriticalSection(&crit_sect); - an EPT_THREAD thread that sees the flag set on line 3802 will drop into the self-suspend block on lines 3892-3900 - after the EPT_PROCESS thread exits the critical section, then any EPT_THREAD threads that were blocked trying to acquire the critical section will now see the flag set on line 3805: if (what == EPT_THREAD && OrderAccess::load_acquire(&process_exiting) == 0) { and drop into the self-suspend block on lines 3892-3900 Short version: any EPT_THREAD threads that arrive after the EPT_PROCESS thread owns the critical section will never call line 3909 _endthreadex() because they self-suspend. OK, I concur that this new algorithm looks correct and will reduce the number of threads racing through line 3909 _endthreadex() while the EPT_PROCESS thread is trying to call exit(). One possible hole remains that we've discussed before. If an EPT_THREAD thread calls _endthreadex() before the EPT_PROCESS thread gets here, and if the EPT_THREAD thread stalls in _endthreadex(), then it's still possible for that EPT_THREAD thread to mess up the exit code if it unblocks after the EPT_PROCESS thread has set the exit code. We've discussed this before and there's nothing we can do about other than try and reduce the probability by reducing the number of EPT_THREAD threads that are calling _endthreadex(). Thumbs up! Side note: A new failure of this mechanism was filed recently: JDK-8069068 VM warning: WaitForMultipleObjects timed out (0) ... https://bugs.openjdk.java.net/browse/JDK-8069068 The bug was filed against JDK9-B45 so it has the most recent fix (https://bugs.openjdk.java.net/browse/JDK-8066863). The weird part is that WaitForMultipleObjects() timed out without an error code being set. Don't know if that means anything in particular in the Win* APIS... This fix (8069048) may also reduce the probability of this failure mode because we'll be queueing fewer threads on the handle list... Dan > > [1] https://bugs.openjdk.java.net/browse/JDK-6573254 > > Sincerely yours, > Ivan From david.holmes at oracle.com Fri Jan 16 06:36:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Jan 2015 16:36:01 +1000 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B4DEC9.60209@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B4DEC9.60209@oracle.com> Message-ID: <54B8B151.3080705@oracle.com> On 13/01/2015 7:00 PM, Dmitry Samersoff wrote: > David, > > On 2015-01-13 08:10, David Holmes wrote: >> >> Short version: okay but I'm going to file a bug to have sun.misc.Perf >> fixed properly. > > Thank you and please, file a new bug (you can assign it to me directly). Filed: https://bugs.openjdk.java.net/browse/JDK-8069149 Sorry for the delay. David > -Dmitry > > >> >> Long version ... read below :) >> >> Thanks, >> David >> >> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>> Hi Everybody, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>> >>> The fix explicitly checks for UsePerfData and if it's false make >>> Perf:detach a NOP. >> >> That sidesteps the assertion failure but there is a bigger semantic >> issue here I think - which is why the bug has remained open for so long. >> UsePerfData can disable a part of the backend of the "perf" >> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >> oblivious to that. It isn't even really clear what UsePerfData pertains >> to. It impacts PerfMemory turning a number of methods into no-ops - but >> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >> What is a no-op is the initialization of PerfMemory (perfMemory_init) >> during VM startup, and also the teardown (perfMemory_exit) during VM >> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >> flag (in part) by not initializing the PerfMemory subsystem, but the >> PerfMemory public apis are still enabled and invoked from the JDK code. >> That doesn't make sense to me - we should fail to attach and in doing so >> not put in place the Cleaner code that will attempt the detach. But >> sun.misc.Perf doesn't understand that anything can fail. :( >> >> Your workaround avoids calling PerfMemory::detach from the Perf_detach >> code by checking UsePerfData, but arguably the check should be inside >> PerfMemory::detach operation (which unfortunately is OS specific). >> >>> >>> -Dmitry >>> > > From ivan.gerasimov at oracle.com Fri Jan 16 07:26:27 2015 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 16 Jan 2015 10:26:27 +0300 Subject: RFR 8069048: (process) Suspend finishing threads when process exits [win] In-Reply-To: <54B854C4.1010907@oracle.com> References: <54B7ADEB.3000506@oracle.com> <54B854C4.1010907@oracle.com> Message-ID: <54B8BD23.7060804@oracle.com> Thank you Daniel for your review! On 16.01.2015 3:01, Daniel D. Daugherty wrote: > On 1/15/15 5:09 AM, Ivan Gerasimov wrote: >> Hello everyone! >> >> This is yet another iteration in the attempt to solve the 'wrong exit >> code' bug on Windows [1]. >> The wrong exit code has been observed once again with one of the >> regression tests. >> >> The suspicion is that this might be due to the critical section had >> been destroyed before all the children threads were terminated. >> In that case, one of the threads had been unblocked and called >> _endthreadex(), which resulted in a race. >> >> To address this scenario, it is proposed to make the thread that is >> about to exit the process raise a flag. >> If the flag is raised, any threads wishing to exit should instead >> suspend themselves. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8069048 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8069048/0/webrev/ > > src/os/windows/vm/os_windows.cpp > line 3895: // don't let the current thread to proceed to > _endthreadex() > Typo: 'let the current thread to proceed to' > -> 'let the current thread proceed to' > > Just making sure that I understand the revised algorithm: > > - before the EPT_PROCESS thread gets here, EPT_THREAD threads > will work as before and call line 3909 _endthreadex() > > - after the EPT_PROCESS thread gets here and sets the flag > on line 3886: OrderAccess::release_store(&process_exiting, 1); > > - an EPT_THREAD thread may have made it past flag check on line > 3802: } else if (OrderAccess::load_acquire(&process_exiting) > == 0) { > but it will be blocked on line 3803: > EnterCriticalSection(&crit_sect); > > - an EPT_THREAD thread that sees the flag set on line 3802 will > drop into the self-suspend block on lines 3892-3900 > > - after the EPT_PROCESS thread exits the critical section, then > any EPT_THREAD threads that were blocked trying to acquire > the critical section will now see the flag set on line 3805: > if (what == EPT_THREAD && > OrderAccess::load_acquire(&process_exiting) == 0) { > and drop into the self-suspend block on lines 3892-3900 > > Short version: any EPT_THREAD threads that arrive after the > EPT_PROCESS thread owns the critical section will never call > line 3909 _endthreadex() because they self-suspend. > Yes, the logic is meant to be precisely as you're describing. > OK, I concur that this new algorithm looks correct and will reduce > the number of threads racing through line 3909 _endthreadex() while > the EPT_PROCESS thread is trying to call exit(). > > One possible hole remains that we've discussed before. If an > EPT_THREAD thread calls _endthreadex() before the EPT_PROCESS > thread gets here, and if the EPT_THREAD thread stalls in > _endthreadex(), then it's still possible for that EPT_THREAD > thread to mess up the exit code if it unblocks after the > EPT_PROCESS thread has set the exit code. > The EPT_PROCESS thread is waiting for those EPT_THREAD threads that had called _endthreadex() at 3874 res = WaitForMultipleObjects(handle_count, handles, TRUE, EXIT_TIMEOUT). This can timeout , of course, so yes, the window for a race is still open. > We've discussed this > before and there's nothing we can do about other than try and > reduce the probability by reducing the number of EPT_THREAD > threads that are calling _endthreadex(). > > Thumbs up! > > > Side note: A new failure of this mechanism was filed recently: > > JDK-8069068 VM warning: WaitForMultipleObjects timed out (0) ... > https://bugs.openjdk.java.net/browse/JDK-8069068 > > The bug was filed against JDK9-B45 so it has the most recent > fix (https://bugs.openjdk.java.net/browse/JDK-8066863). The > weird part is that WaitForMultipleObjects() timed out without > an error code being set. Don't know if that means anything in > particular in the Win* APIS... > > This fix (8069048) may also reduce the probability of this > failure mode because we'll be queueing fewer threads on the > handle list... > Right. If this failure had happened during the app termination, the new logic might have helped. It still looks surprising though, as the warning indicates that none of 64 threads that have already called _endthreadex() could not complete execution during 4 second! And one of those threads had the priority above normal. Very strange. I need to try to reproduce this kind of failure locally. Sincerely yours, Ivan From mattis.castegren at oracle.com Fri Jan 16 10:17:40 2015 From: mattis.castegren at oracle.com (Mattis Castegren) Date: Fri, 16 Jan 2015 02:17:40 -0800 (PST) Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54B7CC2B.4070702@oracle.com> References: <54B7CC2B.4070702@oracle.com> Message-ID: Hi This bug is targeted for 7u80, with rdp2 next Tuesday. It would be great to get a review for this fix as soon as possible, so that we can get this fix out in the last public JDK 7 release. Kind Regards /Mattis -----Original Message----- From: Kevin Walls Sent: den 15 januari 2015 15:18 To: serviceability-dev at openjdk.java.net Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool Hi, This is a review request for a change in JVMTI, where we os::free() some objects where we should delete them. The problem was logged against 7, though it exists up to the present day, below is a diff in current latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot Testing: I've used a native JVMTI agent to call GetConstantPool() during an object allocation callback. Memory usage does appear less after the change, it can be 5-6MB in a trivial testcase with a small number of allocations monitored, each inoking GetConstantlPool(). (In my test agent the GetConstantPool() call returns a JVMTI error 101 after a fairly short time and a relatively small number of allocations are monitored.) If this is OK to submit without testcase that's great. I don't see other examples of native agents in the standard hotspot tests. bug https://bugs.openjdk.java.net/browse/JDK-8035938 diff: $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp @@ -68,11 +68,11 @@ ~JvmtiConstantPoolReconstituter() { if (_symmap != NULL) { - os::free(_symmap); + delete _symmap; _symmap = NULL; } if (_classmap != NULL) { - os::free(_classmap); + delete _classmap; _classmap = NULL; } } Thanks Kevin From dmitry.samersoff at oracle.com Fri Jan 16 14:59:39 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 16 Jan 2015 17:59:39 +0300 Subject: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData In-Reply-To: <54B8B151.3080705@oracle.com> References: <54B3D101.4090309@oracle.com> <54B4A8D2.70700@oracle.com> <54B4DEC9.60209@oracle.com> <54B8B151.3080705@oracle.com> Message-ID: <54B9275B.8060306@oracle.com> David, Thank you! -Dmitry On 2015-01-16 09:36, David Holmes wrote: > On 13/01/2015 7:00 PM, Dmitry Samersoff wrote: >> David, >> >> On 2015-01-13 08:10, David Holmes wrote: >>> >>> Short version: okay but I'm going to file a bug to have sun.misc.Perf >>> fixed properly. >> >> Thank you and please, file a new bug (you can assign it to me directly). > > Filed: > > https://bugs.openjdk.java.net/browse/JDK-8069149 > > Sorry for the delay. > > David > >> -Dmitry >> >> >>> >>> Long version ... read below :) >>> >>> Thanks, >>> David >>> >>> On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >>>> Hi Everybody, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >>>> >>>> The fix explicitly checks for UsePerfData and if it's false make >>>> Perf:detach a NOP.? ?? ?????-?? ??? ???????????? ???? >>> >>> That sidesteps the assertion failure but there is a bigger semantic >>> issue here I think - which is why the bug has remained open for so long. >>> UsePerfData can disable a part of the backend of the "perf" >>> functionality used via sun.misc.Perf, but sun.misc.Perf is completely >>> oblivious to that. It isn't even really clear what UsePerfData pertains >>> to. It impacts PerfMemory turning a number of methods into no-ops - but >>> it doesn't turn PerfMemory::attach nor PerfMemory::detach into no-ops. >>> What is a no-op is the initialization of PerfMemory (perfMemory_init) >>> during VM startup, and also the teardown (perfMemory_exit) during VM >>> shutdown (via at_exit handler). So the VM responds to the -UsePerfData >>> flag (in part) by not initializing the PerfMemory subsystem, but the >>> PerfMemory public apis are still enabled and invoked from the JDK code. >>> That doesn't make sense to me - we should fail to attach and in doing so >>> not put in place the Cleaner code that will attempt the detach. But >>> sun.misc.Perf doesn't understand that anything can fail. :( >>> >>> Your workaround avoids calling PerfMemory::detach from the Perf_detach >>> code by checking UsePerfData, but arguably the check should be inside >>> PerfMemory::detach operation (which unfortunately is OS specific). >>> >>>> >>>> -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 serguei.spitsyn at oracle.com Fri Jan 16 17:29:30 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 09:29:30 -0800 Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: References: <54B7CC2B.4070702@oracle.com> Message-ID: <54B94A7A.7080605@oracle.com> The fix looks good. Thanks, Serguei On 1/16/15 2:17 AM, Mattis Castegren wrote: > Hi > > This bug is targeted for 7u80, with rdp2 next Tuesday. It would be great to get a review for this fix as soon as possible, so that we can get this fix out in the last public JDK 7 release. > > Kind Regards > /Mattis > > -----Original Message----- > From: Kevin Walls > Sent: den 15 januari 2015 15:18 > To: serviceability-dev at openjdk.java.net > Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > > Hi, > > This is a review request for a change in JVMTI, where we os::free() some > objects where we should delete them. The problem was logged against 7, > though it exists up to the present day, below is a diff in current > latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot > > > Testing: > I've used a native JVMTI agent to call GetConstantPool() during an > object allocation callback. Memory usage does appear less after the > change, it can be 5-6MB in a trivial testcase with a small number of > allocations monitored, each inoking GetConstantlPool(). > > (In my test agent the GetConstantPool() call returns a JVMTI error 101 > after a fairly short time and a relatively small number of allocations > are monitored.) > > If this is OK to submit without testcase that's great. I don't see > other examples of native agents in the standard hotspot tests. > > bug > https://bugs.openjdk.java.net/browse/JDK-8035938 > > diff: > $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp > diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > @@ -68,11 +68,11 @@ > > ~JvmtiConstantPoolReconstituter() { > if (_symmap != NULL) { > - os::free(_symmap); > + delete _symmap; > _symmap = NULL; > } > if (_classmap != NULL) { > - os::free(_classmap); > + delete _classmap; > _classmap = NULL; > } > } > > > > Thanks > Kevin > From daniel.daugherty at oracle.com Fri Jan 16 17:51:05 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 16 Jan 2015 10:51:05 -0700 Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: References: <54B7CC2B.4070702@oracle.com> Message-ID: <54B94F89.2070907@oracle.com> > src/share/vm/prims/jvmtiClassFileReconstituter.hpp These lines allocate: line 59: _symmap = new SymbolHashMap(); line 60: _classmap = new SymbolHashMap(); and these lines free incorrectly: line 71: os::free(_symmap); line 75: os::free(_classmap); so the proposed fix looks good! Dan On 1/16/15 3:17 AM, Mattis Castegren wrote: > Hi > > This bug is targeted for 7u80, with rdp2 next Tuesday. It would be great to get a review for this fix as soon as possible, so that we can get this fix out in the last public JDK 7 release. > > Kind Regards > /Mattis > > -----Original Message----- > From: Kevin Walls > Sent: den 15 januari 2015 15:18 > To: serviceability-dev at openjdk.java.net > Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > > Hi, > > This is a review request for a change in JVMTI, where we os::free() some > objects where we should delete them. The problem was logged against 7, > though it exists up to the present day, below is a diff in current > latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot > > > Testing: > I've used a native JVMTI agent to call GetConstantPool() during an > object allocation callback. Memory usage does appear less after the > change, it can be 5-6MB in a trivial testcase with a small number of > allocations monitored, each inoking GetConstantlPool(). > > (In my test agent the GetConstantPool() call returns a JVMTI error 101 > after a fairly short time and a relatively small number of allocations > are monitored.) > > If this is OK to submit without testcase that's great. I don't see > other examples of native agents in the standard hotspot tests. > > bug > https://bugs.openjdk.java.net/browse/JDK-8035938 > > diff: > $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp > diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > @@ -68,11 +68,11 @@ > > ~JvmtiConstantPoolReconstituter() { > if (_symmap != NULL) { > - os::free(_symmap); > + delete _symmap; > _symmap = NULL; > } > if (_classmap != NULL) { > - os::free(_classmap); > + delete _classmap; > _classmap = NULL; > } > } > > > > Thanks > Kevin > > > From kevin.walls at oracle.com Fri Jan 16 18:28:50 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 16 Jan 2015 18:28:50 +0000 Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54B94F89.2070907@oracle.com> References: <54B7CC2B.4070702@oracle.com> <54B94F89.2070907@oracle.com> Message-ID: <54B95862.4020305@oracle.com> Thanks Serguei, thanks Dan! On 16/01/2015 17:51, Daniel D. Daugherty wrote: > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > > These lines allocate: > > line 59: _symmap = new SymbolHashMap(); > line 60: _classmap = new SymbolHashMap(); > > and these lines free incorrectly: > > line 71: os::free(_symmap); > line 75: os::free(_classmap); > > so the proposed fix looks good! > > > Dan > > > On 1/16/15 3:17 AM, Mattis Castegren wrote: >> Hi >> >> This bug is targeted for 7u80, with rdp2 next Tuesday. It would be >> great to get a review for this fix as soon as possible, so that we >> can get this fix out in the last public JDK 7 release. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kevin Walls >> Sent: den 15 januari 2015 15:18 >> To: serviceability-dev at openjdk.java.net >> Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool >> >> Hi, >> >> This is a review request for a change in JVMTI, where we os::free() some >> objects where we should delete them. The problem was logged against 7, >> though it exists up to the present day, below is a diff in current >> latest http://hg.openjdk.java.net/jdk9/hs-rt/hotspot >> >> >> Testing: >> I've used a native JVMTI agent to call GetConstantPool() during an >> object allocation callback. Memory usage does appear less after the >> change, it can be 5-6MB in a trivial testcase with a small number of >> allocations monitored, each inoking GetConstantlPool(). >> >> (In my test agent the GetConstantPool() call returns a JVMTI error 101 >> after a fairly short time and a relatively small number of allocations >> are monitored.) >> >> If this is OK to submit without testcase that's great. I don't see >> other examples of native agents in the standard hotspot tests. >> >> bug >> https://bugs.openjdk.java.net/browse/JDK-8035938 >> >> diff: >> $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> @@ -68,11 +68,11 @@ >> >> ~JvmtiConstantPoolReconstituter() { >> if (_symmap != NULL) { >> - os::free(_symmap); >> + delete _symmap; >> _symmap = NULL; >> } >> if (_classmap != NULL) { >> - os::free(_classmap); >> + delete _classmap; >> _classmap = NULL; >> } >> } >> >> >> >> Thanks >> Kevin >> >> >> > From serguei.spitsyn at oracle.com Fri Jan 16 19:14:09 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 11:14:09 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B60308.4000105@oracle.com> References: <54B60308.4000105@oracle.com> Message-ID: <54B96301.40108@oracle.com> Dan, David H. or David C., May I ask one of you to look at the webrev below? The issue itself is a little bit tricky, so it is not easy to review despite the small size. Coleen, Does the webrev matches what we discussed with you? Do you give me a thumbs up? Thanks, Serguei May I ask On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8068162 > > > Open webrevs: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ > > > > Summary: > > The sun.misc.Unsafe:throwIllegalAccessError() method is used in > place of a default > interface method in the itable if a default method was not defined > in the interface. > In fact, it happens for two interfaces that purhaps are > auto-generated: > java/nio/CharBuffer > java/nio/HeapCharBuffer > > This approach creates a problem when the class sun.misc.Unsafe is > retransformed. > The Method* pointer to the old (redefined) method in the itable > triggers an assert > (see the hs_err log in the bug report). > Coleen told me that a similar approach is going to be implemented > for some vtable entries. > Coleen, thanks for suggesting a better fix for this issue! > > The fix is to replace the old Unsafe method in the itable/vtable > with the latest method version. > > > Testing: > In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests > > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Fri Jan 16 19:16:34 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 11:16:34 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B96301.40108@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> Message-ID: <54B96392.8090904@oracle.com> Sorry for the re-post. Forgot to add review candidates to the to-list. Thanks, Serguei On 1/16/15 11:14 AM, serguei.spitsyn at oracle.com wrote: > Dan, David H. or David C., > > May I ask one of you to look at the webrev below? > The issue itself is a little bit tricky, so it is not easy to review > despite the small size. > > Coleen, > > Does the webrev matches what we discussed with you? > Do you give me a thumbs up? > > Thanks, > Serguei > > May I ask > > On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8068162 >> >> >> Open webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >> >> >> >> Summary: >> >> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >> place of a default >> interface method in the itable if a default method was not defined >> in the interface. >> In fact, it happens for two interfaces that purhaps are >> auto-generated: >> java/nio/CharBuffer >> java/nio/HeapCharBuffer >> >> This approach creates a problem when the class sun.misc.Unsafe is >> retransformed. >> The Method* pointer to the old (redefined) method in the itable >> triggers an assert >> (see the hs_err log in the bug report). >> Coleen told me that a similar approach is going to be implemented >> for some vtable entries. >> Coleen, thanks for suggesting a better fix for this issue! >> >> The fix is to replace the old Unsafe method in the itable/vtable >> with the latest method version. >> >> >> Testing: >> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Fri Jan 16 20:07:51 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 12:07:51 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54934E73.4080808@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> Message-ID: <54B96F97.5070204@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8008678 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ Summary: Currently, a JVM_CONSTANT_String CP entry having a NULL reference to Symbol* indicates that it is a pseudo-string (patched string). This creates nasty issues for the constant pool reconstitution. Current suggestion is to avoid having a NULL reference and retain the original Symbol* reference for pseudo-strings. The pseudo-string indication will be if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". This approach makes the fix much simpler. I need a confirmation from the Compiler team that this won't break any assumptions or invariants. Big thanks to Coleen for previous round reviews and good advices! Testing: Run: - java/lang/instrument tests - new jtreg test (see webrev) that was written by Filipp Zhinkin Thanks, Serguei On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you for reviewing! > > > On 12/18/14 11:23 AM, Coleen Phillimore wrote: >> >> Hi Serguei, >> >> Thank you for making the patches an optional field. >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >> 198 if (!patched()) { >> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >> 200 return 0; >> 201 } >> Why not >> assert(patched(), "a pseud-string map must exist for >> patched CP only"); > > Wanted it to be more reliable but it looks pointless. > Will make this change. > >> >> >> Why is this? Is this really a ShouldNotReachHere? should it be false? >> >> 215 assert(true, "not found a matching entry in pseudo-string map"); > > > A typo, must be false. > It is the last minute change. > Thanks for the catch! > > >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >> >> Don't you have to move the value of the patched field from the old >> constant pool to the new one? I hate to ask but is there merging >> that needs to be done? I don't know how to write this test case >> though. Is it possible to redefine a class with a constant pool >> patches with another that has constant pool patches? > > Thank you for asking this question. > If I understand correctly, the patching comes from the compiler side > for anonymous classes only. > I saw it for LambdaForm's only. > I think, the patching can not be changed with a retransformation. > But I'm not sure if it can not be changed with a redefinition. > > But if it can - then it would be safe to merge the 'patched' > condition, i.e. make it patched > if either the_class or scratch class is patched. > >> >> Somehow I thought you'd have to save the value of the cp_patches oops >> passed in. >> >> So I was wondering why you can't change this instead: >> >> bool is_pseudo_string_at(int which) { >> // A pseudo string is a string that doesn't have a symbol in the >> cpSlot >> - return unresolved_string_at(which) == NULL; >> + return (strncmp(unresolved_string_at(which)->as_utf8(), >> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >> } > > I was thinking about the same but was not sure if it would work for > the compiler team. > We have to ask John about this (added John and Christian to the cc-list). > This question to John was in my plan! :) > > The beauty of the above approach is that there is no need to create an > intermediate > pseudo-string map and most of the code in from this webrev is not needed. > > > Thanks, > Serguei > >> >> And the asserts in the other functions below it. >> >> Coleen >> >> >> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the second round fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>> >>> >>> Summary: >>> >>> This fix implements a footprint saving approach suggested by Coleen. >>> To be able to reconstitute a class constant pool, an intermediate >>> pseudo-string map is used. >>> Now, this field is accounted optionally, only if the 'cp_patches' >>> is provided in the >>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>> This fix is not elegant, even a little bit ugly, but it is the >>> only way I see so far. >>> >>> Unfortunately, this approach did not help much to make some other >>> fields (eg., 'operands') optional. >>> The problem is that we have to account optional fields before >>> parsing, at the CP allocation time. >>> It is possible to re-allocate the ConstantPool when any >>> InvokeDynamic bytecode is discovered, >>> but it looks too complicated. >>> >>> Testing: >>> - the unit test from bug report >>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>> - vm.mlvm.testlist, vm.quick.testlist, >>> vm.parallel_class_loading.testlist (in progress) >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>> Coleen, >>>> >>>> Thank you for looking at this! >>>> I'll check how this can be improved. >>>> It is my concern too. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>> >>>>> Serguei, >>>>> I had a quick look at this. I was wondering if we could make the >>>>> pseudo_string_map conditional in ConstantPool and not make all >>>>> classes pay in footprint for this field? The same thing probably >>>>> could be done for operands too. There are flags that you can set >>>>> to conditionally add a pointer to base() in this function. >>>>> >>>>> Typical C++ would subclass ConstantPool to add >>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>> the trick we use is like the one in ConstMethod. I think it's >>>>> worth doing in this case. >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>> >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The pseudo-strings are currently not supported in >>>>>> reconstitution of constant pool. >>>>>> >>>>>> This is an explanation from John Rose about what the >>>>>> pseudo-strings are: >>>>>> >>>>>> "We still need "live" oop constants pre-linked into the >>>>>> constant pool of bytecodes which >>>>>> implement some method handles. We use the anonymous class >>>>>> pseudo-string feature for that. >>>>>> The relevant code is here: >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>> >>>>>> These oops are what "pseudo-strings" are. >>>>>> The odd name refers to the fact that, even though they are >>>>>> random oops, they appear in the constant pool >>>>>> where one would expect (because of class file syntax) to find >>>>>> a string." >>>>>> ... >>>>>> If you really wanted to reconstitute a class file for an >>>>>> anonymous class, and >>>>>> if that class has oop patching (pseudo-strings), you would >>>>>> need either to (a) reconstitute the patches array >>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept whatever >>>>>> odd strings were there first, as an approximation. >>>>>> The "odd strings" are totally insignificant, and are >>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>> >>>>>> >>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>> >>>>>> The problem is that a pseudo-string is a patched string that >>>>>> does not have >>>>>> a reference to the string symbol anymore: >>>>>> unresolved_string_at(idx) == NULL >>>>>> >>>>>> The fix is to create and fill in a map from >>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>> to be able to restore this assotiation in the >>>>>> JvmtiConstantPoolReconstituter. >>>>>> >>>>>> Testing: >>>>>> Run: >>>>>> - java/lang/instrument tests >>>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 16 22:38:33 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 14:38:33 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B96392.8090904@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B96392.8090904@oracle.com> Message-ID: <54B992E9.4090904@oracle.com> Just wanted to tell that Dan is the second reviewer, so there is no pressure on others to review this. :) Thanks, Dan! Serguei On 1/16/15 11:16 AM, serguei.spitsyn at oracle.com wrote: > Sorry for the re-post. > Forgot to add review candidates to the to-list. > > Thanks, > Serguei > > On 1/16/15 11:14 AM, serguei.spitsyn at oracle.com wrote: >> Dan, David H. or David C., >> >> May I ask one of you to look at the webrev below? >> The issue itself is a little bit tricky, so it is not easy to review >> despite the small size. >> >> Coleen, >> >> Does the webrev matches what we discussed with you? >> Do you give me a thumbs up? >> >> Thanks, >> Serguei >> >> May I ask >> >> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>> >>> >>> Open webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>> >>> >>> >>> Summary: >>> >>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>> place of a default >>> interface method in the itable if a default method was not >>> defined in the interface. >>> In fact, it happens for two interfaces that purhaps are >>> auto-generated: >>> java/nio/CharBuffer >>> java/nio/HeapCharBuffer >>> >>> This approach creates a problem when the class sun.misc.Unsafe is >>> retransformed. >>> The Method* pointer to the old (redefined) method in the itable >>> triggers an assert >>> (see the hs_err log in the bug report). >>> Coleen told me that a similar approach is going to be implemented >>> for some vtable entries. >>> Coleen, thanks for suggesting a better fix for this issue! >>> >>> The fix is to replace the old Unsafe method in the itable/vtable >>> with the latest method version. >>> >>> >>> Testing: >>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From coleen.phillimore at oracle.com Fri Jan 16 22:50:17 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Jan 2015 17:50:17 -0500 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B992E9.4090904@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B96392.8090904@oracle.com> <54B992E9.4090904@oracle.com> Message-ID: <54B995A9.9030506@oracle.com> Hi Serguei, Sorry this got lost in my mailbox, twice. This change looks great! Thank you for re-enabling the test. Thanks, Coleen On 1/16/15, 5:38 PM, serguei.spitsyn at oracle.com wrote: > Just wanted to tell that Dan is the second reviewer, > so there is no pressure on others to review this. :) > > Thanks, Dan! > Serguei > > On 1/16/15 11:16 AM, serguei.spitsyn at oracle.com wrote: >> Sorry for the re-post. >> Forgot to add review candidates to the to-list. >> >> Thanks, >> Serguei >> >> On 1/16/15 11:14 AM, serguei.spitsyn at oracle.com wrote: >>> Dan, David H. or David C., >>> >>> May I ask one of you to look at the webrev below? >>> The issue itself is a little bit tricky, so it is not easy to review >>> despite the small size. >>> >>> Coleen, >>> >>> Does the webrev matches what we discussed with you? >>> Do you give me a thumbs up? >>> >>> Thanks, >>> Serguei >>> >>> May I ask >>> >>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>> >>>> >>>> Open webrevs: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>> place of a default >>>> interface method in the itable if a default method was not >>>> defined in the interface. >>>> In fact, it happens for two interfaces that purhaps are >>>> auto-generated: >>>> java/nio/CharBuffer >>>> java/nio/HeapCharBuffer >>>> >>>> This approach creates a problem when the class sun.misc.Unsafe >>>> is retransformed. >>>> The Method* pointer to the old (redefined) method in the itable >>>> triggers an assert >>>> (see the hs_err log in the bug report). >>>> Coleen told me that a similar approach is going to be >>>> implemented for some vtable entries. >>>> Coleen, thanks for suggesting a better fix for this issue! >>>> >>>> The fix is to replace the old Unsafe method in the itable/vtable >>>> with the latest method version. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From coleen.phillimore at oracle.com Fri Jan 16 22:53:54 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Jan 2015 17:53:54 -0500 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B96F97.5070204@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> Message-ID: <54B99682.8070802@oracle.com> This change looks good to me also. Thanks, Coleen On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8008678 > > > Open webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ > > > Summary: > Currently, a JVM_CONSTANT_String CP entry having a NULL reference > to Symbol* > indicates that it is a pseudo-string (patched string). > This creates nasty issues for the constant pool reconstitution. > > Current suggestion is to avoid having a NULL reference and retain > the original > Symbol* reference for pseudo-strings. The pseudo-string indication > will be > if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". > This approach makes the fix much simpler. > > I need a confirmation from the Compiler team that this won't break > any assumptions or invariants. > Big thanks to Coleen for previous round reviews and good advices! > > > Testing: > Run: > - java/lang/instrument tests > - new jtreg test (see webrev) that was written by Filipp Zhinkin > > > Thanks, > Serguei > > > On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you for reviewing! >> >> >> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>> >>> Hi Serguei, >>> >>> Thank you for making the patches an optional field. >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>> 198 if (!patched()) { >>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>> 200 return 0; >>> 201 } >>> Why not >>> assert(patched(), "a pseud-string map must exist for >>> patched CP only"); >> >> Wanted it to be more reliable but it looks pointless. >> Will make this change. >> >>> >>> >>> Why is this? Is this really a ShouldNotReachHere? should it be false? >>> >>> 215 assert(true, "not found a matching entry in pseudo-string map"); >> >> >> A typo, must be false. >> It is the last minute change. >> Thanks for the catch! >> >> >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>> >>> Don't you have to move the value of the patched field from the old >>> constant pool to the new one? I hate to ask but is there merging >>> that needs to be done? I don't know how to write this test case >>> though. Is it possible to redefine a class with a constant pool >>> patches with another that has constant pool patches? >> >> Thank you for asking this question. >> If I understand correctly, the patching comes from the compiler side >> for anonymous classes only. >> I saw it for LambdaForm's only. >> I think, the patching can not be changed with a retransformation. >> But I'm not sure if it can not be changed with a redefinition. >> >> But if it can - then it would be safe to merge the 'patched' >> condition, i.e. make it patched >> if either the_class or scratch class is patched. >> >>> >>> Somehow I thought you'd have to save the value of the cp_patches >>> oops passed in. >>> >>> So I was wondering why you can't change this instead: >>> >>> bool is_pseudo_string_at(int which) { >>> // A pseudo string is a string that doesn't have a symbol in the >>> cpSlot >>> - return unresolved_string_at(which) == NULL; >>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>> } >> >> I was thinking about the same but was not sure if it would work for >> the compiler team. >> We have to ask John about this (added John and Christian to the cc-list). >> This question to John was in my plan! :) >> >> The beauty of the above approach is that there is no need to create >> an intermediate >> pseudo-string map and most of the code in from this webrev is not needed. >> >> >> Thanks, >> Serguei >> >>> >>> And the asserts in the other functions below it. >>> >>> Coleen >>> >>> >>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the second round fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>> >>>> >>>> Summary: >>>> >>>> This fix implements a footprint saving approach suggested by Coleen. >>>> To be able to reconstitute a class constant pool, an intermediate >>>> pseudo-string map is used. >>>> Now, this field is accounted optionally, only if the 'cp_patches' >>>> is provided in the >>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>> This fix is not elegant, even a little bit ugly, but it is the >>>> only way I see so far. >>>> >>>> Unfortunately, this approach did not help much to make some other >>>> fields (eg., 'operands') optional. >>>> The problem is that we have to account optional fields before >>>> parsing, at the CP allocation time. >>>> It is possible to re-allocate the ConstantPool when any >>>> InvokeDynamic bytecode is discovered, >>>> but it looks too complicated. >>>> >>>> Testing: >>>> - the unit test from bug report >>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>> - vm.mlvm.testlist, vm.quick.testlist, >>>> vm.parallel_class_loading.testlist (in progress) >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>> Coleen, >>>>> >>>>> Thank you for looking at this! >>>>> I'll check how this can be improved. >>>>> It is my concern too. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Serguei, >>>>>> I had a quick look at this. I was wondering if we could make the >>>>>> pseudo_string_map conditional in ConstantPool and not make all >>>>>> classes pay in footprint for this field? The same thing probably >>>>>> could be done for operands too. There are flags that you can set >>>>>> to conditionally add a pointer to base() in this function. >>>>>> >>>>>> Typical C++ would subclass ConstantPool to add >>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>>> the trick we use is like the one in ConstMethod. I think it's >>>>>> worth doing in this case. >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>> >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> The pseudo-strings are currently not supported in >>>>>>> reconstitution of constant pool. >>>>>>> >>>>>>> This is an explanation from John Rose about what the >>>>>>> pseudo-strings are: >>>>>>> >>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>> constant pool of bytecodes which >>>>>>> implement some method handles. We use the anonymous class >>>>>>> pseudo-string feature for that. >>>>>>> The relevant code is here: >>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>> >>>>>>> These oops are what "pseudo-strings" are. >>>>>>> The odd name refers to the fact that, even though they are >>>>>>> random oops, they appear in the constant pool >>>>>>> where one would expect (because of class file syntax) to >>>>>>> find a string." >>>>>>> ... >>>>>>> If you really wanted to reconstitute a class file for an >>>>>>> anonymous class, and >>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>> need either to (a) reconstitute the patches array >>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>> whatever odd strings were there first, as an approximation. >>>>>>> The "odd strings" are totally insignificant, and are >>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>> >>>>>>> >>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>> >>>>>>> The problem is that a pseudo-string is a patched string that >>>>>>> does not have >>>>>>> a reference to the string symbol anymore: >>>>>>> unresolved_string_at(idx) == NULL >>>>>>> >>>>>>> The fix is to create and fill in a map from >>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>> to be able to restore this assotiation in the >>>>>>> JvmtiConstantPoolReconstituter. >>>>>>> >>>>>>> Testing: >>>>>>> Run: >>>>>>> - java/lang/instrument tests >>>>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 16 22:57:23 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 14:57:23 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B995A9.9030506@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B96392.8090904@oracle.com> <54B992E9.4090904@oracle.com> <54B995A9.9030506@oracle.com> Message-ID: <54B99753.2070506@oracle.com> Thanks, Coleen! Serguei On 1/16/15 2:50 PM, Coleen Phillimore wrote: > > Hi Serguei, > > Sorry this got lost in my mailbox, twice. This change looks great! > Thank you for re-enabling the test. > > Thanks, > Coleen > > On 1/16/15, 5:38 PM, serguei.spitsyn at oracle.com wrote: >> Just wanted to tell that Dan is the second reviewer, >> so there is no pressure on others to review this. :) >> >> Thanks, Dan! >> Serguei >> >> On 1/16/15 11:16 AM, serguei.spitsyn at oracle.com wrote: >>> Sorry for the re-post. >>> Forgot to add review candidates to the to-list. >>> >>> Thanks, >>> Serguei >>> >>> On 1/16/15 11:14 AM, serguei.spitsyn at oracle.com wrote: >>>> Dan, David H. or David C., >>>> >>>> May I ask one of you to look at the webrev below? >>>> The issue itself is a little bit tricky, so it is not easy to >>>> review despite the small size. >>>> >>>> Coleen, >>>> >>>> Does the webrev matches what we discussed with you? >>>> Do you give me a thumbs up? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> May I ask >>>> >>>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>>> >>>>> >>>>> Open webrevs: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>>> place of a default >>>>> interface method in the itable if a default method was not >>>>> defined in the interface. >>>>> In fact, it happens for two interfaces that purhaps are >>>>> auto-generated: >>>>> java/nio/CharBuffer >>>>> java/nio/HeapCharBuffer >>>>> >>>>> This approach creates a problem when the class sun.misc.Unsafe >>>>> is retransformed. >>>>> The Method* pointer to the old (redefined) method in the itable >>>>> triggers an assert >>>>> (see the hs_err log in the bug report). >>>>> Coleen told me that a similar approach is going to be >>>>> implemented for some vtable entries. >>>>> Coleen, thanks for suggesting a better fix for this issue! >>>>> >>>>> The fix is to replace the old Unsafe method in the >>>>> itable/vtable with the latest method version. >>>>> >>>>> >>>>> Testing: >>>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Fri Jan 16 23:01:12 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 15:01:12 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B99682.8070802@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> Message-ID: <54B99838.10601@oracle.com> John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. The updated webrev is going to be close to the .3 webrev. I will send it soon. Thanks, Serguei On 1/16/15 2:53 PM, Coleen Phillimore wrote: > > This change looks good to me also. > Thanks, > Coleen > > On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8008678 >> >> >> Open webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >> >> >> Summary: >> Currently, a JVM_CONSTANT_String CP entry having a NULL reference >> to Symbol* >> indicates that it is a pseudo-string (patched string). >> This creates nasty issues for the constant pool reconstitution. >> >> Current suggestion is to avoid having a NULL reference and retain >> the original >> Symbol* reference for pseudo-strings. The pseudo-string indication >> will be >> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >> This approach makes the fix much simpler. >> >> I need a confirmation from the Compiler team that this won't break >> any assumptions or invariants. >> Big thanks to Coleen for previous round reviews and good advices! >> >> >> Testing: >> Run: >> - java/lang/instrument tests >> - new jtreg test (see webrev) that was written by Filipp Zhinkin >> >> >> Thanks, >> Serguei >> >> >> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Thank you for reviewing! >>> >>> >>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>> >>>> Hi Serguei, >>>> >>>> Thank you for making the patches an optional field. >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>> 198 if (!patched()) { >>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>> 200 return 0; >>>> 201 } >>>> Why not >>>> assert(patched(), "a pseud-string map must exist >>>> for patched CP only"); >>> >>> Wanted it to be more reliable but it looks pointless. >>> Will make this change. >>> >>>> >>>> >>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>> false? >>>> >>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>> >>> >>> A typo, must be false. >>> It is the last minute change. >>> Thanks for the catch! >>> >>> >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>> >>>> Don't you have to move the value of the patched field from the old >>>> constant pool to the new one? I hate to ask but is there merging >>>> that needs to be done? I don't know how to write this test case >>>> though. Is it possible to redefine a class with a constant pool >>>> patches with another that has constant pool patches? >>> >>> Thank you for asking this question. >>> If I understand correctly, the patching comes from the compiler side >>> for anonymous classes only. >>> I saw it for LambdaForm's only. >>> I think, the patching can not be changed with a retransformation. >>> But I'm not sure if it can not be changed with a redefinition. >>> >>> But if it can - then it would be safe to merge the 'patched' >>> condition, i.e. make it patched >>> if either the_class or scratch class is patched. >>> >>>> >>>> Somehow I thought you'd have to save the value of the cp_patches >>>> oops passed in. >>>> >>>> So I was wondering why you can't change this instead: >>>> >>>> bool is_pseudo_string_at(int which) { >>>> // A pseudo string is a string that doesn't have a symbol in >>>> the cpSlot >>>> - return unresolved_string_at(which) == NULL; >>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>> } >>> >>> I was thinking about the same but was not sure if it would work for >>> the compiler team. >>> We have to ask John about this (added John and Christian to the >>> cc-list). >>> This question to John was in my plan! :) >>> >>> The beauty of the above approach is that there is no need to create >>> an intermediate >>> pseudo-string map and most of the code in from this webrev is not >>> needed. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> And the asserts in the other functions below it. >>>> >>>> Coleen >>>> >>>> >>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the second round fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>> >>>>> >>>>> Summary: >>>>> >>>>> This fix implements a footprint saving approach suggested by Coleen. >>>>> To be able to reconstitute a class constant pool, an >>>>> intermediate pseudo-string map is used. >>>>> Now, this field is accounted optionally, only if the >>>>> 'cp_patches' is provided in the >>>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>> only way I see so far. >>>>> >>>>> Unfortunately, this approach did not help much to make some >>>>> other fields (eg., 'operands') optional. >>>>> The problem is that we have to account optional fields before >>>>> parsing, at the CP allocation time. >>>>> It is possible to re-allocate the ConstantPool when any >>>>> InvokeDynamic bytecode is discovered, >>>>> but it looks too complicated. >>>>> >>>>> Testing: >>>>> - the unit test from bug report >>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>> vm.parallel_class_loading.testlist (in progress) >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Coleen, >>>>>> >>>>>> Thank you for looking at this! >>>>>> I'll check how this can be improved. >>>>>> It is my concern too. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Serguei, >>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>> all classes pay in footprint for this field? The same thing >>>>>>> probably could be done for operands too. There are flags that >>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>> function. >>>>>>> >>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ so >>>>>>> the trick we use is like the one in ConstMethod. I think it's >>>>>>> worth doing in this case. >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>> >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> The pseudo-strings are currently not supported in >>>>>>>> reconstitution of constant pool. >>>>>>>> >>>>>>>> This is an explanation from John Rose about what the >>>>>>>> pseudo-strings are: >>>>>>>> >>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>> constant pool of bytecodes which >>>>>>>> implement some method handles. We use the anonymous class >>>>>>>> pseudo-string feature for that. >>>>>>>> The relevant code is here: >>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>> >>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>> The odd name refers to the fact that, even though they are >>>>>>>> random oops, they appear in the constant pool >>>>>>>> where one would expect (because of class file syntax) to >>>>>>>> find a string." >>>>>>>> ... >>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>> anonymous class, and >>>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>>> need either to (a) reconstitute the patches array >>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>> >>>>>>>> >>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>> >>>>>>>> The problem is that a pseudo-string is a patched string that >>>>>>>> does not have >>>>>>>> a reference to the string symbol anymore: >>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>> >>>>>>>> The fix is to create and fill in a map from >>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>> to be able to restore this assotiation in the >>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>> >>>>>>>> Testing: >>>>>>>> Run: >>>>>>>> - java/lang/instrument tests >>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>> Zhinkin >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Jan 16 23:03:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Jan 2015 18:03:51 -0500 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B99838.10601@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> Message-ID: <54B998D7.1020208@oracle.com> On 1/16/15, 6:01 PM, serguei.spitsyn at oracle.com wrote: > John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. I was sort of wondering about this along the same lines. You're setting the second bit, right? :) Coleen > The updated webrev is going to be close to the .3 webrev. > I will send it soon. > > Thanks, > Serguei > > On 1/16/15 2:53 PM, Coleen Phillimore wrote: >> >> This change looks good to me also. >> Thanks, >> Coleen >> >> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>> >>> >>> Summary: >>> Currently, a JVM_CONSTANT_String CP entry having a NULL reference >>> to Symbol* >>> indicates that it is a pseudo-string (patched string). >>> This creates nasty issues for the constant pool reconstitution. >>> >>> Current suggestion is to avoid having a NULL reference and retain >>> the original >>> Symbol* reference for pseudo-strings. The pseudo-string >>> indication will be >>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>> This approach makes the fix much simpler. >>> >>> I need a confirmation from the Compiler team that this won't >>> break any assumptions or invariants. >>> Big thanks to Coleen for previous round reviews and good advices! >>> >>> >>> Testing: >>> Run: >>> - java/lang/instrument tests >>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> Thank you for reviewing! >>>> >>>> >>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Thank you for making the patches an optional field. >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>> 198 if (!patched()) { >>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>> 200 return 0; >>>>> 201 } >>>>> Why not >>>>> assert(patched(), "a pseud-string map must exist >>>>> for patched CP only"); >>>> >>>> Wanted it to be more reliable but it looks pointless. >>>> Will make this change. >>>> >>>>> >>>>> >>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>> false? >>>>> >>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>> >>>> >>>> A typo, must be false. >>>> It is the last minute change. >>>> Thanks for the catch! >>>> >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>> >>>>> Don't you have to move the value of the patched field from the old >>>>> constant pool to the new one? I hate to ask but is there merging >>>>> that needs to be done? I don't know how to write this test case >>>>> though. Is it possible to redefine a class with a constant pool >>>>> patches with another that has constant pool patches? >>>> >>>> Thank you for asking this question. >>>> If I understand correctly, the patching comes from the compiler >>>> side for anonymous classes only. >>>> I saw it for LambdaForm's only. >>>> I think, the patching can not be changed with a retransformation. >>>> But I'm not sure if it can not be changed with a redefinition. >>>> >>>> But if it can - then it would be safe to merge the 'patched' >>>> condition, i.e. make it patched >>>> if either the_class or scratch class is patched. >>>> >>>>> >>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>> oops passed in. >>>>> >>>>> So I was wondering why you can't change this instead: >>>>> >>>>> bool is_pseudo_string_at(int which) { >>>>> // A pseudo string is a string that doesn't have a symbol in >>>>> the cpSlot >>>>> - return unresolved_string_at(which) == NULL; >>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>> } >>>> >>>> I was thinking about the same but was not sure if it would work for >>>> the compiler team. >>>> We have to ask John about this (added John and Christian to the >>>> cc-list). >>>> This question to John was in my plan! :) >>>> >>>> The beauty of the above approach is that there is no need to create >>>> an intermediate >>>> pseudo-string map and most of the code in from this webrev is not >>>> needed. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> And the asserts in the other functions below it. >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the second round fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This fix implements a footprint saving approach suggested by >>>>>> Coleen. >>>>>> To be able to reconstitute a class constant pool, an >>>>>> intermediate pseudo-string map is used. >>>>>> Now, this field is accounted optionally, only if the >>>>>> 'cp_patches' is provided in the >>>>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>>> only way I see so far. >>>>>> >>>>>> Unfortunately, this approach did not help much to make some >>>>>> other fields (eg., 'operands') optional. >>>>>> The problem is that we have to account optional fields before >>>>>> parsing, at the CP allocation time. >>>>>> It is possible to re-allocate the ConstantPool when any >>>>>> InvokeDynamic bytecode is discovered, >>>>>> but it looks too complicated. >>>>>> >>>>>> Testing: >>>>>> - the unit test from bug report >>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Thank you for looking at this! >>>>>>> I'll check how this can be improved. >>>>>>> It is my concern too. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Serguei, >>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>>> all classes pay in footprint for this field? The same thing >>>>>>>> probably could be done for operands too. There are flags that >>>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>>> function. >>>>>>>> >>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>> it's worth doing in this case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>> reconstitution of constant pool. >>>>>>>>> >>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>> pseudo-strings are: >>>>>>>>> >>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>> constant pool of bytecodes which >>>>>>>>> implement some method handles. We use the anonymous class >>>>>>>>> pseudo-string feature for that. >>>>>>>>> The relevant code is here: >>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>> >>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>> The odd name refers to the fact that, even though they are >>>>>>>>> random oops, they appear in the constant pool >>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>> find a string." >>>>>>>>> ... >>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>> anonymous class, and >>>>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>>>> need either to (a) reconstitute the patches array >>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>> >>>>>>>>> >>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>> >>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>> that does not have >>>>>>>>> a reference to the string symbol anymore: >>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>> >>>>>>>>> The fix is to create and fill in a map from >>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>> to be able to restore this assotiation in the >>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run: >>>>>>>>> - java/lang/instrument tests >>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>> Zhinkin >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 16 23:10:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 15:10:13 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B998D7.1020208@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54B998D7.1020208@oracle.com> Message-ID: <54B99A55.6000002@oracle.com> On 1/16/15 3:03 PM, Coleen Phillimore wrote: > > On 1/16/15, 6:01 PM, serguei.spitsyn at oracle.com wrote: >> John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. > > I was sort of wondering about this along the same lines. You're > setting the second bit, right? :) I'm not sure yet. I'll check if setting the first bit would not create an ambiguity. Otherwise, will set the second one. Thanks, Serguei > Coleen > >> The updated webrev is going to be close to the .3 webrev. >> I will send it soon. >> >> Thanks, >> Serguei >> >> On 1/16/15 2:53 PM, Coleen Phillimore wrote: >>> >>> This change looks good to me also. >>> Thanks, >>> Coleen >>> >>> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>>> >>>> >>>> Summary: >>>> Currently, a JVM_CONSTANT_String CP entry having a NULL >>>> reference to Symbol* >>>> indicates that it is a pseudo-string (patched string). >>>> This creates nasty issues for the constant pool reconstitution. >>>> >>>> Current suggestion is to avoid having a NULL reference and >>>> retain the original >>>> Symbol* reference for pseudo-strings. The pseudo-string >>>> indication will be >>>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>>> This approach makes the fix much simpler. >>>> >>>> I need a confirmation from the Compiler team that this won't >>>> break any assumptions or invariants. >>>> Big thanks to Coleen for previous round reviews and good advices! >>>> >>>> >>>> Testing: >>>> Run: >>>> - java/lang/instrument tests >>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen, >>>>> >>>>> Thank you for reviewing! >>>>> >>>>> >>>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for making the patches an optional field. >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>>> 198 if (!patched()) { >>>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>>> 200 return 0; >>>>>> 201 } >>>>>> Why not >>>>>> assert(patched(), "a pseud-string map must exist >>>>>> for patched CP only"); >>>>> >>>>> Wanted it to be more reliable but it looks pointless. >>>>> Will make this change. >>>>> >>>>>> >>>>>> >>>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>>> false? >>>>>> >>>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>>> >>>>> >>>>> A typo, must be false. >>>>> It is the last minute change. >>>>> Thanks for the catch! >>>>> >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>>> >>>>>> Don't you have to move the value of the patched field from the >>>>>> old constant pool to the new one? I hate to ask but is there >>>>>> merging that needs to be done? I don't know how to write this >>>>>> test case though. Is it possible to redefine a class with a >>>>>> constant pool patches with another that has constant pool patches? >>>>> >>>>> Thank you for asking this question. >>>>> If I understand correctly, the patching comes from the compiler >>>>> side for anonymous classes only. >>>>> I saw it for LambdaForm's only. >>>>> I think, the patching can not be changed with a retransformation. >>>>> But I'm not sure if it can not be changed with a redefinition. >>>>> >>>>> But if it can - then it would be safe to merge the 'patched' >>>>> condition, i.e. make it patched >>>>> if either the_class or scratch class is patched. >>>>> >>>>>> >>>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>>> oops passed in. >>>>>> >>>>>> So I was wondering why you can't change this instead: >>>>>> >>>>>> bool is_pseudo_string_at(int which) { >>>>>> // A pseudo string is a string that doesn't have a symbol in >>>>>> the cpSlot >>>>>> - return unresolved_string_at(which) == NULL; >>>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>>> } >>>>> >>>>> I was thinking about the same but was not sure if it would work >>>>> for the compiler team. >>>>> We have to ask John about this (added John and Christian to the >>>>> cc-list). >>>>> This question to John was in my plan! :) >>>>> >>>>> The beauty of the above approach is that there is no need to >>>>> create an intermediate >>>>> pseudo-string map and most of the code in from this webrev is not >>>>> needed. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> And the asserts in the other functions below it. >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the second round fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This fix implements a footprint saving approach suggested by >>>>>>> Coleen. >>>>>>> To be able to reconstitute a class constant pool, an >>>>>>> intermediate pseudo-string map is used. >>>>>>> Now, this field is accounted optionally, only if the >>>>>>> 'cp_patches' is provided in the >>>>>>> ClassFileParser::parseClassFile() before ConstantPool is >>>>>>> allocated. >>>>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>>>> only way I see so far. >>>>>>> >>>>>>> Unfortunately, this approach did not help much to make some >>>>>>> other fields (eg., 'operands') optional. >>>>>>> The problem is that we have to account optional fields before >>>>>>> parsing, at the CP allocation time. >>>>>>> It is possible to re-allocate the ConstantPool when any >>>>>>> InvokeDynamic bytecode is discovered, >>>>>>> but it looks too complicated. >>>>>>> >>>>>>> Testing: >>>>>>> - the unit test from bug report >>>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Thank you for looking at this! >>>>>>>> I'll check how this can be improved. >>>>>>>> It is my concern too. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> Serguei, >>>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>>>> all classes pay in footprint for this field? The same thing >>>>>>>>> probably could be done for operands too. There are flags that >>>>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>>>> function. >>>>>>>>> >>>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>>> it's worth doing in this case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>>> reconstitution of constant pool. >>>>>>>>>> >>>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>>> pseudo-strings are: >>>>>>>>>> >>>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>>> constant pool of bytecodes which >>>>>>>>>> implement some method handles. We use the anonymous class >>>>>>>>>> pseudo-string feature for that. >>>>>>>>>> The relevant code is here: >>>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>>> >>>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>>> The odd name refers to the fact that, even though they >>>>>>>>>> are random oops, they appear in the constant pool >>>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>>> find a string." >>>>>>>>>> ... >>>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>>> anonymous class, and >>>>>>>>>> if that class has oop patching (pseudo-strings), you >>>>>>>>>> would need either to (a) reconstitute the patches array >>>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>>> >>>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>>> that does not have >>>>>>>>>> a reference to the string symbol anymore: >>>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>>> >>>>>>>>>> The fix is to create and fill in a map from >>>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>>> to be able to restore this assotiation in the >>>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run: >>>>>>>>>> - java/lang/instrument tests >>>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>>> Zhinkin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri Jan 16 23:32:33 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 16 Jan 2015 15:32:33 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B998D7.1020208@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54B998D7.1020208@oracle.com> Message-ID: <82E12F9C-BE5E-4B66-B477-9F90956ECD6D@oracle.com> On Jan 16, 2015, at 3:03 PM, Coleen Phillimore wrote: > > I was sort of wondering about this along the same lines. You're setting the second bit, right? :) That sounds good, much better than the string prefix hack. Parsing the string would introduce too much coupling between the JVM and random details of the JDK. I also suggested to Serguei that redefinition of patched classes is not going to happen, since they are not user-visible. So all of the "EMCP" logic can punt on pseudo-strings, one way or another, if it needs to. BTW, since patched classes are always anonymous classes, you can't even get to them, unless you dig them out some private place like a lambda form. Reconstitution is also a lost cause, since the patches will be dropped, but I see how that might be something you might possibly run into, as a stress test or some sort of debugger display. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 16 23:35:19 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 15:35:19 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B99A55.6000002@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54B998D7.1020208@oracle.com> <54B99A55.6000002@oracle.com> Message-ID: <54B9A037.6040007@oracle.com> On 1/16/15 3:10 PM, serguei.spitsyn at oracle.com wrote: > On 1/16/15 3:03 PM, Coleen Phillimore wrote: >> >> On 1/16/15, 6:01 PM, serguei.spitsyn at oracle.com wrote: >>> John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. >> >> I was sort of wondering about this along the same lines. You're >> setting the second bit, right? :) > > I'm not sure yet. > I'll check if setting the first bit would not create an ambiguity. > Otherwise, will set the second one. In fact, the suggestion was to look at the PCSlot as an example. I'm not sure this class is good to extend or reuse for pseudo-strings as it was added for klass entries only. > > Thanks, > Serguei > >> Coleen >> >>> The updated webrev is going to be close to the .3 webrev. >>> I will send it soon. >>> >>> Thanks, >>> Serguei >>> >>> On 1/16/15 2:53 PM, Coleen Phillimore wrote: >>>> >>>> This change looks good to me also. >>>> Thanks, >>>> Coleen >>>> >>>> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>>>> >>>>> >>>>> Summary: >>>>> Currently, a JVM_CONSTANT_String CP entry having a NULL >>>>> reference to Symbol* >>>>> indicates that it is a pseudo-string (patched string). >>>>> This creates nasty issues for the constant pool reconstitution. >>>>> >>>>> Current suggestion is to avoid having a NULL reference and >>>>> retain the original >>>>> Symbol* reference for pseudo-strings. The pseudo-string >>>>> indication will be >>>>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>>>> This approach makes the fix much simpler. >>>>> >>>>> I need a confirmation from the Compiler team that this won't >>>>> break any assumptions or invariants. >>>>> Big thanks to Coleen for previous round reviews and good advices! >>>>> >>>>> >>>>> Testing: >>>>> Run: >>>>> - java/lang/instrument tests >>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Thank you for reviewing! >>>>>> >>>>>> >>>>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Thank you for making the patches an optional field. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>>>> 198 if (!patched()) { >>>>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>>>> 200 return 0; >>>>>>> 201 } >>>>>>> Why not >>>>>>> assert(patched(), "a pseud-string map must exist >>>>>>> for patched CP only"); >>>>>> >>>>>> Wanted it to be more reliable but it looks pointless. >>>>>> Will make this change. >>>>>> >>>>>>> >>>>>>> >>>>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>>>> false? >>>>>>> >>>>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>>>> >>>>>> >>>>>> A typo, must be false. >>>>>> It is the last minute change. >>>>>> Thanks for the catch! >>>>>> >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>>>> >>>>>>> Don't you have to move the value of the patched field from the >>>>>>> old constant pool to the new one? I hate to ask but is there >>>>>>> merging that needs to be done? I don't know how to write this >>>>>>> test case though. Is it possible to redefine a class with a >>>>>>> constant pool patches with another that has constant pool patches? >>>>>> >>>>>> Thank you for asking this question. >>>>>> If I understand correctly, the patching comes from the compiler >>>>>> side for anonymous classes only. >>>>>> I saw it for LambdaForm's only. >>>>>> I think, the patching can not be changed with a retransformation. >>>>>> But I'm not sure if it can not be changed with a redefinition. >>>>>> >>>>>> But if it can - then it would be safe to merge the 'patched' >>>>>> condition, i.e. make it patched >>>>>> if either the_class or scratch class is patched. >>>>>> >>>>>>> >>>>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>>>> oops passed in. >>>>>>> >>>>>>> So I was wondering why you can't change this instead: >>>>>>> >>>>>>> bool is_pseudo_string_at(int which) { >>>>>>> // A pseudo string is a string that doesn't have a symbol in >>>>>>> the cpSlot >>>>>>> - return unresolved_string_at(which) == NULL; >>>>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>>>> } >>>>>> >>>>>> I was thinking about the same but was not sure if it would work >>>>>> for the compiler team. >>>>>> We have to ask John about this (added John and Christian to the >>>>>> cc-list). >>>>>> This question to John was in my plan! :) >>>>>> >>>>>> The beauty of the above approach is that there is no need to >>>>>> create an intermediate >>>>>> pseudo-string map and most of the code in from this webrev is not >>>>>> needed. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> And the asserts in the other functions below it. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the second round fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> This fix implements a footprint saving approach suggested by >>>>>>>> Coleen. >>>>>>>> To be able to reconstitute a class constant pool, an >>>>>>>> intermediate pseudo-string map is used. >>>>>>>> Now, this field is accounted optionally, only if the >>>>>>>> 'cp_patches' is provided in the >>>>>>>> ClassFileParser::parseClassFile() before ConstantPool is >>>>>>>> allocated. >>>>>>>> This fix is not elegant, even a little bit ugly, but it is >>>>>>>> the only way I see so far. >>>>>>>> >>>>>>>> Unfortunately, this approach did not help much to make some >>>>>>>> other fields (eg., 'operands') optional. >>>>>>>> The problem is that we have to account optional fields before >>>>>>>> parsing, at the CP allocation time. >>>>>>>> It is possible to re-allocate the ConstantPool when any >>>>>>>> InvokeDynamic bytecode is discovered, >>>>>>>> but it looks too complicated. >>>>>>>> >>>>>>>> Testing: >>>>>>>> - the unit test from bug report >>>>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG >>>>>>>> java/lang/instrument >>>>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Coleen, >>>>>>>>> >>>>>>>>> Thank you for looking at this! >>>>>>>>> I'll check how this can be improved. >>>>>>>>> It is my concern too. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> Serguei, >>>>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>>>> the pseudo_string_map conditional in ConstantPool and not >>>>>>>>>> make all classes pay in footprint for this field? The same >>>>>>>>>> thing probably could be done for operands too. There are >>>>>>>>>> flags that you can set to conditionally add a pointer to >>>>>>>>>> base() in this function. >>>>>>>>>> >>>>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>>>> it's worth doing in this case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the fix for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Open webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>>>> reconstitution of constant pool. >>>>>>>>>>> >>>>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>>>> pseudo-strings are: >>>>>>>>>>> >>>>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>>>> constant pool of bytecodes which >>>>>>>>>>> implement some method handles. We use the anonymous >>>>>>>>>>> class pseudo-string feature for that. >>>>>>>>>>> The relevant code is here: >>>>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>>>> >>>>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>>>> The odd name refers to the fact that, even though they >>>>>>>>>>> are random oops, they appear in the constant pool >>>>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>>>> find a string." >>>>>>>>>>> ... >>>>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>>>> anonymous class, and >>>>>>>>>>> if that class has oop patching (pseudo-strings), you >>>>>>>>>>> would need either to (a) reconstitute the patches array >>>>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>>>> >>>>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>>>> that does not have >>>>>>>>>>> a reference to the string symbol anymore: >>>>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>>>> >>>>>>>>>>> The fix is to create and fill in a map from >>>>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>>>> to be able to restore this assotiation in the >>>>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> Run: >>>>>>>>>>> - java/lang/instrument tests >>>>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>>>> Zhinkin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Jan 17 01:15:10 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 16 Jan 2015 17:15:10 -0800 Subject: 3-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <82E12F9C-BE5E-4B66-B477-9F90956ECD6D@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54B998D7.1020208@oracle.com> <82E12F9C-BE5E-4B66-B477-9F90956ECD6D@oracle.com> Message-ID: <54B9B79E.3060600@oracle.com> On 1/16/15 3:32 PM, John Rose wrote: > On Jan 16, 2015, at 3:03 PM, Coleen Phillimore > > > wrote: >> >> I was sort of wondering about this along the same lines. You're >> setting the second bit, right? :) > > That sounds good, much better than the string prefix hack. > > Parsing the string would introduce too much coupling between the JVM > and random details of the JDK. > > I also suggested to Serguei that redefinition of patched classes is > not going to happen, since they are not user-visible. So all of the > "EMCP" logic can punt on pseudo-strings, one way or another, if it > needs to. > > BTW, since patched classes are always anonymous classes, you can't > even get to them, unless you dig them out some private place like a > lambda form. Anonymous classes can be noticed by agents with the CL or CFLH events. Then nothing stops agents from redefining or re-transforming anonymous classes. > > Reconstitution is also a lost cause, since the patches will be > dropped, but I see how that might be something you might possibly run > into, as a stress test or some sort of debugger display. I've filed a new bug to track this issue as we early agreed with Coleen: https://bugs.openjdk.java.net/browse/JDK-8069233 Fill free to update it if necessary. Thanks, Serguei > > ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Sat Jan 17 02:24:11 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 16 Jan 2015 19:24:11 -0700 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B96301.40108@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> Message-ID: <54B9C7CB.60103@oracle.com> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ src/share/vm/memory/universe.hpp No comments. src/share/vm/memory/universe.cpp No comments. src/share/vm/prims/jvmtiRedefineClasses.cpp So redefining the Unsafe class is now very expensive because we have to visit the i-table and v-table of every class (and maybe interface?)... Based on the bug report 'Unsafe::throw_illegal_access' is some magical method that can appear in any i-table or v-table entry. Maybe only as part of some default methods thing? That's not clear to me so I'm just guessing... Is there some way to limit this visit to classes where the magical method can appear? Or can it really appear anywhere? Dan On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: > Dan, David H. or David C., > > May I ask one of you to look at the webrev below? > The issue itself is a little bit tricky, so it is not easy to review > despite the small size. > > Coleen, > > Does the webrev matches what we discussed with you? > Do you give me a thumbs up? > > Thanks, > Serguei > > May I ask > > On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8068162 >> >> >> Open webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >> >> >> >> Summary: >> >> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >> place of a default >> interface method in the itable if a default method was not defined >> in the interface. >> In fact, it happens for two interfaces that purhaps are >> auto-generated: >> java/nio/CharBuffer >> java/nio/HeapCharBuffer >> >> This approach creates a problem when the class sun.misc.Unsafe is >> retransformed. >> The Method* pointer to the old (redefined) method in the itable >> triggers an assert >> (see the hs_err log in the bug report). >> Coleen told me that a similar approach is going to be implemented >> for some vtable entries. >> Coleen, thanks for suggesting a better fix for this issue! >> >> The fix is to replace the old Unsafe method in the itable/vtable >> with the latest method version. >> >> >> Testing: >> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >> >> >> Thanks, >> Serguei >> > From david.holmes at oracle.com Mon Jan 19 05:47:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Jan 2015 15:47:42 +1000 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B9C7CB.60103@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> Message-ID: <54BC9A7E.5070607@oracle.com> On 17/01/2015 12:24 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ > > > src/share/vm/memory/universe.hpp > No comments. > > src/share/vm/memory/universe.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > So redefining the Unsafe class is now very expensive because > we have to visit the i-table and v-table of every class (and > maybe interface?)... Sorry I didn't follow this through all the rounds, but the bug report states (and the code I looked at seems to be consistent with it) that the throw_IllegalAccessError call is only added to itables - so why are we also walking vtables? David H. ----- > Based on the bug report 'Unsafe::throw_illegal_access' is some > magical method that can appear in any i-table or v-table entry. > Maybe only as part of some default methods thing? That's not > clear to me so I'm just guessing... > > Is there some way to limit this visit to classes where the > magical method can appear? Or can it really appear anywhere? > > Dan > > > On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >> Dan, David H. or David C., >> >> May I ask one of you to look at the webrev below? >> The issue itself is a little bit tricky, so it is not easy to review >> despite the small size. >> >> Coleen, >> >> Does the webrev matches what we discussed with you? >> Do you give me a thumbs up? >> >> Thanks, >> Serguei >> >> May I ask >> >> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>> >>> >>> Open webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>> > >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>> >>> >>> >>> Summary: >>> >>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>> place of a default >>> interface method in the itable if a default method was not defined >>> in the interface. >>> In fact, it happens for two interfaces that purhaps are >>> auto-generated: >>> java/nio/CharBuffer >>> java/nio/HeapCharBuffer >>> >>> This approach creates a problem when the class sun.misc.Unsafe is >>> retransformed. >>> The Method* pointer to the old (redefined) method in the itable >>> triggers an assert >>> (see the hs_err log in the bug report). >>> Coleen told me that a similar approach is going to be implemented >>> for some vtable entries. >>> Coleen, thanks for suggesting a better fix for this issue! >>> >>> The fix is to replace the old Unsafe method in the itable/vtable >>> with the latest method version. >>> >>> >>> Testing: >>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From erik.joelsson at oracle.com Mon Jan 19 08:29:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 19 Jan 2015 09:29:57 +0100 Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build In-Reply-To: <54B33555.8030206@oracle.com> References: <54AFE70C.3070208@oracle.com> <54B33555.8030206@oracle.com> Message-ID: <54BCC085.50406@oracle.com> Hello, Any chance someone from serviceability could take a look at this? /Erik On 2015-01-12 03:45, David Holmes wrote: > Hi Erik, > > On 10/01/2015 12:34 AM, Erik Joelsson wrote: >> Hello, >> >> Please review this patch which fixes the verify-modules target when >> running bootcycle build, and also reenables verify-modules when running >> "make images". >> >> There were two problems: >> >> * The bootcycle build configuration was broken so that both the normal >> and the bootcycle build used the same HOTSPOT_DIST directory. The >> consequence of this was that verify-modules worked when run on its own, >> but not if bootcycle-images had been run before. This is fixed in >> bootcycle-spec.gmk.in. >> >> * Since javac in JDK 9 no longer emits classes for implicitly compiled >> sources, certain classes in sa-jdi.jar were not compiled during the >> bootcycle build. I fixed this by adding the missing classes to sa.files. >> Not having the classes there might have been intentional (in at least >> some cases), but since they were compiled anyway, I felt it safer to >> just add them to the list to fix this issue. If these classes shouldn't >> be included, then they need to be properly removed in a followup fix. > > SA is owned by serviceability - cc'd. Changes seem okay as a solution > to immediate problem, but I don't think anyone expects the IA64 stuff > to still be needed. It is on the todo list to eradicate IA64 IIRC. > > Looks like there is limited awareness of the need to keep sa.files up > to date. :( > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479 >> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/ >> >> Since this is changing hotspot, I assume it will need to go in through a >> hotspot forest. Which one? >> >> /Erik From staffan.larsen at oracle.com Mon Jan 19 09:05:26 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 19 Jan 2015 10:05:26 +0100 Subject: RFR: JDK-8067479: verify-modules fails in bootcycle build In-Reply-To: <54BCC085.50406@oracle.com> References: <54AFE70C.3070208@oracle.com> <54B33555.8030206@oracle.com> <54BCC085.50406@oracle.com> Message-ID: <3A3C541D-E976-44EC-A2DC-B663D0049A4F@oracle.com> SA changes look ok - the IA64 stuff isn?t needed as we don?t support it and will remove it. /Staffan > On 19 jan 2015, at 09:29, Erik Joelsson wrote: > > Hello, > > Any chance someone from serviceability could take a look at this? > > /Erik > > On 2015-01-12 03:45, David Holmes wrote: >> Hi Erik, >> >> On 10/01/2015 12:34 AM, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this patch which fixes the verify-modules target when >>> running bootcycle build, and also reenables verify-modules when running >>> "make images". >>> >>> There were two problems: >>> >>> * The bootcycle build configuration was broken so that both the normal >>> and the bootcycle build used the same HOTSPOT_DIST directory. The >>> consequence of this was that verify-modules worked when run on its own, >>> but not if bootcycle-images had been run before. This is fixed in >>> bootcycle-spec.gmk.in. >>> >>> * Since javac in JDK 9 no longer emits classes for implicitly compiled >>> sources, certain classes in sa-jdi.jar were not compiled during the >>> bootcycle build. I fixed this by adding the missing classes to sa.files. >>> Not having the classes there might have been intentional (in at least >>> some cases), but since they were compiled anyway, I felt it safer to >>> just add them to the list to fix this issue. If these classes shouldn't >>> be included, then they need to be properly removed in a followup fix. >> >> SA is owned by serviceability - cc'd. Changes seem okay as a solution to immediate problem, but I don't think anyone expects the IA64 stuff to still be needed. It is on the todo list to eradicate IA64 IIRC. >> >> Looks like there is limited awareness of the need to keep sa.files up to date. :( >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067479 >>> Webrev: http://cr.openjdk.java.net/~erikj/8067479/webrev.01/ >>> >>> Since this is changing hotspot, I assume it will need to go in through a >>> hotspot forest. Which one? >>> >>> /Erik > From mattias.tobiasson at oracle.com Mon Jan 19 13:24:42 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Mon, 19 Jan 2015 14:24:42 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root Message-ID: <54BD059A.9000604@oracle.com> Hi, Could I please have a review of this test bug fix. Test expects some files to be unreadable. That does not work when running as root. The fix is to ignore the parts for unreadable files when running as root. bug: https://bugs.openjdk.java.net/browse/JDK-8044419 webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 Tested as non-root on all platforms except embedded. Tested as root on linux. Thanks, Mattias From dmitry.samersoff at oracle.com Mon Jan 19 15:13:30 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 19 Jan 2015 18:13:30 +0300 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54BD059A.9000604@oracle.com> References: <54BD059A.9000604@oracle.com> Message-ID: <54BD1F1A.9080400@oracle.com> Mattias, After chmod a-r grep will display unpleasant permission denied error for non root user so it's better just do: if id | grep -q 'uid=0(' then Do root staff else Do non-root staff fi -Dmitry On 2015-01-19 16:24, Mattias Tobiasson wrote: > Hi, > Could I please have a review of this test bug fix. > > Test expects some files to be unreadable. That does not work when > running as root. > The fix is to ignore the parts for unreadable files when running as root. > > bug: https://bugs.openjdk.java.net/browse/JDK-8044419 > webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 > > Tested as non-root on all platforms except embedded. > Tested as root on linux. > > Thanks, > Mattias > -- 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 Jan 19 15:55:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 19 Jan 2015 10:55:35 -0500 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54B9C7CB.60103@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> Message-ID: <54BD28F7.7040905@oracle.com> On 1/16/15, 9:24 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ > > src/share/vm/memory/universe.hpp > No comments. > > src/share/vm/memory/universe.cpp > No comments. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > So redefining the Unsafe class is now very expensive because > we have to visit the i-table and v-table of every class (and > maybe interface?)... > > Based on the bug report 'Unsafe::throw_illegal_access' is some > magical method that can appear in any i-table or v-table entry. > Maybe only as part of some default methods thing? That's not > clear to me so I'm just guessing... True. > > Is there some way to limit this visit to classes where the > magical method can appear? Or can it really appear anywhere? The Unsafe methods can appear in any itable now. I don't know of a way to limit this. Fortunately, redefining Unsafe seems to be an unusual thing to do, except for this stress test. Coleen > > Dan > > > On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >> Dan, David H. or David C., >> >> May I ask one of you to look at the webrev below? >> The issue itself is a little bit tricky, so it is not easy to review >> despite the small size. >> >> Coleen, >> >> Does the webrev matches what we discussed with you? >> Do you give me a thumbs up? >> >> Thanks, >> Serguei >> >> May I ask >> >> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>> >>> >>> Open webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>> > >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>> >>> >>> >>> Summary: >>> >>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>> place of a default >>> interface method in the itable if a default method was not >>> defined in the interface. >>> In fact, it happens for two interfaces that purhaps are >>> auto-generated: >>> java/nio/CharBuffer >>> java/nio/HeapCharBuffer >>> >>> This approach creates a problem when the class sun.misc.Unsafe is >>> retransformed. >>> The Method* pointer to the old (redefined) method in the itable >>> triggers an assert >>> (see the hs_err log in the bug report). >>> Coleen told me that a similar approach is going to be implemented >>> for some vtable entries. >>> Coleen, thanks for suggesting a better fix for this issue! >>> >>> The fix is to replace the old Unsafe method in the itable/vtable >>> with the latest method version. >>> >>> >>> Testing: >>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From alexander.kulyakhtin at oracle.com Mon Jan 19 16:00:04 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Mon, 19 Jan 2015 08:00:04 -0800 (PST) Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) Message-ID: Hi, Could you, please, review the fix below. To adress the previous review findings any referenes to "test.jdk" have been removed. bug: https://bugs.openjdk.java.net/browse/JDK-8067945 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ References to tools.jar are removed from the tests as jdk9 drops tools.jar Thanks, Alex From serguei.spitsyn at oracle.com Mon Jan 19 17:22:34 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 19 Jan 2015 09:22:34 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54BD28F7.7040905@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> <54BD28F7.7040905@oracle.com> Message-ID: <54BD3D5A.1030903@oracle.com> Coleen, Thank you for answering questions below! Thanks, Serguei On 1/19/15 7:55 AM, Coleen Phillimore wrote: > > On 1/16/15, 9:24 PM, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >> >> src/share/vm/memory/universe.hpp >> No comments. >> >> src/share/vm/memory/universe.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> So redefining the Unsafe class is now very expensive because >> we have to visit the i-table and v-table of every class (and >> maybe interface?)... >> >> Based on the bug report 'Unsafe::throw_illegal_access' is some >> magical method that can appear in any i-table or v-table entry. >> Maybe only as part of some default methods thing? That's not >> clear to me so I'm just guessing... > > True. >> >> Is there some way to limit this visit to classes where the >> magical method can appear? Or can it really appear anywhere? > > The Unsafe methods can appear in any itable now. I don't know of a > way to limit this. Fortunately, redefining Unsafe seems to be an > unusual thing to do, except for this stress test. > > Coleen > >> >> Dan >> >> >> On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, David H. or David C., >>> >>> May I ask one of you to look at the webrev below? >>> The issue itself is a little bit tricky, so it is not easy to review >>> despite the small size. >>> >>> Coleen, >>> >>> Does the webrev matches what we discussed with you? >>> Do you give me a thumbs up? >>> >>> Thanks, >>> Serguei >>> >>> May I ask >>> >>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>> >>>> >>>> Open webrevs: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>> >> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>> place of a default >>>> interface method in the itable if a default method was not >>>> defined in the interface. >>>> In fact, it happens for two interfaces that purhaps are >>>> auto-generated: >>>> java/nio/CharBuffer >>>> java/nio/HeapCharBuffer >>>> >>>> This approach creates a problem when the class sun.misc.Unsafe >>>> is retransformed. >>>> The Method* pointer to the old (redefined) method in the itable >>>> triggers an assert >>>> (see the hs_err log in the bug report). >>>> Coleen told me that a similar approach is going to be >>>> implemented for some vtable entries. >>>> Coleen, thanks for suggesting a better fix for this issue! >>>> >>>> The fix is to replace the old Unsafe method in the itable/vtable >>>> with the latest method version. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From serguei.spitsyn at oracle.com Mon Jan 19 17:26:24 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 19 Jan 2015 09:26:24 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54BC9A7E.5070607@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> <54BC9A7E.5070607@oracle.com> Message-ID: <54BD3E40.5030400@oracle.com> On 1/18/15 9:47 PM, David Holmes wrote: > On 17/01/2015 12:24 PM, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >> >> >> >> src/share/vm/memory/universe.hpp >> No comments. >> >> src/share/vm/memory/universe.cpp >> No comments. >> >> src/share/vm/prims/jvmtiRedefineClasses.cpp >> So redefining the Unsafe class is now very expensive because >> we have to visit the i-table and v-table of every class (and >> maybe interface?)... > > Sorry I didn't follow this through all the rounds, but the bug report > states (and the code I looked at seems to be consistent with it) that > the throw_IllegalAccessError call is only added to itables - so why > are we also walking vtables? The Runtime team is going to extend use of the throw_IllegalAccessError for vtables as well. Thank you for looking at the fix! Serguei > > David H. > ----- > >> Based on the bug report 'Unsafe::throw_illegal_access' is some >> magical method that can appear in any i-table or v-table entry. >> Maybe only as part of some default methods thing? That's not >> clear to me so I'm just guessing... >> >> Is there some way to limit this visit to classes where the >> magical method can appear? Or can it really appear anywhere? >> >> Dan >> >> >> On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >>> Dan, David H. or David C., >>> >>> May I ask one of you to look at the webrev below? >>> The issue itself is a little bit tricky, so it is not easy to review >>> despite the small size. >>> >>> Coleen, >>> >>> Does the webrev matches what we discussed with you? >>> Do you give me a thumbs up? >>> >>> Thanks, >>> Serguei >>> >>> May I ask >>> >>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>> >>>> >>>> Open webrevs: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>> >>>> >> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>> >>>> >>>> >>>> >>>> Summary: >>>> >>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>> place of a default >>>> interface method in the itable if a default method was not defined >>>> in the interface. >>>> In fact, it happens for two interfaces that purhaps are >>>> auto-generated: >>>> java/nio/CharBuffer >>>> java/nio/HeapCharBuffer >>>> >>>> This approach creates a problem when the class sun.misc.Unsafe is >>>> retransformed. >>>> The Method* pointer to the old (redefined) method in the itable >>>> triggers an assert >>>> (see the hs_err log in the bug report). >>>> Coleen told me that a similar approach is going to be implemented >>>> for some vtable entries. >>>> Coleen, thanks for suggesting a better fix for this issue! >>>> >>>> The fix is to replace the old Unsafe method in the itable/vtable >>>> with the latest method version. >>>> >>>> >>>> Testing: >>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> From mattias.tobiasson at oracle.com Tue Jan 20 11:25:34 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Tue, 20 Jan 2015 12:25:34 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54BD1F1A.9080400@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> Message-ID: <54BE3B2E.1090603@oracle.com> Thanks for the suggestion. Your suggestion is a better way to check if the user is root. But if we only use that check, then we do not verify that the file is really unreadable. I do not know if there are any other conditions, besides running as root, that can fail to make a file unreadable. I think it feels safer to really try to read the unreadable file. Then we will get the error message. I could add a log that says the error message is expected. And I can change the second "grep" to your suggestion. Mattias On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: > Mattias, > > After chmod a-r grep will display unpleasant > permission denied error for non root user > > so it's better just do: > > if id | grep -q 'uid=0(' > then > Do root staff > else > Do non-root staff > fi > > -Dmitry > > On 2015-01-19 16:24, Mattias Tobiasson wrote: >> Hi, >> Could I please have a review of this test bug fix. >> >> Test expects some files to be unreadable. That does not work when >> running as root. >> The fix is to ignore the parts for unreadable files when running as root. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >> >> Tested as non-root on all platforms except embedded. >> Tested as root on linux. >> >> Thanks, >> Mattias >> > From daniel.daugherty at oracle.com Tue Jan 20 20:25:29 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 20 Jan 2015 13:25:29 -0700 Subject: Serviceability Agent support in JDK9 In-Reply-To: <54BEA7E0.9040603@redhat.com> References: <54BEA7E0.9040603@redhat.com> Message-ID: <54BEB9B9.20409@oracle.com> Adding the Serviceability team since SA belongs to them... Dan On 1/20/15 12:09 PM, Andrew Haley wrote: > I'm having trouble with compiler replay data in JDK 9: > > $ ./build/linux-aarch64-normal-server-slowdebug/jdk/bin/java -Xbootclasspath/p:boot.jar -cp app.jar -XX:ReplayDataFile=replay.foo -XX:+ReplayCompiles > Error occurred during initialization of VM > java/lang/ClassFormatError: Missing BootstrapMethods attribute in class file java/lang/CharSequence > > I guess this is because sun.jvm.hotspot.tools.jcore.ClassWriter doesn't > handle the BootstrapMethods attribute. Is that right? It would be nice > to have this working. > > Andrew. From yekaterina.kantserova at oracle.com Wed Jan 21 09:12:29 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 21 Jan 2015 10:12:29 +0100 Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) In-Reply-To: References: Message-ID: <54BF6D7D.7070208@oracle.com> Hi Alex, Comments bellow should be removed. You don't need to make a webrev for it, only the changes are included in the final patch. test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java 39 // create files from given arguments and tools.jar test/com/sun/tools/attach/BasicTests.java 81 // Need to add jdk/lib/tools.jar to classpath. Best regards, Katja (not a reviewer) On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the fix below. > > To adress the previous review findings any referenes to "test.jdk" have been removed. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067945 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ > > References to tools.jar are removed from the tests as jdk9 drops tools.jar > > Thanks, > Alex From mattias.tobiasson at oracle.com Wed Jan 21 10:05:58 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 21 Jan 2015 11:05:58 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54BE3B2E.1090603@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> Message-ID: <54BF7A06.7020408@oracle.com> Hi, Changes in this version: 1. Replaced the unnecessary grep from unreadable file with "id | grep ..." 2. Log that "permission denied" error message is expected. webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ bug: https://bugs.openjdk.java.net/browse/JDK-8044419 Thanks, Mattias On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: > Thanks for the suggestion. Your suggestion is a better way to check if > the user is root. > But if we only use that check, then we do not verify that the file is > really unreadable. > > I do not know if there are any other conditions, besides running as > root, that can fail to make a file unreadable. > I think it feels safer to really try to read the unreadable file. Then > we will get the error message. > > I could add a log that says the error message is expected. > And I can change the second "grep" to your suggestion. > > Mattias > > On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >> Mattias, >> >> After chmod a-r grep will display unpleasant >> permission denied error for non root user >> >> so it's better just do: >> >> if id | grep -q 'uid=0(' >> then >> Do root staff >> else >> Do non-root staff >> fi >> >> -Dmitry >> >> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>> Hi, >>> Could I please have a review of this test bug fix. >>> >>> Test expects some files to be unreadable. That does not work when >>> running as root. >>> The fix is to ignore the parts for unreadable files when running as >>> root. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>> >>> Tested as non-root on all platforms except embedded. >>> Tested as root on linux. >>> >>> Thanks, >>> Mattias >>> >> > From alexander.kulyakhtin at oracle.com Wed Jan 21 10:23:53 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 21 Jan 2015 02:23:53 -0800 (PST) Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) Message-ID: Hi Katia, Please, find attached the jdk.patch containing the changes per your findings. The patch has been made by running the webrev tool. Best regards, Alex ----- Original Message ----- From: yekaterina.kantserova at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Sent: Wednesday, January 21, 2015 12:11:58 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) Hi Alex, Comments bellow should be removed. You don't need to make a webrev for it, only the changes are included in the final patch. test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java 39 // create files from given arguments and tools.jar test/com/sun/tools/attach/BasicTests.java 81 // Need to add jdk/lib/tools.jar to classpath. Best regards, Katja (not a reviewer) On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the fix below. > > To adress the previous review findings any referenes to "test.jdk" have been removed. > > bug: https://bugs.openjdk.java.net/browse/JDK-8067945 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ > > References to tools.jar are removed from the tests as jdk9 drops tools.jar > > Thanks, > Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.patch Type: text/x-patch Size: 8600 bytes Desc: not available URL: From dmitry.samersoff at oracle.com Wed Jan 21 11:56:18 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 21 Jan 2015 14:56:18 +0300 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54BF7A06.7020408@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> <54BF7A06.7020408@oracle.com> Message-ID: <54BF93E2.40401@oracle.com> Mattias, 1. mkFiles at ll. 215 above is reluctant 2. if you wish to store id output and grep the file it's better to do something like: id > $HOME/jdb.ini chmod a-r $HOME/jdb.ini grep -q 'uid=0(' $HOME/jdb.ini 2> /dev/null case $? in 0) echo "Can't make file unreadable running as root" ;; 1) echo "Can't make file unreadable for some other reason" ;; 2) if [ -f $HOME/jdb.ini ] then echo "OK. the file is unreadable" else echo "Can't create a file" fi ;; esac -Dmitry On 2015-01-21 13:05, Mattias Tobiasson wrote: > Hi, > Changes in this version: > 1. Replaced the unnecessary grep from unreadable file with "id | grep ..." > 2. Log that "permission denied" error message is expected. > > webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ > bug: https://bugs.openjdk.java.net/browse/JDK-8044419 > > Thanks, > Mattias > > On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: >> Thanks for the suggestion. Your suggestion is a better way to check if >> the user is root. >> But if we only use that check, then we do not verify that the file is >> really unreadable. >> >> I do not know if there are any other conditions, besides running as >> root, that can fail to make a file unreadable. >> I think it feels safer to really try to read the unreadable file. Then >> we will get the error message. >> >> I could add a log that says the error message is expected. >> And I can change the second "grep" to your suggestion. >> >> Mattias >> >> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>> Mattias, >>> >>> After chmod a-r grep will display unpleasant >>> permission denied error for non root user >>> >>> so it's better just do: >>> >>> if id | grep -q 'uid=0(' >>> then >>> Do root staff >>> else >>> Do non-root staff >>> fi >>> >>> -Dmitry >>> >>> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>>> Hi, >>>> Could I please have a review of this test bug fix. >>>> >>>> Test expects some files to be unreadable. That does not work when >>>> running as root. >>>> The fix is to ignore the parts for unreadable files when running as >>>> root. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>>> >>>> Tested as non-root on all platforms except embedded. >>>> Tested as root on linux. >>>> >>>> Thanks, >>>> Mattias >>>> >>> >> > -- 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 yekaterina.kantserova at oracle.com Wed Jan 21 12:07:37 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 21 Jan 2015 13:07:37 +0100 Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) In-Reply-To: References: Message-ID: <54BF9689.9060102@oracle.com> Looks god to me (not a reviewer). // Katja On 01/21/2015 11:23 AM, Alexander Kulyakhtin wrote: > Hi Katia, > > Please, find attached the jdk.patch containing the changes per your findings. The patch has been made by running the webrev tool. > > Best regards, > Alex > > ----- Original Message ----- > From: yekaterina.kantserova at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Sent: Wednesday, January 21, 2015 12:11:58 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) > > Hi Alex, > > Comments bellow should be removed. You don't need to make a webrev for > it, only the changes are included in the final patch. > > test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java > > 39 // create files from given arguments and tools.jar > > test/com/sun/tools/attach/BasicTests.java > > 81 // Need to add jdk/lib/tools.jar to classpath. > > > Best regards, > Katja (not a reviewer) > > > > On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review the fix below. >> >> To adress the previous review findings any referenes to "test.jdk" have been removed. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067945 >> webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ >> >> References to tools.jar are removed from the tests as jdk9 drops tools.jar >> >> Thanks, >> Alex From yekaterina.kantserova at oracle.com Wed Jan 21 12:25:36 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 21 Jan 2015 13:25:36 +0100 Subject: RFR(XXS): 8069296: java/lang/management/MemoryMXBean/LowMemoryTest.java should be quarantined Message-ID: <54BF9AC0.5070905@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8069296 webrev: http://cr.openjdk.java.net/~ykantser/8069296/webrev.00/ Thanks, Katja From dmitry.samersoff at oracle.com Wed Jan 21 13:05:54 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 21 Jan 2015 16:05:54 +0300 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <543FB4EF.5050706@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> Message-ID: <54BFA432.10500@oracle.com> David, Please, take a look at updated webrev http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ -Dmitry On 2014-10-16 16:07, David Holmes wrote: > Hi Dmitry, > > On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >> David, >> >> Changed. Thank you for review! >> >> please, see: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ > > 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { > > Isn't the only time it will return NULL when an exception occurs? > Conversely if an exception occurs then it must return NULL - so the > exception check seems redundant. > > But this also suggests you need similar logic at: > > 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, node->ref); > > 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, node->ref); > > Or more generally any JNI call from JVMTI should be wrapped in a way > that checks for exceptions and clears them. > > David > >> -Dmitry >> >> On 2014-10-16 04:24, David Holmes wrote: >>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Sorry, copied wrong function! >>>> >>>> I mean this call >>>> >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> >>>> that can post OutOfMemoryError >>> >>> Okay, so shouldn't that be where the exception is cleared: >>> >>> /* Create weak reference to make sure we have a reference */ >>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>> if (weakRef == NULL) { >>> + // < clear exception here > >>> jvmtiDeallocate(node); >>> return NULL; >>> } >>> >>> Thanks, >>> David >>> ----- >>> >>>> commonRef_refToID() -> >>>> >>>> createNode(JNIEnv *env, jobject ref) -> >>>> >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> >>>> -Dmitry >>>> >>>> On 2014-10-15 16:21, David Holmes wrote: >>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>> Please review the fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>> >>>>>>>> Added missed exception checks. >>>>>>> >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>> >>>>>>> What is potentially posting the exception? >>>>>> >>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>> commonRef_refToID() >>>>> >>>>> You mean this call: >>>>> >>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>> &tag); >>>> >>>> x >>>>> >>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI doesn't >>>>> post exceptions. >>>>> >>>>> "JVM TI functions never throw exceptions; error conditions are >>>>> communicated via the function return value. Any existing exception >>>>> state >>>>> is preserved across a call to a JVM TI function." >>>>> >>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>> >>>>> David >>>>> >>>>>> -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 staffan.larsen at oracle.com Wed Jan 21 14:04:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 21 Jan 2015 15:04:27 +0100 Subject: RFR(XXS): 8069296: java/lang/management/MemoryMXBean/LowMemoryTest.java should be quarantined In-Reply-To: <54BF9AC0.5070905@oracle.com> References: <54BF9AC0.5070905@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 21 jan 2015, at 13:25, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8069296 > webrev: http://cr.openjdk.java.net/~ykantser/8069296/webrev.00/ > > Thanks, > Katja From yekaterina.kantserova at oracle.com Wed Jan 21 14:05:26 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Wed, 21 Jan 2015 15:05:26 +0100 Subject: RFR(XXS): 8069296: java/lang/management/MemoryMXBean/LowMemoryTest.java should be quarantined In-Reply-To: References: <54BF9AC0.5070905@oracle.com> Message-ID: <54BFB226.60205@oracle.com> Thanks, Staffan! On 01/21/2015 03:04 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 21 jan 2015, at 13:25, Yekaterina Kantserova wrote: >> >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8069296 >> webrev: http://cr.openjdk.java.net/~ykantser/8069296/webrev.00/ >> >> Thanks, >> Katja From alexander.kulyakhtin at oracle.com Thu Jan 22 10:59:48 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 22 Jan 2015 02:59:48 -0800 (PST) Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) Message-ID: <28a8721b-d0f0-4634-a9ac-a7477fd482fa@default> Could someone from the reviewers group, please, review the changes, if possible, so they can be pushed? bug: https://bugs.openjdk.java.net/browse/JDK-8067945 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ Thank you very much Alex ----- Original Message ----- From: yekaterina.kantserova at oracle.com To: alexander.kulyakhtin at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Wednesday, January 21, 2015 3:07:06 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) Looks god to me (not a reviewer). // Katja On 01/21/2015 11:23 AM, Alexander Kulyakhtin wrote: > Hi Katia, > > Please, find attached the jdk.patch containing the changes per your findings. The patch has been made by running the webrev tool. > > Best regards, > Alex > > ----- Original Message ----- > From: yekaterina.kantserova at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Sent: Wednesday, January 21, 2015 12:11:58 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) > > Hi Alex, > > Comments bellow should be removed. You don't need to make a webrev for > it, only the changes are included in the final patch. > > test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java > > 39 // create files from given arguments and tools.jar > > test/com/sun/tools/attach/BasicTests.java > > 81 // Need to add jdk/lib/tools.jar to classpath. > > > Best regards, > Katja (not a reviewer) > > > > On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review the fix below. >> >> To adress the previous review findings any referenes to "test.jdk" have been removed. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8067945 >> webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ >> >> References to tools.jar are removed from the tests as jdk9 drops tools.jar >> >> Thanks, >> Alex From staffan.larsen at oracle.com Thu Jan 22 13:38:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 22 Jan 2015 14:38:06 +0100 Subject: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) In-Reply-To: <28a8721b-d0f0-4634-a9ac-a7477fd482fa@default> References: <28a8721b-d0f0-4634-a9ac-a7477fd482fa@default> Message-ID: <3CE0919A-FB6B-4E45-8BE4-8F67F24D7DB3@oracle.com> Looks good! Thanks, /Staffan > On 22 jan 2015, at 11:59, Alexander Kulyakhtin wrote: > > > Could someone from the reviewers group, please, review the changes, if possible, so they can be pushed? > > bug: https://bugs.openjdk.java.net/browse/JDK-8067945 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ > > Thank you very much > Alex > > ----- Original Message ----- > From: yekaterina.kantserova at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Wednesday, January 21, 2015 3:07:06 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) > > Looks god to me (not a reviewer). > > // Katja > > On 01/21/2015 11:23 AM, Alexander Kulyakhtin wrote: >> Hi Katia, >> >> Please, find attached the jdk.patch containing the changes per your findings. The patch has been made by running the webrev tool. >> >> Best regards, >> Alex >> >> ----- Original Message ----- >> From: yekaterina.kantserova at oracle.com >> To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net >> Sent: Wednesday, January 21, 2015 12:11:58 PM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: JDK-8067945: SVC jdk/test/* should be cleaned from JRE layout dependency (corrected per the review findings) >> >> Hi Alex, >> >> Comments bellow should be removed. You don't need to make a webrev for >> it, only the changes are included in the final patch. >> >> test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.java >> >> 39 // create files from given arguments and tools.jar >> >> test/com/sun/tools/attach/BasicTests.java >> >> 81 // Need to add jdk/lib/tools.jar to classpath. >> >> >> Best regards, >> Katja (not a reviewer) >> >> >> >> On 01/19/2015 05:00 PM, Alexander Kulyakhtin wrote: >>> Hi, >>> >>> Could you, please, review the fix below. >>> >>> To adress the previous review findings any referenes to "test.jdk" have been removed. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8067945 >>> webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8067945/webrev.01/ >>> >>> References to tools.jar are removed from the tests as jdk9 drops tools.jar >>> >>> Thanks, >>> Alex > From mike.yawn at oracle.com Thu Jan 22 14:24:26 2015 From: mike.yawn at oracle.com (Mike Yawn) Date: Thu, 22 Jan 2015 09:24:26 -0500 Subject: Issue with ObjectReferenceImpl.invokeMethod in jdk8 (invocation of an annotation method fails from debugger) Message-ID: <54C1081A.4010001@oracle.com> I'm seeing a regression moving from JDK7 to JDK8u40 with the invocation of a method in an annotation from a debugger. I have a simple annotation class with two methods. There is a unit test that retrieves the annotations (getDeclaredAnnotations()). After retrieving the annotations, I try to call ObjectReference.invokeMethod() to invoke each of the annotation's methods. In JDK7 this worked; in JDK8 it fails with an IllegalAccessException: "Not a default method". I've looked at the source for com.sun.tools.jdi.ObjectReferenceImpl and see significant changes between JDK7 and JDK8 due to the introduction of interface methods in JDK8. In JDK7, all methods were class (as opposed to interface) methods and the validation of the annotation methods was successful. In JDK8, validateMethodInvocation has been rewritten to be a small method that forwards the validation to one of two new methods, validateClassMethodInvocation or validateIFaceMethodInvocation. The implementation of validateClassMethodInvocation appears to be the same as the pre-JDK8 validateMethodInvocation -- validation that the annotation method would pass. However, the annotation method is being treated as an interface method (because method.declaringType() instanceof InterfaceTypeImpl is true) and going through validateIFaceMethodInvocation. The test there is that method.isDefault() -- and the annotation method returns false, thus the exception is thrown. I'm not sure what the correct behavior is here, but there are a couple of possibilities: - If annotation classes were treated as classes, rather than interfaces, then we'd go through the same validation as before and this would work. - Alternately. if methods on annotations were considered default methods, then we'd pass the new validation. (The annotations do have a "default" value specified, but not all annotation methods will, so this seems a less satisfactory solution) - Or, the validateIFaceMethodInvocation may need a special test for annotation methods and validate them differently than interface methods. Do I need to file a bug for this, or is this mailing list a better place to report/discuss the issue, or am I doing something wrong that I just got away with in JDK7 but JDK8 is closing a loophole, so to speak? Thanks, Mike Yawn From yekaterina.kantserova at oracle.com Fri Jan 23 08:51:25 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 23 Jan 2015 09:51:25 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54BF93E2.40401@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> <54BF7A06.7020408@oracle.com> <54BF93E2.40401@oracle.com> Message-ID: <54C20B8D.6070002@oracle.com> Hi, New webrev can be found here http://cr.openjdk.java.net/~ykantser/8044419/webrev.03/ The fix has been tested on all platforms except embedded. Thanks, Katja On 01/21/2015 12:56 PM, Dmitry Samersoff wrote: > Mattias, > > 1. mkFiles at ll. 215 above is reluctant > > 2. if you wish to store id output and grep the file it's better to do > something like: > > id > $HOME/jdb.ini > chmod a-r $HOME/jdb.ini > grep -q 'uid=0(' $HOME/jdb.ini 2> /dev/null > case $? in > 0) > echo "Can't make file unreadable running as root" > ;; > 1) > echo "Can't make file unreadable for some other reason" > ;; > 2) > if [ -f $HOME/jdb.ini ] > then > echo "OK. the file is unreadable" > else > echo "Can't create a file" > fi > ;; > esac > > > -Dmitry > > > > On 2015-01-21 13:05, Mattias Tobiasson wrote: >> Hi, >> Changes in this version: >> 1. Replaced the unnecessary grep from unreadable file with "id | grep ..." >> 2. Log that "permission denied" error message is expected. >> >> webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >> >> Thanks, >> Mattias >> >> On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: >>> Thanks for the suggestion. Your suggestion is a better way to check if >>> the user is root. >>> But if we only use that check, then we do not verify that the file is >>> really unreadable. >>> >>> I do not know if there are any other conditions, besides running as >>> root, that can fail to make a file unreadable. >>> I think it feels safer to really try to read the unreadable file. Then >>> we will get the error message. >>> >>> I could add a log that says the error message is expected. >>> And I can change the second "grep" to your suggestion. >>> >>> Mattias >>> >>> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>>> Mattias, >>>> >>>> After chmod a-r grep will display unpleasant >>>> permission denied error for non root user >>>> >>>> so it's better just do: >>>> >>>> if id | grep -q 'uid=0(' >>>> then >>>> Do root staff >>>> else >>>> Do non-root staff >>>> fi >>>> >>>> -Dmitry >>>> >>>> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>>>> Hi, >>>>> Could I please have a review of this test bug fix. >>>>> >>>>> Test expects some files to be unreadable. That does not work when >>>>> running as root. >>>>> The fix is to ignore the parts for unreadable files when running as >>>>> root. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>>>> >>>>> Tested as non-root on all platforms except embedded. >>>>> Tested as root on linux. >>>>> >>>>> Thanks, >>>>> Mattias >>>>> > From dmitry.samersoff at oracle.com Fri Jan 23 10:03:00 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 23 Jan 2015 13:03:00 +0300 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54C20B8D.6070002@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> <54BF7A06.7020408@oracle.com> <54BF93E2.40401@oracle.com> <54C20B8D.6070002@oracle.com> Message-ID: <54C21C54.8070406@oracle.com> Looks good for me. -Dmitry On 2015-01-23 11:51, Yekaterina Kantserova wrote: > Hi, > > New webrev can be found here > http://cr.openjdk.java.net/~ykantser/8044419/webrev.03/ > The fix has been tested on all platforms except embedded. > > Thanks, > Katja > > > > On 01/21/2015 12:56 PM, Dmitry Samersoff wrote: >> Mattias, >> >> 1. mkFiles at ll. 215 above is reluctant >> >> 2. if you wish to store id output and grep the file it's better to do >> something like: >> >> id > $HOME/jdb.ini >> chmod a-r $HOME/jdb.ini >> grep -q 'uid=0(' $HOME/jdb.ini 2> /dev/null >> case $? in >> 0) >> echo "Can't make file unreadable running as root" >> ;; >> 1) >> echo "Can't make file unreadable for some other reason" >> ;; >> 2) >> if [ -f $HOME/jdb.ini ] >> then >> echo "OK. the file is unreadable" >> else >> echo "Can't create a file" >> fi >> ;; >> esac >> >> >> -Dmitry >> >> >> >> On 2015-01-21 13:05, Mattias Tobiasson wrote: >>> Hi, >>> Changes in this version: >>> 1. Replaced the unnecessary grep from unreadable file with "id | grep >>> ..." >>> 2. Log that "permission denied" error message is expected. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>> >>> Thanks, >>> Mattias >>> >>> On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: >>>> Thanks for the suggestion. Your suggestion is a better way to check if >>>> the user is root. >>>> But if we only use that check, then we do not verify that the file is >>>> really unreadable. >>>> >>>> I do not know if there are any other conditions, besides running as >>>> root, that can fail to make a file unreadable. >>>> I think it feels safer to really try to read the unreadable file. Then >>>> we will get the error message. >>>> >>>> I could add a log that says the error message is expected. >>>> And I can change the second "grep" to your suggestion. >>>> >>>> Mattias >>>> >>>> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>>>> Mattias, >>>>> >>>>> After chmod a-r grep will display unpleasant >>>>> permission denied error for non root user >>>>> >>>>> so it's better just do: >>>>> >>>>> if id | grep -q 'uid=0(' >>>>> then >>>>> Do root staff >>>>> else >>>>> Do non-root staff >>>>> fi >>>>> >>>>> -Dmitry >>>>> >>>>> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>>>>> Hi, >>>>>> Could I please have a review of this test bug fix. >>>>>> >>>>>> Test expects some files to be unreadable. That does not work when >>>>>> running as root. >>>>>> The fix is to ignore the parts for unreadable files when running as >>>>>> root. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>>>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>>>>> >>>>>> Tested as non-root on all platforms except embedded. >>>>>> Tested as root on linux. >>>>>> >>>>>> Thanks, >>>>>> Mattias >>>>>> >> > -- 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 daniel.daugherty at oracle.com Fri Jan 23 14:06:56 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 23 Jan 2015 07:06:56 -0700 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54BD3D5A.1030903@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> <54BD28F7.7040905@oracle.com> <54BD3D5A.1030903@oracle.com> Message-ID: <54C25580.8040404@oracle.com> Serguei, Sorry I forgot to close the loop on this review. I'm OK with the answers below. Thumbs up. Dan On 1/19/15 10:22 AM, serguei.spitsyn at oracle.com wrote: > Coleen, > > Thank you for answering questions below! > > Thanks, > Serguei > > > On 1/19/15 7:55 AM, Coleen Phillimore wrote: >> >> On 1/16/15, 9:24 PM, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>> >>> src/share/vm/memory/universe.hpp >>> No comments. >>> >>> src/share/vm/memory/universe.cpp >>> No comments. >>> >>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>> So redefining the Unsafe class is now very expensive because >>> we have to visit the i-table and v-table of every class (and >>> maybe interface?)... >>> >>> Based on the bug report 'Unsafe::throw_illegal_access' is some >>> magical method that can appear in any i-table or v-table entry. >>> Maybe only as part of some default methods thing? That's not >>> clear to me so I'm just guessing... >> >> True. >>> >>> Is there some way to limit this visit to classes where the >>> magical method can appear? Or can it really appear anywhere? >> >> The Unsafe methods can appear in any itable now. I don't know of a >> way to limit this. Fortunately, redefining Unsafe seems to be an >> unusual thing to do, except for this stress test. >> >> Coleen >> >>> >>> Dan >>> >>> >>> On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >>>> Dan, David H. or David C., >>>> >>>> May I ask one of you to look at the webrev below? >>>> The issue itself is a little bit tricky, so it is not easy to >>>> review despite the small size. >>>> >>>> Coleen, >>>> >>>> Does the webrev matches what we discussed with you? >>>> Do you give me a thumbs up? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> May I ask >>>> >>>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>>> >>>>> >>>>> Open webrevs: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>>> >>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> >>>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used in >>>>> place of a default >>>>> interface method in the itable if a default method was not >>>>> defined in the interface. >>>>> In fact, it happens for two interfaces that purhaps are >>>>> auto-generated: >>>>> java/nio/CharBuffer >>>>> java/nio/HeapCharBuffer >>>>> >>>>> This approach creates a problem when the class sun.misc.Unsafe >>>>> is retransformed. >>>>> The Method* pointer to the old (redefined) method in the itable >>>>> triggers an assert >>>>> (see the hs_err log in the bug report). >>>>> Coleen told me that a similar approach is going to be >>>>> implemented for some vtable entries. >>>>> Coleen, thanks for suggesting a better fix for this issue! >>>>> >>>>> The fix is to replace the old Unsafe method in the >>>>> itable/vtable with the latest method version. >>>>> >>>>> >>>>> Testing: >>>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>> >>> >> > > From staffan.larsen at oracle.com Fri Jan 23 15:43:03 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 23 Jan 2015 16:43:03 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: <54C20B8D.6070002@oracle.com> References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> <54BF7A06.7020408@oracle.com> <54BF93E2.40401@oracle.com> <54C20B8D.6070002@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 23 jan 2015, at 09:51, Yekaterina Kantserova wrote: > > Hi, > > New webrev can be found here http://cr.openjdk.java.net/~ykantser/8044419/webrev.03/ > The fix has been tested on all platforms except embedded. > > Thanks, > Katja > > > > On 01/21/2015 12:56 PM, Dmitry Samersoff wrote: >> Mattias, >> >> 1. mkFiles at ll. 215 above is reluctant >> >> 2. if you wish to store id output and grep the file it's better to do >> something like: >> >> id > $HOME/jdb.ini >> chmod a-r $HOME/jdb.ini >> grep -q 'uid=0(' $HOME/jdb.ini 2> /dev/null >> case $? in >> 0) >> echo "Can't make file unreadable running as root" >> ;; >> 1) >> echo "Can't make file unreadable for some other reason" >> ;; >> 2) >> if [ -f $HOME/jdb.ini ] >> then >> echo "OK. the file is unreadable" >> else >> echo "Can't create a file" >> fi >> ;; >> esac >> >> >> -Dmitry >> >> >> >> On 2015-01-21 13:05, Mattias Tobiasson wrote: >>> Hi, >>> Changes in this version: >>> 1. Replaced the unnecessary grep from unreadable file with "id | grep ..." >>> 2. Log that "permission denied" error message is expected. >>> >>> webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>> >>> Thanks, >>> Mattias >>> >>> On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: >>>> Thanks for the suggestion. Your suggestion is a better way to check if >>>> the user is root. >>>> But if we only use that check, then we do not verify that the file is >>>> really unreadable. >>>> >>>> I do not know if there are any other conditions, besides running as >>>> root, that can fail to make a file unreadable. >>>> I think it feels safer to really try to read the unreadable file. Then >>>> we will get the error message. >>>> >>>> I could add a log that says the error message is expected. >>>> And I can change the second "grep" to your suggestion. >>>> >>>> Mattias >>>> >>>> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>>>> Mattias, >>>>> >>>>> After chmod a-r grep will display unpleasant >>>>> permission denied error for non root user >>>>> >>>>> so it's better just do: >>>>> >>>>> if id | grep -q 'uid=0(' >>>>> then >>>>> Do root staff >>>>> else >>>>> Do non-root staff >>>>> fi >>>>> >>>>> -Dmitry >>>>> >>>>> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>>>>> Hi, >>>>>> Could I please have a review of this test bug fix. >>>>>> >>>>>> Test expects some files to be unreadable. That does not work when >>>>>> running as root. >>>>>> The fix is to ignore the parts for unreadable files when running as >>>>>> root. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>>>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>>>>> >>>>>> Tested as non-root on all platforms except embedded. >>>>>> Tested as root on linux. >>>>>> >>>>>> Thanks, >>>>>> Mattias >>>>>> >> > From yekaterina.kantserova at oracle.com Fri Jan 23 15:47:06 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Fri, 23 Jan 2015 16:47:06 +0100 Subject: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root In-Reply-To: References: <54BD059A.9000604@oracle.com> <54BD1F1A.9080400@oracle.com> <54BE3B2E.1090603@oracle.com> <54BF7A06.7020408@oracle.com> <54BF93E2.40401@oracle.com> <54C20B8D.6070002@oracle.com> Message-ID: <54C26CFA.9@oracle.com> Dmitry, Staffan, thanks for your reviews! // Katja On 01/23/2015 04:43 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 23 jan 2015, at 09:51, Yekaterina Kantserova wrote: >> >> Hi, >> >> New webrev can be found here http://cr.openjdk.java.net/~ykantser/8044419/webrev.03/ >> The fix has been tested on all platforms except embedded. >> >> Thanks, >> Katja >> >> >> >> On 01/21/2015 12:56 PM, Dmitry Samersoff wrote: >>> Mattias, >>> >>> 1. mkFiles at ll. 215 above is reluctant >>> >>> 2. if you wish to store id output and grep the file it's better to do >>> something like: >>> >>> id > $HOME/jdb.ini >>> chmod a-r $HOME/jdb.ini >>> grep -q 'uid=0(' $HOME/jdb.ini 2> /dev/null >>> case $? in >>> 0) >>> echo "Can't make file unreadable running as root" >>> ;; >>> 1) >>> echo "Can't make file unreadable for some other reason" >>> ;; >>> 2) >>> if [ -f $HOME/jdb.ini ] >>> then >>> echo "OK. the file is unreadable" >>> else >>> echo "Can't create a file" >>> fi >>> ;; >>> esac >>> >>> >>> -Dmitry >>> >>> >>> >>> On 2015-01-21 13:05, Mattias Tobiasson wrote: >>>> Hi, >>>> Changes in this version: >>>> 1. Replaced the unnecessary grep from unreadable file with "id | grep ..." >>>> 2. Log that "permission denied" error message is expected. >>>> >>>> webrev: http://cr.openjdk.java.net/~ykantser/8044419/webrev.02/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>> >>>> Thanks, >>>> Mattias >>>> >>>> On 01/20/2015 12:25 PM, Mattias Tobiasson wrote: >>>>> Thanks for the suggestion. Your suggestion is a better way to check if >>>>> the user is root. >>>>> But if we only use that check, then we do not verify that the file is >>>>> really unreadable. >>>>> >>>>> I do not know if there are any other conditions, besides running as >>>>> root, that can fail to make a file unreadable. >>>>> I think it feels safer to really try to read the unreadable file. Then >>>>> we will get the error message. >>>>> >>>>> I could add a log that says the error message is expected. >>>>> And I can change the second "grep" to your suggestion. >>>>> >>>>> Mattias >>>>> >>>>> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>>>>> Mattias, >>>>>> >>>>>> After chmod a-r grep will display unpleasant >>>>>> permission denied error for non root user >>>>>> >>>>>> so it's better just do: >>>>>> >>>>>> if id | grep -q 'uid=0(' >>>>>> then >>>>>> Do root staff >>>>>> else >>>>>> Do non-root staff >>>>>> fi >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2015-01-19 16:24, Mattias Tobiasson wrote: >>>>>>> Hi, >>>>>>> Could I please have a review of this test bug fix. >>>>>>> >>>>>>> Test expects some files to be unreadable. That does not work when >>>>>>> running as root. >>>>>>> The fix is to ignore the parts for unreadable files when running as >>>>>>> root. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044419 >>>>>>> webrev: http://cr.openjdk.java.net/~miauno/8044419/webrev.01 >>>>>>> >>>>>>> Tested as non-root on all platforms except embedded. >>>>>>> Tested as root on linux. >>>>>>> >>>>>>> Thanks, >>>>>>> Mattias >>>>>>> From coleen.phillimore at oracle.com Fri Jan 23 16:51:59 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 23 Jan 2015 11:51:59 -0500 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54C25580.8040404@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> <54BD28F7.7040905@oracle.com> <54BD3D5A.1030903@oracle.com> <54C25580.8040404@oracle.com> Message-ID: <54C27C2F.4020209@oracle.com> This still looks good to me. Coleen On 1/23/15, 9:06 AM, Daniel D. Daugherty wrote: > Serguei, > > Sorry I forgot to close the loop on this review. > > I'm OK with the answers below. Thumbs up. > > Dan > > > On 1/19/15 10:22 AM, serguei.spitsyn at oracle.com wrote: >> Coleen, >> >> Thank you for answering questions below! >> >> Thanks, >> Serguei >> >> >> On 1/19/15 7:55 AM, Coleen Phillimore wrote: >>> >>> On 1/16/15, 9:24 PM, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>> >>>> src/share/vm/memory/universe.hpp >>>> No comments. >>>> >>>> src/share/vm/memory/universe.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>> So redefining the Unsafe class is now very expensive because >>>> we have to visit the i-table and v-table of every class (and >>>> maybe interface?)... >>>> >>>> Based on the bug report 'Unsafe::throw_illegal_access' is some >>>> magical method that can appear in any i-table or v-table entry. >>>> Maybe only as part of some default methods thing? That's not >>>> clear to me so I'm just guessing... >>> >>> True. >>>> >>>> Is there some way to limit this visit to classes where the >>>> magical method can appear? Or can it really appear anywhere? >>> >>> The Unsafe methods can appear in any itable now. I don't know of a >>> way to limit this. Fortunately, redefining Unsafe seems to be an >>> unusual thing to do, except for this stress test. >>> >>> Coleen >>> >>>> >>>> Dan >>>> >>>> >>>> On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >>>>> Dan, David H. or David C., >>>>> >>>>> May I ask one of you to look at the webrev below? >>>>> The issue itself is a little bit tricky, so it is not easy to >>>>> review despite the small size. >>>>> >>>>> Coleen, >>>>> >>>>> Does the webrev matches what we discussed with you? >>>>> Do you give me a thumbs up? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> May I ask >>>>> >>>>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>>>> >>>>>> >>>>>> Open webrevs: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>>>> >>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used >>>>>> in place of a default >>>>>> interface method in the itable if a default method was not >>>>>> defined in the interface. >>>>>> In fact, it happens for two interfaces that purhaps are >>>>>> auto-generated: >>>>>> java/nio/CharBuffer >>>>>> java/nio/HeapCharBuffer >>>>>> >>>>>> This approach creates a problem when the class sun.misc.Unsafe >>>>>> is retransformed. >>>>>> The Method* pointer to the old (redefined) method in the >>>>>> itable triggers an assert >>>>>> (see the hs_err log in the bug report). >>>>>> Coleen told me that a similar approach is going to be >>>>>> implemented for some vtable entries. >>>>>> Coleen, thanks for suggesting a better fix for this issue! >>>>>> >>>>>> The fix is to replace the old Unsafe method in the >>>>>> itable/vtable with the latest method version. >>>>>> >>>>>> >>>>>> Testing: >>>>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Fri Jan 23 18:50:05 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 23 Jan 2015 10:50:05 -0800 Subject: 4-th round RFR (XS) 8068162: jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found In-Reply-To: <54C27C2F.4020209@oracle.com> References: <54B60308.4000105@oracle.com> <54B96301.40108@oracle.com> <54B9C7CB.60103@oracle.com> <54BD28F7.7040905@oracle.com> <54BD3D5A.1030903@oracle.com> <54C25580.8040404@oracle.com> <54C27C2F.4020209@oracle.com> Message-ID: <54C297DD.7040906@oracle.com> Coleen and Dan, Thanks! Serguei On 1/23/15 8:51 AM, Coleen Phillimore wrote: > > This still looks good to me. > Coleen > > On 1/23/15, 9:06 AM, Daniel D. Daugherty wrote: >> Serguei, >> >> Sorry I forgot to close the loop on this review. >> >> I'm OK with the answers below. Thumbs up. >> >> Dan >> >> >> On 1/19/15 10:22 AM, serguei.spitsyn at oracle.com wrote: >>> Coleen, >>> >>> Thank you for answering questions below! >>> >>> Thanks, >>> Serguei >>> >>> >>> On 1/19/15 7:55 AM, Coleen Phillimore wrote: >>>> >>>> On 1/16/15, 9:24 PM, Daniel D. Daugherty wrote: >>>>> > >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>>> >>>>> src/share/vm/memory/universe.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/memory/universe.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/jvmtiRedefineClasses.cpp >>>>> So redefining the Unsafe class is now very expensive because >>>>> we have to visit the i-table and v-table of every class (and >>>>> maybe interface?)... >>>>> >>>>> Based on the bug report 'Unsafe::throw_illegal_access' is some >>>>> magical method that can appear in any i-table or v-table entry. >>>>> Maybe only as part of some default methods thing? That's not >>>>> clear to me so I'm just guessing... >>>> >>>> True. >>>>> >>>>> Is there some way to limit this visit to classes where the >>>>> magical method can appear? Or can it really appear anywhere? >>>> >>>> The Unsafe methods can appear in any itable now. I don't know of >>>> a way to limit this. Fortunately, redefining Unsafe seems to be an >>>> unusual thing to do, except for this stress test. >>>> >>>> Coleen >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 1/16/15 12:14 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Dan, David H. or David C., >>>>>> >>>>>> May I ask one of you to look at the webrev below? >>>>>> The issue itself is a little bit tricky, so it is not easy to >>>>>> review despite the small size. >>>>>> >>>>>> Coleen, >>>>>> >>>>>> Does the webrev matches what we discussed with you? >>>>>> Do you give me a thumbs up? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> May I ask >>>>>> >>>>>> On 1/13/15 9:47 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8068162 >>>>>>> >>>>>>> >>>>>>> Open webrevs: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8068162-JVMTI-old.4/ >>>>>>> >>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8068162-Test-IsModifiableAgent/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> The sun.misc.Unsafe:throwIllegalAccessError() method is used >>>>>>> in place of a default >>>>>>> interface method in the itable if a default method was not >>>>>>> defined in the interface. >>>>>>> In fact, it happens for two interfaces that purhaps are >>>>>>> auto-generated: >>>>>>> java/nio/CharBuffer >>>>>>> java/nio/HeapCharBuffer >>>>>>> >>>>>>> This approach creates a problem when the class >>>>>>> sun.misc.Unsafe is retransformed. >>>>>>> The Method* pointer to the old (redefined) method in the >>>>>>> itable triggers an assert >>>>>>> (see the hs_err log in the bug report). >>>>>>> Coleen told me that a similar approach is going to be >>>>>>> implemented for some vtable entries. >>>>>>> Coleen, thanks for suggesting a better fix for this issue! >>>>>>> >>>>>>> The fix is to replace the old Unsafe method in the >>>>>>> itable/vtable with the latest method version. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> In progress: nsk.jdi.testlist, JTREG java/lang/instrument tests >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From yasuenag at gmail.com Sun Jan 25 13:15:43 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 25 Jan 2015 22:15:43 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() Message-ID: <54C4EC7F.2010509@gmail.com> Hi all, GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . I uploaded webrev for this enhancement: http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. Could you review it? Thanks, Yasumasa From kirk at kodewerk.com Sun Jan 25 13:56:33 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 25 Jan 2015 14:56:33 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54C4EC7F.2010509@gmail.com> References: <54C4EC7F.2010509@gmail.com> Message-ID: <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> Hi, IMHO, if a System.gc() is being called then the cause should be System.gc(). If we start down the road of differentiating between the various causes of calls to System.gc() this will turn in a nightmare! Indeed as I look at the patch it?s curious that it?s up to the caller to determine is calls to System.gc() have been suppressed. I would have expected the collect() call to make the decision as to should the call be honored or not. void SystemGCDCmd::execute(DCmdSource source, TRAPS) { if (!DisableExplicitGC) { Universe::heap()->collect(GCCause::_jcmd_gc_run); } else { output()->print_cr("Explicit GC is disabled, no GC has been performed."); } Kind regards, Kirk Pepperdine On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga wrote: > Hi all, > > GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. > I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . > > I uploaded webrev for this enhancement: > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ > > This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. > > > Could you review it? > > > Thanks, > > Yasumasa -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From yasuenag at gmail.com Sun Jan 25 15:11:31 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 26 Jan 2015 00:11:31 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> References: <54C4EC7F.2010509@gmail.com> <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> Message-ID: <54C507A3.3010708@gmail.com> Hi Kirk, I think the System.gc() call which is invoked by jcmd is special case and I want to distinguish it. Programmer can call System.gc() from their code. But GC which is invoked by jcmd is NOT explicitly call by programmer. Indeed, SystemGCDCmd will call System.gc() (same meaning). However, I think it has different meaning from System.gc() call from source code. Thanks, Yasumasa On 2015/01/25 22:56, Kirk Pepperdine wrote: > Hi, > > IMHO, if a System.gc() is being called then the cause should be System.gc(). If we start down the road of differentiating between the various causes of calls to System.gc() this will turn in a nightmare! > > Indeed as I look at the patch it?s curious that it?s up to the caller to determine is calls to System.gc() have been suppressed. I would have expected the collect() call to make the decision as to should the call be honored or not. > > void SystemGCDCmd::execute(DCmdSource source, TRAPS) { > if (!DisableExplicitGC) { > Universe::heap()->collect(GCCause::_jcmd_gc_run); > } else { > output()->print_cr("Explicit GC is disabled, no GC has been performed."); > } > > > > Kind regards, > Kirk Pepperdine > > On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga > wrote: > >> Hi all, >> >> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >> >> I uploaded webrev for this enhancement: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >> >> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >> >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa > From kirk at kodewerk.com Sun Jan 25 21:14:37 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sun, 25 Jan 2015 22:14:37 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54C507A3.3010708@gmail.com> References: <54C4EC7F.2010509@gmail.com> <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> <54C507A3.3010708@gmail.com> Message-ID: Hi Yasumasa, > > I think the System.gc() call which is invoked by jcmd is special case and I want to > distinguish it. > Programmer can call System.gc() from their code. But GC which is invoked by jcmd is NOT explicitly call by programmer. System.gc() called for by RMI is also not explicitly called by the programmer either. There are also other tools that will result in calls to System.gc() also. Should we catalog them in GCCause also? > > Indeed, SystemGCDCmd will call System.gc() (same meaning). > However, I think it has different meaning from System.gc() call from source code. I?m not sure I understand the point. From an analytical POV, a single call to System.gc() is pretty much meaningless. If it?s regular or there is a pattern in the frequency of the calls then I?m interested. A call to System.gc() has the same effect no matter who or why is responsible. My interest lies in keeping the GC logs as simple as possible. If there is meaningful data to add so be it. That said, I?m not sure that this change meets that bar. That said, I?m still concerned that the caller/callee division seems inside out. But it?s Sunday so? Kind regards, Kirk Pepperdine > > > Thanks, > > Yasumasa > > > On 2015/01/25 22:56, Kirk Pepperdine wrote: >> Hi, >> >> IMHO, if a System.gc() is being called then the cause should be System.gc(). If we start down the road of differentiating between the various causes of calls to System.gc() this will turn in a nightmare! >> >> Indeed as I look at the patch it?s curious that it?s up to the caller to determine is calls to System.gc() have been suppressed. I would have expected the collect() call to make the decision as to should the call be honored or not. >> >> void SystemGCDCmd::execute(DCmdSource source, TRAPS) { >> if (!DisableExplicitGC) { >> Universe::heap()->collect(GCCause::_jcmd_gc_run); >> } else { >> output()->print_cr("Explicit GC is disabled, no GC has been performed."); >> } >> >> >> >> Kind regards, >> Kirk Pepperdine >> >> On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga > wrote: >> >>> Hi all, >>> >>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >>> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >>> >>> I uploaded webrev for this enhancement: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >>> >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >>> >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From yasuenag at gmail.com Mon Jan 26 03:53:01 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 26 Jan 2015 12:53:01 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> <54C507A3.3010708@gmail.com> Message-ID: Hi Kirk, I want to distinguish GC whether it is requested from internal (e.g. System.gc()) or not. System.gc() is called in RMI as you said. In JVM implementation, entry point of GC is Universe::heap()->collect() family. It is used by JVMTI force GC, heap inspection (e.g. jmap), etc. Thus I guess that GCCause which is invoked from JVM should set valid GCCause which is not System.gc(). So I file this enhancement to JBS and create a patch. Thanks, Yasumasa 2015/01/26 6:14 "Kirk Pepperdine" : > Hi Yasumasa, > > > > > > I think the System.gc() call which is invoked by jcmd is special case > and I want to > > distinguish it. > > Programmer can call System.gc() from their code. But GC which is invoked > by jcmd is NOT explicitly call by programmer. > > System.gc() called for by RMI is also not explicitly called by the > programmer either. There are also other tools that will result in calls to > System.gc() also. Should we catalog them in GCCause also? > > > > > Indeed, SystemGCDCmd will call System.gc() (same meaning). > > However, I think it has different meaning from System.gc() call from > source code. > > I?m not sure I understand the point. From an analytical POV, a single call > to System.gc() is pretty much meaningless. If it?s regular or there is a > pattern in the frequency of the calls then I?m interested. A call to > System.gc() has the same effect no matter who or why is responsible. > > My interest lies in keeping the GC logs as simple as possible. If there is > meaningful data to add so be it. That said, I?m not sure that this change > meets that bar. > > That said, I?m still concerned that the caller/callee division seems > inside out. But it?s Sunday so? > > Kind regards, > Kirk Pepperdine > > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/25 22:56, Kirk Pepperdine wrote: > >> Hi, > >> > >> IMHO, if a System.gc() is being called then the cause should be > System.gc(). If we start down the road of differentiating between the > various causes of calls to System.gc() this will turn in a nightmare! > >> > >> Indeed as I look at the patch it?s curious that it?s up to the caller > to determine is calls to System.gc() have been suppressed. I would have > expected the collect() call to make the decision as to should the call be > honored or not. > >> > >> void SystemGCDCmd::execute(DCmdSource source, TRAPS) { > >> if (!DisableExplicitGC) { > >> Universe::heap()->collect(GCCause::_jcmd_gc_run); > >> } else { > >> output()->print_cr("Explicit GC is disabled, no GC has been > performed."); > >> } > >> > >> > >> > >> Kind regards, > >> Kirk Pepperdine > >> > >> On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga > wrote: > >> > >>> Hi all, > >>> > >>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run > is invoked. > >>> I think that GCCause which is caused by jcmd GC.run should be > different from System.gc() . > >>> > >>> I uploaded webrev for this enhancement: > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ > >>> > >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. > >>> > >>> > >>> Could you review it? > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Mon Jan 26 07:50:21 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Mon, 26 Jan 2015 08:50:21 +0100 Subject: RFR(XXS): 8071324: com/sun/jdi/ConnectedVMs.java should be quarantined Message-ID: <54C5F1BD.1000306@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071324 webrev: http://cr.openjdk.java.net/~ykantser/8071324/webrev.00/ Thanks, Katja From staffan.larsen at oracle.com Mon Jan 26 08:12:57 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 26 Jan 2015 09:12:57 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54C4EC7F.2010509@gmail.com> References: <54C4EC7F.2010509@gmail.com> Message-ID: <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. Thanks, /Staffan > On 25 jan 2015, at 14:15, Yasumasa Suenaga wrote: > > Hi all, > > GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. > I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . > > I uploaded webrev for this enhancement: > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ > > This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. > > > Could you review it? > > > Thanks, > > Yasumasa From goetz.lindenmaier at sap.com Mon Jan 26 08:20:59 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 26 Jan 2015 08:20:59 +0000 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF70D40@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF70D40@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF71FB7@DEWDFEMB12A.global.corp.sap> Hi, could please somebody from servicability sponsor this tiny change? (My first mail didn't go through, because I wasn't yet registered to servicability-dev). Thanks, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 16. Januar 2015 23:56 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available This seems fine. Someone from the serviceability group should probably sponsor. Thanks, Coleen On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review for this small fix? I also please need a sponsor. > > Thanks, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Montag, 12. Januar 2015 09:23 > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > Hi, > > This test uses SA, thus fails on platforms where that's not implemented. > I see problems on mac and aix. > Call Platform.shouldSAAttach() to check whether SA should work. > > Please review this small fix. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ > > Best regards, > Goetz. From kirk at kodewerk.com Mon Jan 26 08:28:01 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Jan 2015 09:28:01 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <29BADC3B-21A8-4B04-9D18-D7C3217256E0@kodewerk.com> <54C507A3.3010708@gmail.com> Message-ID: <87B28F4F-A80D-4502-9D4C-1E730ACA9F23@kodewerk.com> Hi Yasumasa, Thank you for your review of the code. Indeed you have filed this as a bug and it has been commented on as an enhancement, not a bug. As I have mentioned a single call to System.gc() makes no difference in any analytic that I performed on any application that I?ve encountered in the wild no matter what the cause. Other issues: it?s not currently clear to me that jcmd is the only entry point to this call and that would make the message misleading for those other paths. There are other entry points that can results in a full GC but they will remain labeled as is. I also see a downstream impact on tooling. Thus I don?t see a compelling argument for the value of this change thus I will argue towards not destabilizing downstream tooling. That said, I?ve said my piece and have added enough spam to the list on this subject. Kind regards, Kirk Pepperdine On Jan 26, 2015, at 4:53 AM, Yasumasa Suenaga wrote: > Hi Kirk, > > I want to distinguish GC whether it is requested from internal (e.g. System.gc()) or not. > System.gc() is called in RMI as you said. > > In JVM implementation, entry point of GC is Universe::heap()->collect() family. It is used by JVMTI force GC, heap inspection (e.g. jmap), etc. Thus I guess that GCCause which is invoked from JVM should set valid GCCause which is not System.gc(). > So I file this enhancement to JBS and create a patch. > > Thanks, > > Yasumasa > > 2015/01/26 6:14 "Kirk Pepperdine" : > Hi Yasumasa, > > > > > > I think the System.gc() call which is invoked by jcmd is special case and I want to > > distinguish it. > > Programmer can call System.gc() from their code. But GC which is invoked by jcmd is NOT explicitly call by programmer. > > System.gc() called for by RMI is also not explicitly called by the programmer either. There are also other tools that will result in calls to System.gc() also. Should we catalog them in GCCause also? > > > > > Indeed, SystemGCDCmd will call System.gc() (same meaning). > > However, I think it has different meaning from System.gc() call from source code. > > I?m not sure I understand the point. From an analytical POV, a single call to System.gc() is pretty much meaningless. If it?s regular or there is a pattern in the frequency of the calls then I?m interested. A call to System.gc() has the same effect no matter who or why is responsible. > > My interest lies in keeping the GC logs as simple as possible. If there is meaningful data to add so be it. That said, I?m not sure that this change meets that bar. > > That said, I?m still concerned that the caller/callee division seems inside out. But it?s Sunday so? > > Kind regards, > Kirk Pepperdine > > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2015/01/25 22:56, Kirk Pepperdine wrote: > >> Hi, > >> > >> IMHO, if a System.gc() is being called then the cause should be System.gc(). If we start down the road of differentiating between the various causes of calls to System.gc() this will turn in a nightmare! > >> > >> Indeed as I look at the patch it?s curious that it?s up to the caller to determine is calls to System.gc() have been suppressed. I would have expected the collect() call to make the decision as to should the call be honored or not. > >> > >> void SystemGCDCmd::execute(DCmdSource source, TRAPS) { > >> if (!DisableExplicitGC) { > >> Universe::heap()->collect(GCCause::_jcmd_gc_run); > >> } else { > >> output()->print_cr("Explicit GC is disabled, no GC has been performed."); > >> } > >> > >> > >> > >> Kind regards, > >> Kirk Pepperdine > >> > >> On Jan 25, 2015, at 2:15 PM, Yasumasa Suenaga > wrote: > >> > >>> Hi all, > >>> > >>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. > >>> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . > >>> > >>> I uploaded webrev for this enhancement: > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ > >>> > >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. > >>> > >>> > >>> Could you review it? > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.larsen at oracle.com Mon Jan 26 08:42:59 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 26 Jan 2015 09:42:59 +0100 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF71FB7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF70D40@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF71FB7@DEWDFEMB12A.global.corp.sap> Message-ID: <763407CB-A3AE-44D9-A6CD-A864E3A62CBC@oracle.com> Change looks good to me - I?ll sponsor it! /Staffan > On 26 jan 2015, at 09:20, Lindenmaier, Goetz wrote: > > Hi, > > could please somebody from servicability sponsor this tiny change? > > (My first mail didn't go through, because I wasn't yet registered to servicability-dev). > > Thanks, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Freitag, 16. Januar 2015 23:56 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > > This seems fine. Someone from the serviceability group should probably > sponsor. > > Thanks, > Coleen > > On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get a review for this small fix? I also please need a sponsor. >> >> Thanks, >> Goetz. >> >> From: goetz.lindenmaier at sap.com >> Sent: Montag, 12. Januar 2015 09:23 >> To: hotspot-dev at openjdk.java.net >> Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available >> >> Hi, >> >> This test uses SA, thus fails on platforms where that's not implemented. >> I see problems on mac and aix. >> Call Platform.shouldSAAttach() to check whether SA should work. >> >> Please review this small fix. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ >> >> Best regards, >> Goetz. > From staffan.larsen at oracle.com Mon Jan 26 08:45:57 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 26 Jan 2015 09:45:57 +0100 Subject: RFR(XXS): 8071324: com/sun/jdi/ConnectedVMs.java should be quarantined In-Reply-To: <54C5F1BD.1000306@oracle.com> References: <54C5F1BD.1000306@oracle.com> Message-ID: <490BD951-6716-40CA-9BDE-31C492E509B7@oracle.com> Looks good! Thanks, /Staffan > On 26 jan 2015, at 08:50, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071324 > webrev: http://cr.openjdk.java.net/~ykantser/8071324/webrev.00/ > > Thanks, > Katja From goetz.lindenmaier at sap.com Mon Jan 26 09:08:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 26 Jan 2015 09:08:36 +0000 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <763407CB-A3AE-44D9-A6CD-A864E3A62CBC@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF70D40@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF71FB7@DEWDFEMB12A.global.corp.sap> <763407CB-A3AE-44D9-A6CD-A864E3A62CBC@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF72005@DEWDFEMB12A.global.corp.sap> That's great, thanks a lot Staffan! Best regards, Goetz. -----Original Message----- From: Staffan Larsen [mailto:staffan.larsen at oracle.com] Sent: Montag, 26. Januar 2015 09:43 To: Lindenmaier, Goetz Cc: serviceability-dev (serviceability-dev at openjdk.java.net); hotspot-dev at openjdk.java.net Developers Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available Change looks good to me - I?ll sponsor it! /Staffan > On 26 jan 2015, at 09:20, Lindenmaier, Goetz wrote: > > Hi, > > could please somebody from servicability sponsor this tiny change? > > (My first mail didn't go through, because I wasn't yet registered to servicability-dev). > > Thanks, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Freitag, 16. Januar 2015 23:56 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > > This seems fine. Someone from the serviceability group should probably > sponsor. > > Thanks, > Coleen > > On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> could I please get a review for this small fix? I also please need a sponsor. >> >> Thanks, >> Goetz. >> >> From: goetz.lindenmaier at sap.com >> Sent: Montag, 12. Januar 2015 09:23 >> To: hotspot-dev at openjdk.java.net >> Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available >> >> Hi, >> >> This test uses SA, thus fails on platforms where that's not implemented. >> I see problems on mac and aix. >> Call Platform.shouldSAAttach() to check whether SA should work. >> >> Please review this small fix. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ >> >> Best regards, >> Goetz. > From kirk at kodewerk.com Mon Jan 26 10:07:09 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 26 Jan 2015 11:07:09 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> Message-ID: Hi Staffan, There are other entry points in diagnosticCommand that will trigger a Full GC. void ClassHistogramDCmd::execute(DCmdSource source, TRAPS) { VM_GC_HeapInspection heapop(output(), !_all.value() /* request full gc if false */); VMThread::execute(&heapop); } and void HeapDumpDCmd::execute(DCmdSource source, TRAPS) { // Request a full GC before heap dump if _all is false // This helps reduces the amount of unreachable objects in the dump // and makes it easier to browse. HeapDumper dumper(!_all.value() /* request GC if _all is false*/); int res = dumper.dump(_filename.value()); if (res == 0) { output()->print_cr("Heap dump file created"); } else { // heap dump failed ResourceMark rm; char* error = dumper.error_as_C_string(); if (error == NULL) { output()->print_cr("Dump failed - reason unknown"); } else { output()->print_cr("%s", error); } } } For example. For consistency, how would you suggest these be handled. Kind regards, Kirk Pepperdine On Jan 26, 2015, at 9:12 AM, Staffan Larsen wrote: > A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. > > Thanks, > /Staffan > >> On 25 jan 2015, at 14:15, Yasumasa Suenaga wrote: >> >> Hi all, >> >> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >> >> I uploaded webrev for this enhancement: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >> >> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >> >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.larsen at oracle.com Mon Jan 26 11:34:39 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 26 Jan 2015 12:34:39 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> Message-ID: HeapDumper uses GCCause::_heap_dump as the cause. That looks good to me. /Staffan > On 26 jan 2015, at 11:07, Kirk Pepperdine wrote: > > Hi Staffan, > > There are other entry points in diagnosticCommand that will trigger a Full GC. > > void ClassHistogramDCmd::execute(DCmdSource source, TRAPS) { > VM_GC_HeapInspection heapop(output(), > !_all.value() /* request full gc if false */); > VMThread::execute(&heapop); > } > > and > void HeapDumpDCmd::execute(DCmdSource source, TRAPS) { > // Request a full GC before heap dump if _all is false > // This helps reduces the amount of unreachable objects in the dump > // and makes it easier to browse. > HeapDumper dumper(!_all.value() /* request GC if _all is false*/); > int res = dumper.dump(_filename.value()); > if (res == 0) { > output()->print_cr("Heap dump file created"); > } else { > // heap dump failed > ResourceMark rm; > char* error = dumper.error_as_C_string(); > if (error == NULL) { > output()->print_cr("Dump failed - reason unknown"); > } else { > output()->print_cr("%s", error); > } > } > } > > For example. For consistency, how would you suggest these be handled. > > Kind regards, > Kirk Pepperdine > > On Jan 26, 2015, at 9:12 AM, Staffan Larsen > wrote: > >> A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. >> >> Thanks, >> /Staffan >> >>> On 25 jan 2015, at 14:15, Yasumasa Suenaga > wrote: >>> >>> Hi all, >>> >>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >>> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >>> >>> I uploaded webrev for this enhancement: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >>> >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >>> >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yekaterina.kantserova at oracle.com Tue Jan 27 08:28:46 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 27 Jan 2015 09:28:46 +0100 Subject: RFR(XXS): 8071545: Tests are still excluded while the appropriate bug has been fixed Message-ID: <54C74C3E.6010403@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071545 webrev: http://cr.openjdk.java.net/~ykantser/8071545/webrev.00/ Thanks, Katja From serguei.spitsyn at oracle.com Tue Jan 27 08:33:34 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 27 Jan 2015 00:33:34 -0800 Subject: RFR(XXS): 8071545: Tests are still excluded while the appropriate bug has been fixed In-Reply-To: <54C74C3E.6010403@oracle.com> References: <54C74C3E.6010403@oracle.com> Message-ID: <54C74D5E.2070206@oracle.com> Hi Katya, It looks good. Thanks, Serguei On 1/27/15 12:28 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071545 > webrev: http://cr.openjdk.java.net/~ykantser/8071545/webrev.00/ > > Thanks, > Katja From yekaterina.kantserova at oracle.com Tue Jan 27 08:36:00 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 27 Jan 2015 09:36:00 +0100 Subject: RFR(XXS): 8071582: com/sun/jdi/GetLocalVariables4Test.sh should be quarantined Message-ID: <54C74DF0.4030604@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071582 webrev: http://cr.openjdk.java.net/~ykantser/8071582/webrev.00/ Thanks, Katja From yekaterina.kantserova at oracle.com Tue Jan 27 08:37:32 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Tue, 27 Jan 2015 09:37:32 +0100 Subject: RFR(XXS): 8071545: Tests are still excluded while the appropriate bug has been fixed In-Reply-To: <54C74D5E.2070206@oracle.com> References: <54C74C3E.6010403@oracle.com> <54C74D5E.2070206@oracle.com> Message-ID: <54C74E4C.3090709@oracle.com> Thanks, Serguei! On 01/27/2015 09:33 AM, serguei.spitsyn at oracle.com wrote: > Hi Katya, > > It looks good. > > Thanks, > Serguei > > On 1/27/15 12:28 AM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this very small fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8071545 >> webrev: http://cr.openjdk.java.net/~ykantser/8071545/webrev.00/ >> >> Thanks, >> Katja > From serguei.spitsyn at oracle.com Tue Jan 27 09:03:12 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 27 Jan 2015 01:03:12 -0800 Subject: RFR(XXS): 8071582: com/sun/jdi/GetLocalVariables4Test.sh should be quarantined In-Reply-To: <54C74DF0.4030604@oracle.com> References: <54C74DF0.4030604@oracle.com> Message-ID: <54C75450.2080706@oracle.com> Looks good. Thanks, Serguei On 1/27/15 12:36 AM, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071582 > webrev: http://cr.openjdk.java.net/~ykantser/8071582/webrev.00/ > > Thanks, > Katja From yasuenag at gmail.com Tue Jan 27 12:22:36 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 27 Jan 2015 21:22:36 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> Message-ID: <54C7830C.4070904@gmail.com> Hi Staffan, Thank you for your comments. I've uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ I changed as below: - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run - GCCause string: "jcmd GC.run" -> "GC.run DCmd" Could you review it? Thanks, Yasumasa On 2015/01/26 17:12, Staffan Larsen wrote: > A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. > > Thanks, > /Staffan > >> On 25 jan 2015, at 14:15, Yasumasa Suenaga wrote: >> >> Hi all, >> >> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >> >> I uploaded webrev for this enhancement: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >> >> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >> >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa > From daniel.daugherty at oracle.com Tue Jan 27 13:56:31 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Jan 2015 06:56:31 -0700 Subject: RewriteFrequentPairs flag was disabled in debug model(and discussion for fix) In-Reply-To: References: Message-ID: <54C7990F.2030309@oracle.com> Resending to include the Serviceability team since they own JVM/TI... Dan On 1/26/15 11:53 PM, San Hong Li wrote: > HI All: > When the JVM is running in debug model, the RewriteFrequentPairs > optimization will be disabled by following code in > JvmtiManageCapabilities::update(): > > * if (avail.can_generate_breakpoint_events) {* > * RewriteFrequentPairs = false;* > * }* > > *[ pls. check the above code @Line 328 in jvmtiManageCapabilities.cpp in > jdk7 codebase]* > > I understand the reason why the RewriteFrequentPairs doesn't work in debug > model is that the TOS cache will be disturbed after the execution of > TemplateTable::aload_0 in such this case, > > Let us discuss it in more details about what will happen if we enable > RewriteFrequentPairs flag in debugging model... > > > The following code was excerpted from TemplateTable::aload_0 > ( @L789 in templateTable_x86_64.cpp). > For better discussion, I just skipped irrelevant parts: > > *void TemplateTable::aload_0() {* > * transition(vtos, atos);* > > > * if (RewriteFrequentPairs) {* > * ...... * > * // do actual aload_0* > * aload(0); * > * ......* > * // rewrite* > * // bc: fast bytecode* > * __ bind(rewrite);* > * patch_bytecode(Bytecodes::_aload_0, bc, rbx, false);* > * __ bind(done);* > * } else {* > * aload(0);* > * }* > *}* > > In above code: > The *aload(0) *happened before * patch_bytecode. * > The TOS cache will be set correctly after *aload(0) *, that's, the state > should be atos as we have expected. > > But the cache will be corrupted by the following *patch_bytecode > *which actually > calls out to InterpreterRuntime::set_original_bytecode_at: > > Pls. check the implementation around at L256 in templateTable_x86_64.cpp: > > * // Let breakpoint table handling rewrite to quicker bytecode* > * __ call_VM(noreg, CAST_FROM_FN_PTR(address, > InterpreterRuntime::set_original_bytecode_at), temp_reg, r13, bc_reg);* > > The problem here is: > The call out into InterpreterRuntime::set_original_bytecode_at will > eventually change the values cached in RAX. > > I would like to discuss and propose a fix for this issue: just do > the * aload(0) > *after *patch_bytecode!* > (actually similar thing we did in TemplateTable::iload) , > So the updated code with fix likes this: > > *void TemplateTable::aload_0() {* > * transition(vtos, atos);* > > > * if (RewriteFrequentPairs) {* > * ...... * > * // do actual aload_0* > * //aload(0); * > * ......* > * // rewrite* > * // bc: fast bytecode* > * __ bind(rewrite);* > * patch_bytecode(Bytecodes::_aload_0, bc, rbx, false);* > * __ bind(done);* > * } * > * // do actual aload_0* > * __ movptr(rax, aaddress(0)); * > *}* > > So that the TOS has been cached correctly without disruption by > *patch_bytecode, > *safe use for next bytecode. > > Finally, just a summary for my questions: > > Whether or not *this is the only case t*hat explained why the current > implementation of HotSpot has to disable RewriteFrequentPairs flag in > debug mode? > --- If so, how do u think about the fix? I did some tests in my > environment, it works fine. > --- if not, would you pls. point out in which case we also have to > disable RewriteFrequentPairs during debugging? > > Thanks! > San Hong From kirk at kodewerk.com Tue Jan 27 17:00:29 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Jan 2015 18:00:29 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54C7830C.4070904@gmail.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> Message-ID: Hi, On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: > Hi Staffan, > > Thank you for your comments. > > I've uploaded new webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ > > I changed as below: > - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run > - GCCause string: "jcmd GC.run" -> "GC.run DCmd? Can I suggest a shortened GCCause string to ?DiagCmd?. At the very least I?d prefer to not have the ?.? in the string. Regards, Kirk > > > Could you review it? > > > Thanks, > > Yasumasa > > > On 2015/01/26 17:12, Staffan Larsen wrote: >> A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. >> >> Thanks, >> /Staffan >> >>> On 25 jan 2015, at 14:15, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >>> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >>> >>> I uploaded webrev for this enhancement: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >>> >>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >>> >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From shanliang.jiang at oracle.com Tue Jan 27 17:43:06 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Tue, 27 Jan 2015 18:43:06 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans Message-ID: <54C7CE2A.1090700@oracle.com> Hi, Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8065213 webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ The class PlatformMBeanProvider.java is added to allow different modules to inform ManagementFactory of their Plaform MBeans. In this version we use the ServiceLoader to load these Plaform MBeans, later we will replace the ServiceProvider by jigsaw mechanisms. there are 2 providers in this version: DefaultPlatformMBeanProvider: for all MBeans in the java.lang.management.* (java.management module) com/sun/management/internal/PlatformMBeanProviderImpl: for the MBeans in com.sun.management.* com.sun.management.* (jdk.management module) Thanks, Shanliang From staffan.larsen at oracle.com Tue Jan 27 19:37:20 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Jan 2015 20:37:20 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> Message-ID: <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> > On 27 jan 2015, at 18:00, Kirk Pepperdine wrote: > > Hi, > > On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: > >> Hi Staffan, >> >> Thank you for your comments. >> >> I've uploaded new webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ >> >> I changed as below: >> - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run >> - GCCause string: "jcmd GC.run" -> "GC.run DCmd? > > Can I suggest a shortened GCCause string to ?DiagCmd?. At the very least I?d prefer to not have the ?.? in the string. I would have suggested ?GC.run Diagnostic Command?, or ?Diagnostic Command: GC.run?. I don?t know what problems a ?.? causes. ?System.gc()? already has one. /Staffan > > Regards, > Kirk > >> >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2015/01/26 17:12, Staffan Larsen wrote: >>> A bit of terminology here. ?GC.run? is called a ?Diagnostic Command?. ?jcmd? is one way to invoke a Diagnostic Command. Another way is via a JMX MBean. With this in mind I think your references to ?jcmd? should be changed to ?diagnostic command? (or an abbreviation thereof). For example: _jcmd_gc_run -> _dcmd_gc_run. >>> >>> Thanks, >>> /Staffan >>> >>>> On 25 jan 2015, at 14:15, Yasumasa Suenaga wrote: >>>> >>>> Hi all, >>>> >>>> GCCause which is printed in gc log is "System.gc()" when jcmd GC.run is invoked. >>>> I think that GCCause which is caused by jcmd GC.run should be different from System.gc() . >>>> >>>> I uploaded webrev for this enhancement: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.00/ >>>> >>>> This patch prints "jcmd GC.run" to gc log when jcmd GC.run is invoked. >>>> >>>> >>>> Could you review it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> > From kirk at kodewerk.com Tue Jan 27 19:57:08 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Jan 2015 20:57:08 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> Message-ID: <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> On Jan 27, 2015, at 8:37 PM, Staffan Larsen wrote: > >> On 27 jan 2015, at 18:00, Kirk Pepperdine wrote: >> >> Hi, >> >> On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: >> >>> Hi Staffan, >>> >>> Thank you for your comments. >>> >>> I've uploaded new webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ >>> >>> I changed as below: >>> - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run >>> - GCCause string: "jcmd GC.run" -> "GC.run DCmd? >> >> Can I suggest a shortened GCCause string to ?DiagCmd?. At the very least I?d prefer to not have the ?.? in the string. > > I would have suggested ?GC.run Diagnostic Command?, or ?Diagnostic Command: GC.run?. I don?t know what problems a ?.? causes. ?System.gc()? already has one. Indeed it does and it and it has () and really wished neither were there. But unfortunately I missed the change from System to System.gc(). It complicates regex which may not seem like a big deal until you add in the entire GC log picture from 1.6.0 ?til 1.9.0 across all collectors and the possible flag combinations... it only adds (needlessly) to the mess. Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. Kind regards, Kirk Pepperdine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.larsen at oracle.com Tue Jan 27 20:01:39 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Jan 2015 21:01:39 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> Message-ID: <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> > On 27 jan 2015, at 20:57, Kirk Pepperdine wrote: > > > On Jan 27, 2015, at 8:37 PM, Staffan Larsen > wrote: > >> >>> On 27 jan 2015, at 18:00, Kirk Pepperdine wrote: >>> >>> Hi, >>> >>> On Jan 27, 2015, at 1:22 PM, Yasumasa Suenaga wrote: >>> >>>> Hi Staffan, >>>> >>>> Thank you for your comments. >>>> >>>> I've uploaded new webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.01/ >>>> >>>> I changed as below: >>>> - GCCause::_jcmd_gc_run -> GCCause::_dcmd_gc_run >>>> - GCCause string: "jcmd GC.run" -> "GC.run DCmd? >>> >>> Can I suggest a shortened GCCause string to ?DiagCmd?. At the very least I?d prefer to not have the ?.? in the string. >> >> I would have suggested ?GC.run Diagnostic Command?, or ?Diagnostic Command: GC.run?. I don?t know what problems a ?.? causes. ?System.gc()? already has one. > > Indeed it does and it and it has () and really wished neither were there. But unfortunately I missed the change from System to System.gc(). It complicates regex which may not seem like a big deal until you add in the entire GC log picture from 1.6.0 ?til 1.9.0 across all collectors and the possible flag combinations... it only adds (needlessly) to the mess. > > Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. Let?s go with ?Diagnostic Command?, then. /Staffan > > Kind regards, > Kirk Pepperdine -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Tue Jan 27 20:06:46 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 27 Jan 2015 21:06:46 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> Message-ID: <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> Hi Staffan, >> >> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. > > Let?s go with ?Diagnostic Command?, then. Thank you! Regards, Kirk -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From serguei.spitsyn at oracle.com Tue Jan 27 23:57:02 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 27 Jan 2015 15:57:02 -0800 Subject: 5-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54B99838.10601@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> Message-ID: <54C825CE.1030105@oracle.com> This is 5-th round review of for: https://bugs.openjdk.java.net/browse/JDK-8008678 There was one (4-rd) private review discussion. The result is this webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.5/ Summary: Current fix is to use the 2-nd LSB bit in the CPSlot to mark pseudo-strings. A similar version of webrev was already reviewed by Coleen and John. The update is that it includes John's suggestion to introduce the CPSlot::TagBits to make code more clean. Also, I've discovered that there is no need to update the SymbolClosure::load_symbol() in iterator.hpp because the pseudo-string PCSlot is not used in the SymbolClosure. I need a final thumbs up for the push. Testing: Run: - nsk.jvmti.testlist, nsk.jdi.testlist, vm.mlvm.testlist - java/lang/instrument, com/sun/jdi and hotspot/test/runtime tests - new jtreg test (see webrev) that was written by Filipp Zhinkin Thanks, Serguei On 1/16/15 3:01 PM, serguei.spitsyn at oracle.com wrote: > John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. > The updated webrev is going to be close to the .3 webrev. > I will send it soon. > > Thanks, > Serguei > > On 1/16/15 2:53 PM, Coleen Phillimore wrote: >> >> This change looks good to me also. >> Thanks, >> Coleen >> >> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>> >>> >>> Open webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>> >>> >>> Summary: >>> Currently, a JVM_CONSTANT_String CP entry having a NULL reference >>> to Symbol* >>> indicates that it is a pseudo-string (patched string). >>> This creates nasty issues for the constant pool reconstitution. >>> >>> Current suggestion is to avoid having a NULL reference and retain >>> the original >>> Symbol* reference for pseudo-strings. The pseudo-string >>> indication will be >>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>> This approach makes the fix much simpler. >>> >>> I need a confirmation from the Compiler team that this won't >>> break any assumptions or invariants. >>> Big thanks to Coleen for previous round reviews and good advices! >>> >>> >>> Testing: >>> Run: >>> - java/lang/instrument tests >>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> Thank you for reviewing! >>>> >>>> >>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Thank you for making the patches an optional field. >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>> 198 if (!patched()) { >>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>> 200 return 0; >>>>> 201 } >>>>> Why not >>>>> assert(patched(), "a pseud-string map must exist >>>>> for patched CP only"); >>>> >>>> Wanted it to be more reliable but it looks pointless. >>>> Will make this change. >>>> >>>>> >>>>> >>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>> false? >>>>> >>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>> >>>> >>>> A typo, must be false. >>>> It is the last minute change. >>>> Thanks for the catch! >>>> >>>> >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>> >>>>> Don't you have to move the value of the patched field from the old >>>>> constant pool to the new one? I hate to ask but is there merging >>>>> that needs to be done? I don't know how to write this test case >>>>> though. Is it possible to redefine a class with a constant pool >>>>> patches with another that has constant pool patches? >>>> >>>> Thank you for asking this question. >>>> If I understand correctly, the patching comes from the compiler >>>> side for anonymous classes only. >>>> I saw it for LambdaForm's only. >>>> I think, the patching can not be changed with a retransformation. >>>> But I'm not sure if it can not be changed with a redefinition. >>>> >>>> But if it can - then it would be safe to merge the 'patched' >>>> condition, i.e. make it patched >>>> if either the_class or scratch class is patched. >>>> >>>>> >>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>> oops passed in. >>>>> >>>>> So I was wondering why you can't change this instead: >>>>> >>>>> bool is_pseudo_string_at(int which) { >>>>> // A pseudo string is a string that doesn't have a symbol in >>>>> the cpSlot >>>>> - return unresolved_string_at(which) == NULL; >>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>> } >>>> >>>> I was thinking about the same but was not sure if it would work for >>>> the compiler team. >>>> We have to ask John about this (added John and Christian to the >>>> cc-list). >>>> This question to John was in my plan! :) >>>> >>>> The beauty of the above approach is that there is no need to create >>>> an intermediate >>>> pseudo-string map and most of the code in from this webrev is not >>>> needed. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> And the asserts in the other functions below it. >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the second round fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>> >>>>>> Open webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> This fix implements a footprint saving approach suggested by >>>>>> Coleen. >>>>>> To be able to reconstitute a class constant pool, an >>>>>> intermediate pseudo-string map is used. >>>>>> Now, this field is accounted optionally, only if the >>>>>> 'cp_patches' is provided in the >>>>>> ClassFileParser::parseClassFile() before ConstantPool is allocated. >>>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>>> only way I see so far. >>>>>> >>>>>> Unfortunately, this approach did not help much to make some >>>>>> other fields (eg., 'operands') optional. >>>>>> The problem is that we have to account optional fields before >>>>>> parsing, at the CP allocation time. >>>>>> It is possible to re-allocate the ConstantPool when any >>>>>> InvokeDynamic bytecode is discovered, >>>>>> but it looks too complicated. >>>>>> >>>>>> Testing: >>>>>> - the unit test from bug report >>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Coleen, >>>>>>> >>>>>>> Thank you for looking at this! >>>>>>> I'll check how this can be improved. >>>>>>> It is my concern too. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>> >>>>>>>> Serguei, >>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>>> all classes pay in footprint for this field? The same thing >>>>>>>> probably could be done for operands too. There are flags that >>>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>>> function. >>>>>>>> >>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>> it's worth doing in this case. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review the fix for: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>> >>>>>>>>> >>>>>>>>> Open webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>> reconstitution of constant pool. >>>>>>>>> >>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>> pseudo-strings are: >>>>>>>>> >>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>> constant pool of bytecodes which >>>>>>>>> implement some method handles. We use the anonymous class >>>>>>>>> pseudo-string feature for that. >>>>>>>>> The relevant code is here: >>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>> >>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>> The odd name refers to the fact that, even though they are >>>>>>>>> random oops, they appear in the constant pool >>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>> find a string." >>>>>>>>> ... >>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>> anonymous class, and >>>>>>>>> if that class has oop patching (pseudo-strings), you would >>>>>>>>> need either to (a) reconstitute the patches array >>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>> >>>>>>>>> >>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>> >>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>> that does not have >>>>>>>>> a reference to the string symbol anymore: >>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>> >>>>>>>>> The fix is to create and fill in a map from >>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>> to be able to restore this assotiation in the >>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> Run: >>>>>>>>> - java/lang/instrument tests >>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>> Zhinkin >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Jan 28 04:48:22 2015 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 28 Jan 2015 13:48:22 +0900 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> Message-ID: <54C86A16.8070200@gmail.com> Hi Staffan, Kirk, I agree to set "Diagnostic Command" to GCCause. So I applied it to new patch. http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ Could you review it again? Thanks, Yasumasa On 2015/01/28 5:06, Kirk Pepperdine wrote: > Hi Staffan, > >>> >>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. >> >> Let?s go with ?Diagnostic Command?, then. > > Thank you! > > Regards, > Kirk > From mandy.chung at oracle.com Wed Jan 28 06:46:51 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Jan 2015 22:46:51 -0800 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C7CE2A.1090700@oracle.com> References: <54C7CE2A.1090700@oracle.com> Message-ID: <54C885DB.50304@oracle.com> On 1/27/2015 9:43 AM, shanliang wrote: > Hi, > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8065213 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ > > The class PlatformMBeanProvider.java is added to allow different > modules to inform ManagementFactory of their Plaform MBeans. In this > version we use the ServiceLoader to load these Plaform MBeans, later > we will replace the ServiceProvider by jigsaw mechanisms. > Thanks for taking on this one. This is the first step toward separating com.sun.management API from java.management module as Java SE module must only export Java SE API per the principles described in JEP 200. This patch separates the standard java.lang.management and JDK-specific MBeans to be provided by two different providers. The next task is to separate the com.sun.management API and its implementation from java.management into a different module (e.g. jdk.management). This will enable java.lang.management to work with and without jdk.management (JDK-specific MBeans) when the module system moves further along. > there are 2 providers in this version: > DefaultPlatformMBeanProvider: for all MBeans in the > java.lang.management.* (java.management module) > com/sun/management/internal/PlatformMBeanProviderImpl: for the > MBeans in com.sun.management.* com.sun.management.* (jdk.management > module) This looks right. The patch looks okay and the ManagementFactory change using service providers is quite clean. Review comments: ManagementFactory.java line 760: would be helpful to add some comments describing that the implementation of this method. You can use MemoryManagerMXBean and GarageCollectorMXBean as the example. Comments for the addProxyNames line 867: it would be more readable if you break this into two statements. List providers = AccessController.doPrivileged(...); providers.stream() .forEachOrdered(...); line 875-886: worths formatting line 885 - instead of creating a HashMap and put entry in the forEach call. You could have do: .collect(toMap(PlatformComponent::getObjectNamePattern, Function.identity()) You could also have the getMap() be called to initialize the componentMap static field (i.e. initialize it in the static initializer rather than lazily so the providers must be loaded anyway. Can you add comments for the PlatformMBeanFinder methods? com/sun/management/internal/PlatformMBeanProviderImpl.java line 43: does this mxbeanList have to be created lazily? Would it be better to make it a final field and create it at the constructor? line 58-59, 66-67, 111-112, 118-119: nit formatting java/lang/management/DefaultPlatformMBeanProvider.java line 42: should this mxbeanList be a final field? you can replace java.lang.management.MemoryManagerMXBean.class with MemoryManagerMXBean.class as it's in the same package. Same apply to other java.lang.management classes. Some formatting nit like mentioned above. Thanks Mandy From david.holmes at oracle.com Wed Jan 28 07:24:31 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Jan 2015 17:24:31 +1000 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54BFA432.10500@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> Message-ID: <54C88EAF.2060604@oracle.com> Hi Dmitry, Sorry this slipped through the cracks. On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: > David, > > Please, take a look at updated webrev > > http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. Don't you need to execute the END_WITH_LOCAL_REFS before you can return? Otherwise seems okay. Thanks, David > -Dmitry > > > On 2014-10-16 16:07, David Holmes wrote: >> Hi Dmitry, >> >> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>> David, >>> >>> Changed. Thank you for review! >>> >>> please, see: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >> >> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >> >> Isn't the only time it will return NULL when an exception occurs? >> Conversely if an exception occurs then it must return NULL - so the >> exception check seems redundant. >> >> But this also suggests you need similar logic at: >> >> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, node->ref); >> >> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, node->ref); >> >> Or more generally any JNI call from JVMTI should be wrapped in a way >> that checks for exceptions and clears them. >> >> David >> >>> -Dmitry >>> >>> On 2014-10-16 04:24, David Holmes wrote: >>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>> Sorry, copied wrong function! >>>>> >>>>> I mean this call >>>>> >>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>> >>>>> that can post OutOfMemoryError >>>> >>>> Okay, so shouldn't that be where the exception is cleared: >>>> >>>> /* Create weak reference to make sure we have a reference */ >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> if (weakRef == NULL) { >>>> + // < clear exception here > >>>> jvmtiDeallocate(node); >>>> return NULL; >>>> } >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> commonRef_refToID() -> >>>>> >>>>> createNode(JNIEnv *env, jobject ref) -> >>>>> >>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>> Please review the fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>> >>>>>>>>> Added missed exception checks. >>>>>>>> >>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>> >>>>>>>> What is potentially posting the exception? >>>>>>> >>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>> commonRef_refToID() >>>>>> >>>>>> You mean this call: >>>>>> >>>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>> &tag); >>>>> >>>>> x >>>>>> >>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI doesn't >>>>>> post exceptions. >>>>>> >>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>> communicated via the function return value. Any existing exception >>>>>> state >>>>>> is preserved across a call to a JVM TI function." >>>>>> >>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From staffan.larsen at oracle.com Wed Jan 28 08:13:45 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Jan 2015 09:13:45 +0100 Subject: RFR(XXS): 8071545: Tests are still excluded while the appropriate bug has been fixed In-Reply-To: <54C74C3E.6010403@oracle.com> References: <54C74C3E.6010403@oracle.com> Message-ID: <807237E9-4B12-4841-BCD5-1A1A4471EBCE@oracle.com> Looks good! Thanks, /Staffan > On 27 jan 2015, at 09:28, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071545 > webrev: http://cr.openjdk.java.net/~ykantser/8071545/webrev.00/ > > Thanks, > Katja From staffan.larsen at oracle.com Wed Jan 28 08:24:22 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Jan 2015 09:24:22 +0100 Subject: RFR: JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() In-Reply-To: <54C86A16.8070200@gmail.com> References: <54C4EC7F.2010509@gmail.com> <5706393E-9EE7-4218-970E-B115D32CF9B6@oracle.com> <54C7830C.4070904@gmail.com> <61C1BF02-F9A9-431B-BC5F-09CC3D8E79A9@oracle.com> <3D93E8F0-B14F-4B72-9C91-E37D0FC9072E@kodewerk.com> <4CF3A4E6-0FCC-4561-BDC7-78F15797EA82@oracle.com> <2B64EE96-7563-4901-B8FA-89BF6BE11904@kodewerk.com> <54C86A16.8070200@gmail.com> Message-ID: <0EC87621-A69D-453E-B0AC-8EB892D3B3CE@oracle.com> Looks good! Thanks, /Staffan > On 28 jan 2015, at 05:48, Yasumasa Suenaga wrote: > > Hi Staffan, Kirk, > > I agree to set "Diagnostic Command" to GCCause. > So I applied it to new patch. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8068589/webrev.02/ > > Could you review it again? > > > Thanks, > > Yasumasa > > > On 2015/01/28 5:06, Kirk Pepperdine wrote: >> Hi Staffan, >> >>>> >>>> Anyway, it?s a record in a GC log so I don?t see the value of GC.run. Certainly ?DiagCmd" or even "Diagnostic Command? seems sufficient given the context. >>> >>> Let?s go with ?Diagnostic Command?, then. >> >> Thank you! >> >> Regards, >> Kirk >> From mattias.tobiasson at oracle.com Wed Jan 28 10:31:33 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 28 Jan 2015 11:31:33 +0100 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start Message-ID: <54C8BA85.3050305@oracle.com> Hi, Could I please have a review of this test bug fix. bug: https://bugs.openjdk.java.net/browse/JDK-8068613 webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.01 On line 90 and on line 246 (in the old version) the test does a short wait between Runtime.getRuntime().runFinalization() and MemoryMXBean.getObjectPendingFinalizationCount() The test expects getObjectPendingFinalizationCount() to return 0, but that sometimes fails on really slow servers. The fix will loop until getObjectPendingFinalizationCount() returns 0, or until it gives up after 100 tries. Thanks, Mattias From staffan.larsen at oracle.com Wed Jan 28 10:38:56 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Jan 2015 11:38:56 +0100 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start In-Reply-To: <54C8BA85.3050305@oracle.com> References: <54C8BA85.3050305@oracle.com> Message-ID: <37EACAA4-0992-479E-8EB5-0873CD3872A7@oracle.com> Looks good! How much testing have you done? Thanks, /Staffan > On 28 jan 2015, at 11:31, Mattias Tobiasson wrote: > > Hi, > Could I please have a review of this test bug fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8068613 > webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.01 > > On line 90 and on line 246 (in the old version) the test does a short wait between > Runtime.getRuntime().runFinalization() and > MemoryMXBean.getObjectPendingFinalizationCount() > > The test expects getObjectPendingFinalizationCount() to return 0, > but that sometimes fails on really slow servers. > > The fix will loop until getObjectPendingFinalizationCount() returns 0, > or until it gives up after 100 tries. > > Thanks, > Mattias > From daniel.fuchs at oracle.com Wed Jan 28 10:44:35 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 28 Jan 2015 11:44:35 +0100 Subject: jmx-dev RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C7CE2A.1090700@oracle.com> References: <54C7CE2A.1090700@oracle.com> Message-ID: <54C8BD93.8090605@oracle.com> Hi Shanliang, This looks good. ManagementFactory.java: line 871: there's a stray debug trace that you probably forgot to remove: 871 System.out.println("\n\n===== jsl adding: "+provider); lines 877-885: I believe it would improved readability if the content of the forEachOrdered statement was factored out in a private static method. Something like: .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) private static void addToComponentMap( Map> cmpMap, PlatformMBeanProvider provider) { provider.getPlatformComponentList().stream() .collect(toMap(p -> p.getObjectNamePattern(), p -> p, (p1, p2) -> { throw new InternalError(p1.getObjectNamePattern() + " has been used as key for " + p1 + ", it cannot be reused for " + p2); })) .values() .stream() // put all components into a map, "putIfAbsent" .forEach(p -> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); } PlatformMBeanProviderImpl.java: 105 * 3 OperatingSystemMXBean Not sure what '3' means here - I suggest to remove it. best regards, -- daniel On 27/01/15 18:43, shanliang wrote: > Hi, > > Please review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8065213 > webrev: http://cr.openjdk.java.net/~sjiang/JDK-8065213/00/ > > The class PlatformMBeanProvider.java is added to allow different modules > to inform ManagementFactory of their Plaform MBeans. In this version we > use the ServiceLoader to load these Plaform MBeans, later we will > replace the ServiceProvider by jigsaw mechanisms. > > there are 2 providers in this version: > DefaultPlatformMBeanProvider: for all MBeans in the > java.lang.management.* (java.management module) > com/sun/management/internal/PlatformMBeanProviderImpl: for the > MBeans in com.sun.management.* com.sun.management.* (jdk.management module) > > Thanks, > Shanliang > > > From mattias.tobiasson at oracle.com Wed Jan 28 12:37:04 2015 From: mattias.tobiasson at oracle.com (Mattias Tobiasson) Date: Wed, 28 Jan 2015 13:37:04 +0100 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start In-Reply-To: <37EACAA4-0992-479E-8EB5-0873CD3872A7@oracle.com> References: <54C8BA85.3050305@oracle.com> <37EACAA4-0992-479E-8EB5-0873CD3872A7@oracle.com> Message-ID: <54C8D7F0.4050600@oracle.com> I have tested 200 times on linux, and once on all other platforms (except embedded). On 01/28/2015 11:38 AM, Staffan Larsen wrote: > Looks good! How much testing have you done? > > Thanks, > /Staffan > >> On 28 jan 2015, at 11:31, Mattias Tobiasson wrote: >> >> Hi, >> Could I please have a review of this test bug fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8068613 >> webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.01 >> >> On line 90 and on line 246 (in the old version) the test does a short wait between >> Runtime.getRuntime().runFinalization() and >> MemoryMXBean.getObjectPendingFinalizationCount() >> >> The test expects getObjectPendingFinalizationCount() to return 0, >> but that sometimes fails on really slow servers. >> >> The fix will loop until getObjectPendingFinalizationCount() returns 0, >> or until it gives up after 100 tries. >> >> Thanks, >> Mattias >> From staffan.larsen at oracle.com Wed Jan 28 12:59:26 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Jan 2015 13:59:26 +0100 Subject: RFR(S): 8068613: Wrong number of objects pending finalization start In-Reply-To: <54C8D7F0.4050600@oracle.com> References: <54C8BA85.3050305@oracle.com> <37EACAA4-0992-479E-8EB5-0873CD3872A7@oracle.com> <54C8D7F0.4050600@oracle.com> Message-ID: Sounds good to me. /Staffan > On 28 jan 2015, at 13:37, Mattias Tobiasson wrote: > > I have tested 200 times on linux, and once on all other platforms (except embedded). > > On 01/28/2015 11:38 AM, Staffan Larsen wrote: >> Looks good! How much testing have you done? >> >> Thanks, >> /Staffan >> >>> On 28 jan 2015, at 11:31, Mattias Tobiasson wrote: >>> >>> Hi, >>> Could I please have a review of this test bug fix. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8068613 >>> webrev: http://cr.openjdk.java.net/~ykantser/8068613/webrev.01 >>> >>> On line 90 and on line 246 (in the old version) the test does a short wait between >>> Runtime.getRuntime().runFinalization() and >>> MemoryMXBean.getObjectPendingFinalizationCount() >>> >>> The test expects getObjectPendingFinalizationCount() to return 0, >>> but that sometimes fails on really slow servers. >>> >>> The fix will loop until getObjectPendingFinalizationCount() returns 0, >>> or until it gives up after 100 tries. >>> >>> Thanks, >>> Mattias >>> > From dmitry.samersoff at oracle.com Wed Jan 28 14:00:14 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 28 Jan 2015 17:00:14 +0300 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C88EAF.2060604@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> <54C88EAF.2060604@oracle.com> Message-ID: <54C8EB6E.5020301@oracle.com> David, > Don't you need to execute the END_WITH_LOCAL_REFS before you can return? done. http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ -Dmitry On 2015-01-28 10:24, David Holmes wrote: > Hi Dmitry, > > Sorry this slipped through the cracks. > > On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: >> David, >> >> Please, take a look at updated webrev >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ > > src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. > > Don't you need to execute the END_WITH_LOCAL_REFS before you can return? > > Otherwise seems okay. > > Thanks, > David > >> -Dmitry >> >> >> On 2014-10-16 16:07, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Changed. Thank you for review! >>>> >>>> please, see: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>> >>> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >>> >>> Isn't the only time it will return NULL when an exception occurs? >>> Conversely if an exception occurs then it must return NULL - so the >>> exception check seems redundant. >>> >>> But this also suggests you need similar logic at: >>> >>> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, >>> node->ref); >>> >>> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, >>> node->ref); >>> >>> Or more generally any JNI call from JVMTI should be wrapped in a way >>> that checks for exceptions and clears them. >>> >>> David >>> >>>> -Dmitry >>>> >>>> On 2014-10-16 04:24, David Holmes wrote: >>>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>>> David, >>>>>> >>>>>> Sorry, copied wrong function! >>>>>> >>>>>> I mean this call >>>>>> >>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>> >>>>>> that can post OutOfMemoryError >>>>> >>>>> Okay, so shouldn't that be where the exception is cleared: >>>>> >>>>> /* Create weak reference to make sure we have a reference */ >>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>> if (weakRef == NULL) { >>>>> + // < clear exception here > >>>>> jvmtiDeallocate(node); >>>>> return NULL; >>>>> } >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> commonRef_refToID() -> >>>>>> >>>>>> createNode(JNIEnv *env, jobject ref) -> >>>>>> >>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>>> Please review the fix: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>>> >>>>>>>>>> Added missed exception checks. >>>>>>>>> >>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>>> >>>>>>>>> What is potentially posting the exception? >>>>>>>> >>>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>>> commonRef_refToID() >>>>>>> >>>>>>> You mean this call: >>>>>>> >>>>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>>> &tag); >>>>>> >>>>>> x >>>>>>> >>>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI >>>>>>> doesn't >>>>>>> post exceptions. >>>>>>> >>>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>>> communicated via the function return value. Any existing exception >>>>>>> state >>>>>>> is preserved across a call to a JVM TI function." >>>>>>> >>>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> -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 coleen.phillimore at oracle.com Wed Jan 28 14:28:15 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 28 Jan 2015 09:28:15 -0500 Subject: 5-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54C825CE.1030105@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54C825CE.1030105@oracle.com> Message-ID: <54C8F1FF.3050301@oracle.com> Yes, this looks great. Ship it! Coleen On 1/27/15, 6:57 PM, serguei.spitsyn at oracle.com wrote: > This is 5-th round review of for: > https://bugs.openjdk.java.net/browse/JDK-8008678 > > There was one (4-rd) private review discussion. The result is this webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.5/ > > > Summary: > Current fix is to use the 2-nd LSB bit in the CPSlot to mark > pseudo-strings. > A similar version of webrev was already reviewed by Coleen and John. > The update is that it includes John's suggestion to introduce the > CPSlot::TagBits to make code more clean. > Also, I've discovered that there is no need to update the > SymbolClosure::load_symbol() in iterator.hpp > because the pseudo-string PCSlot is not used in the SymbolClosure. > I need a final thumbs up for the push. > > Testing: > Run: > - nsk.jvmti.testlist, nsk.jdi.testlist, vm.mlvm.testlist > - java/lang/instrument, com/sun/jdi and hotspot/test/runtime tests > - new jtreg test (see webrev) that was written by Filipp Zhinkin > > > Thanks, > Serguei > > On 1/16/15 3:01 PM, serguei.spitsyn at oracle.com wrote: >> John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. >> The updated webrev is going to be close to the .3 webrev. >> I will send it soon. >> >> Thanks, >> Serguei >> >> On 1/16/15 2:53 PM, Coleen Phillimore wrote: >>> >>> This change looks good to me also. >>> Thanks, >>> Coleen >>> >>> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>> >>>> >>>> Open webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>>> >>>> >>>> Summary: >>>> Currently, a JVM_CONSTANT_String CP entry having a NULL >>>> reference to Symbol* >>>> indicates that it is a pseudo-string (patched string). >>>> This creates nasty issues for the constant pool reconstitution. >>>> >>>> Current suggestion is to avoid having a NULL reference and >>>> retain the original >>>> Symbol* reference for pseudo-strings. The pseudo-string >>>> indication will be >>>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>>> This approach makes the fix much simpler. >>>> >>>> I need a confirmation from the Compiler team that this won't >>>> break any assumptions or invariants. >>>> Big thanks to Coleen for previous round reviews and good advices! >>>> >>>> >>>> Testing: >>>> Run: >>>> - java/lang/instrument tests >>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Coleen, >>>>> >>>>> Thank you for reviewing! >>>>> >>>>> >>>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for making the patches an optional field. >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>>> 198 if (!patched()) { >>>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>>> 200 return 0; >>>>>> 201 } >>>>>> Why not >>>>>> assert(patched(), "a pseud-string map must exist >>>>>> for patched CP only"); >>>>> >>>>> Wanted it to be more reliable but it looks pointless. >>>>> Will make this change. >>>>> >>>>>> >>>>>> >>>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>>> false? >>>>>> >>>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>>> >>>>> >>>>> A typo, must be false. >>>>> It is the last minute change. >>>>> Thanks for the catch! >>>>> >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>>> >>>>>> Don't you have to move the value of the patched field from the >>>>>> old constant pool to the new one? I hate to ask but is there >>>>>> merging that needs to be done? I don't know how to write this >>>>>> test case though. Is it possible to redefine a class with a >>>>>> constant pool patches with another that has constant pool patches? >>>>> >>>>> Thank you for asking this question. >>>>> If I understand correctly, the patching comes from the compiler >>>>> side for anonymous classes only. >>>>> I saw it for LambdaForm's only. >>>>> I think, the patching can not be changed with a retransformation. >>>>> But I'm not sure if it can not be changed with a redefinition. >>>>> >>>>> But if it can - then it would be safe to merge the 'patched' >>>>> condition, i.e. make it patched >>>>> if either the_class or scratch class is patched. >>>>> >>>>>> >>>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>>> oops passed in. >>>>>> >>>>>> So I was wondering why you can't change this instead: >>>>>> >>>>>> bool is_pseudo_string_at(int which) { >>>>>> // A pseudo string is a string that doesn't have a symbol in >>>>>> the cpSlot >>>>>> - return unresolved_string_at(which) == NULL; >>>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>>> } >>>>> >>>>> I was thinking about the same but was not sure if it would work >>>>> for the compiler team. >>>>> We have to ask John about this (added John and Christian to the >>>>> cc-list). >>>>> This question to John was in my plan! :) >>>>> >>>>> The beauty of the above approach is that there is no need to >>>>> create an intermediate >>>>> pseudo-string map and most of the code in from this webrev is not >>>>> needed. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> And the asserts in the other functions below it. >>>>>> >>>>>> Coleen >>>>>> >>>>>> >>>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the second round fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> This fix implements a footprint saving approach suggested by >>>>>>> Coleen. >>>>>>> To be able to reconstitute a class constant pool, an >>>>>>> intermediate pseudo-string map is used. >>>>>>> Now, this field is accounted optionally, only if the >>>>>>> 'cp_patches' is provided in the >>>>>>> ClassFileParser::parseClassFile() before ConstantPool is >>>>>>> allocated. >>>>>>> This fix is not elegant, even a little bit ugly, but it is the >>>>>>> only way I see so far. >>>>>>> >>>>>>> Unfortunately, this approach did not help much to make some >>>>>>> other fields (eg., 'operands') optional. >>>>>>> The problem is that we have to account optional fields before >>>>>>> parsing, at the CP allocation time. >>>>>>> It is possible to re-allocate the ConstantPool when any >>>>>>> InvokeDynamic bytecode is discovered, >>>>>>> but it looks too complicated. >>>>>>> >>>>>>> Testing: >>>>>>> - the unit test from bug report >>>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG java/lang/instrument >>>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Coleen, >>>>>>>> >>>>>>>> Thank you for looking at this! >>>>>>>> I'll check how this can be improved. >>>>>>>> It is my concern too. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>>> >>>>>>>>> Serguei, >>>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>>> the pseudo_string_map conditional in ConstantPool and not make >>>>>>>>> all classes pay in footprint for this field? The same thing >>>>>>>>> probably could be done for operands too. There are flags that >>>>>>>>> you can set to conditionally add a pointer to base() in this >>>>>>>>> function. >>>>>>>>> >>>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>>> it's worth doing in this case. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review the fix for: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Open webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>>> reconstitution of constant pool. >>>>>>>>>> >>>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>>> pseudo-strings are: >>>>>>>>>> >>>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>>> constant pool of bytecodes which >>>>>>>>>> implement some method handles. We use the anonymous class >>>>>>>>>> pseudo-string feature for that. >>>>>>>>>> The relevant code is here: >>>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>>> >>>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>>> The odd name refers to the fact that, even though they >>>>>>>>>> are random oops, they appear in the constant pool >>>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>>> find a string." >>>>>>>>>> ... >>>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>>> anonymous class, and >>>>>>>>>> if that class has oop patching (pseudo-strings), you >>>>>>>>>> would need either to (a) reconstitute the patches array >>>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>>> >>>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>>> that does not have >>>>>>>>>> a reference to the string symbol anymore: >>>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>>> >>>>>>>>>> The fix is to create and fill in a map from >>>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>>> to be able to restore this assotiation in the >>>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> Run: >>>>>>>>>> - java/lang/instrument tests >>>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>>> Zhinkin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Wed Jan 28 16:24:59 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Wed, 28 Jan 2015 08:24:59 -0800 (PST) Subject: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar Message-ID: Hi, Could you, please, review the fix below. bug: https://bugs.openjdk.java.net/browse/JDK-8071464 webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8071464/webrev.01/ References to the jre layout are removed from ShellScaffold.sh and DemoRun.java. Other files mentioned in the CR have not been changed as they don't contain any JRE-related artifacts anymore. Thanks, Alex From kevin.walls at oracle.com Wed Jan 28 17:34:43 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 28 Jan 2015 17:34:43 +0000 Subject: RFR(S) (8u): 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54B95862.4020305@oracle.com> References: <54B95862.4020305@oracle.com> Message-ID: <54C91DB3.5000609@oracle.com> Hi, I'd like a sanity check review for backporting this from latest/9 to jdk8u. It's changing os:free to delete. In 8u the same change is relevant, the changeset does not import directly as we have to remove an (unnecessary) NMT parameter (which gets removed by 8060074 in jdk9). Thanks Kevin diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp @@ -68,11 +68,11 @@ ~JvmtiConstantPoolReconstituter() { if (_symmap != NULL) { - os::free(_symmap, mtClass); + delete _symmap; _symmap = NULL; } if (_classmap != NULL) { - os::free(_classmap, mtClass); + delete _classmap; _classmap = NULL; } } -------- Forwarded Message -------- Subject: Re: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool Date: Fri, 16 Jan 2015 18:28:50 +0000 From: Kevin Walls Organization: Oracle Corporation To: daniel.daugherty at oracle.com, Mattis Castegren CC: serviceability-dev at openjdk.java.net Thanks Serguei, thanks Dan! On 16/01/2015 17:51, Daniel D. Daugherty wrote: > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > > These lines allocate: > > line 59: _symmap = new SymbolHashMap(); > line 60: _classmap = new SymbolHashMap(); > > and these lines free incorrectly: > > line 71: os::free(_symmap); > line 75: os::free(_classmap); > > so the proposed fix looks good! > > > Dan > > > On 1/16/15 3:17 AM, Mattis Castegren wrote: >> Hi >> >> This bug is targeted for 7u80, with rdp2 next Tuesday. It would be >> great to get a review for this fix as soon as possible, so that we >> can get this fix out in the last public JDK 7 release. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kevin Walls >> Sent: den 15 januari 2015 15:18 >> To:serviceability-dev at openjdk.java.net >> Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool >> >> Hi, >> >> This is a review request for a change in JVMTI, where we os::free() some >> objects where we should delete them. The problem was logged against 7, >> though it exists up to the present day, below is a diff in current >> latesthttp://hg.openjdk.java.net/jdk9/hs-rt/hotspot >> >> >> Testing: >> I've used a native JVMTI agent to call GetConstantPool() during an >> object allocation callback. Memory usage does appear less after the >> change, it can be 5-6MB in a trivial testcase with a small number of >> allocations monitored, each inoking GetConstantlPool(). >> >> (In my test agent the GetConstantPool() call returns a JVMTI error 101 >> after a fairly short time and a relatively small number of allocations >> are monitored.) >> >> If this is OK to submit without testcase that's great. I don't see >> other examples of native agents in the standard hotspot tests. >> >> bug >>https://bugs.openjdk.java.net/browse/JDK-8035938 >> >> diff: >> $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> @@ -68,11 +68,11 @@ >> >> ~JvmtiConstantPoolReconstituter() { >> if (_symmap != NULL) { >> - os::free(_symmap); >> + delete _symmap; >> _symmap = NULL; >> } >> if (_classmap != NULL) { >> - os::free(_classmap); >> + delete _classmap; >> _classmap = NULL; >> } >> } >> >> >> >> Thanks >> Kevin >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Jan 28 17:45:22 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 28 Jan 2015 10:45:22 -0700 Subject: RFR(S) (8u): 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54C91DB3.5000609@oracle.com> References: <54B95862.4020305@oracle.com> <54C91DB3.5000609@oracle.com> Message-ID: <54C92032.3040007@oracle.com> src/share/vm/prims/jvmtiClassFileReconstituter.hpp No comments. Thumbs up. Dan On 1/28/15 10:34 AM, Kevin Walls wrote: > Hi, > > I'd like a sanity check review for backporting this from latest/9 to > jdk8u. It's changing os:free to delete. > > In 8u the same change is relevant, the changeset does not import > directly as we have to remove an (unnecessary) NMT parameter (which > gets removed by 8060074 in jdk9). > > Thanks > Kevin > > diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > @@ -68,11 +68,11 @@ > > ~JvmtiConstantPoolReconstituter() { > if (_symmap != NULL) { > - os::free(_symmap, mtClass); > + delete _symmap; > _symmap = NULL; > } > if (_classmap != NULL) { > - os::free(_classmap, mtClass); > + delete _classmap; > _classmap = NULL; > } > } > > > > -------- Forwarded Message -------- > Subject: Re: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > Date: Fri, 16 Jan 2015 18:28:50 +0000 > From: Kevin Walls > Organization: Oracle Corporation > To: daniel.daugherty at oracle.com, Mattis Castegren > > CC: serviceability-dev at openjdk.java.net > > > > Thanks Serguei, thanks Dan! > > > On 16/01/2015 17:51, Daniel D. Daugherty wrote: > > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > > > > These lines allocate: > > > > line 59: _symmap = new SymbolHashMap(); > > line 60: _classmap = new SymbolHashMap(); > > > > and these lines free incorrectly: > > > > line 71: os::free(_symmap); > > line 75: os::free(_classmap); > > > > so the proposed fix looks good! > > > > > > Dan > > > > > > On 1/16/15 3:17 AM, Mattis Castegren wrote: > >> Hi > >> > >> This bug is targeted for 7u80, with rdp2 next Tuesday. It would be > >> great to get a review for this fix as soon as possible, so that we > >> can get this fix out in the last public JDK 7 release. > >> > >> Kind Regards > >> /Mattis > >> > >> -----Original Message----- > >> From: Kevin Walls > >> Sent: den 15 januari 2015 15:18 > >> To:serviceability-dev at openjdk.java.net > >> Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > >> > >> Hi, > >> > >> This is a review request for a change in JVMTI, where we os::free() some > >> objects where we should delete them. The problem was logged against 7, > >> though it exists up to the present day, below is a diff in current > >> latesthttp://hg.openjdk.java.net/jdk9/hs-rt/hotspot > >> > >> > >> Testing: > >> I've used a native JVMTI agent to call GetConstantPool() during an > >> object allocation callback. Memory usage does appear less after the > >> change, it can be 5-6MB in a trivial testcase with a small number of > >> allocations monitored, each inoking GetConstantlPool(). > >> > >> (In my test agent the GetConstantPool() call returns a JVMTI error 101 > >> after a fairly short time and a relatively small number of allocations > >> are monitored.) > >> > >> If this is OK to submit without testcase that's great. I don't see > >> other examples of native agents in the standard hotspot tests. > >> > >> bug > >>https://bugs.openjdk.java.net/browse/JDK-8035938 > >> > >> diff: > >> $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> @@ -68,11 +68,11 @@ > >> > >> ~JvmtiConstantPoolReconstituter() { > >> if (_symmap != NULL) { > >> - os::free(_symmap); > >> + delete _symmap; > >> _symmap = NULL; > >> } > >> if (_classmap != NULL) { > >> - os::free(_classmap); > >> + delete _classmap; > >> _classmap = NULL; > >> } > >> } > >> > >> > >> > >> Thanks > >> Kevin > >> > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jan 28 18:57:23 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 28 Jan 2015 10:57:23 -0800 Subject: 5-rd round RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings In-Reply-To: <54C8F1FF.3050301@oracle.com> References: <5475968C.40800@oracle.com> <54760B40.9040206@oracle.com> <54762FC9.2010800@oracle.com> <5491BCB9.10505@oracle.com> <5493299F.60005@oracle.com> <54934E73.4080808@oracle.com> <54B96F97.5070204@oracle.com> <54B99682.8070802@oracle.com> <54B99838.10601@oracle.com> <54C825CE.1030105@oracle.com> <54C8F1FF.3050301@oracle.com> Message-ID: <54C93113.7000308@oracle.com> Thank you, Coleen! Serguei On 1/28/15 6:28 AM, Coleen Phillimore wrote: > > Yes, this looks great. Ship it! > Coleen > > On 1/27/15, 6:57 PM, serguei.spitsyn at oracle.com wrote: >> This is 5-th round review of for: >> https://bugs.openjdk.java.net/browse/JDK-8008678 >> >> There was one (4-rd) private review discussion. The result is this >> webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.5/ >> >> >> Summary: >> Current fix is to use the 2-nd LSB bit in the CPSlot to mark >> pseudo-strings. >> A similar version of webrev was already reviewed by Coleen and John. >> The update is that it includes John's suggestion to introduce the >> CPSlot::TagBits to make code more clean. >> Also, I've discovered that there is no need to update the >> SymbolClosure::load_symbol() in iterator.hpp >> because the pseudo-string PCSlot is not used in the SymbolClosure. >> I need a final thumbs up for the push. >> >> Testing: >> Run: >> - nsk.jvmti.testlist, nsk.jdi.testlist, vm.mlvm.testlist >> - java/lang/instrument, com/sun/jdi and hotspot/test/runtime tests >> - new jtreg test (see webrev) that was written by Filipp Zhinkin >> >> >> Thanks, >> Serguei >> >> On 1/16/15 3:01 PM, serguei.spitsyn at oracle.com wrote: >>> John R. suggested to use the CPSlot(Symbol* ptr) to mark pseudo-strings. >>> The updated webrev is going to be close to the .3 webrev. >>> I will send it soon. >>> >>> Thanks, >>> Serguei >>> >>> On 1/16/15 2:53 PM, Coleen Phillimore wrote: >>>> >>>> This change looks good to me also. >>>> Thanks, >>>> Coleen >>>> >>>> On 1/16/15, 3:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>> >>>>> >>>>> Open webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8008678-JVMTI-pseudo.3/ >>>>> >>>>> >>>>> Summary: >>>>> Currently, a JVM_CONSTANT_String CP entry having a NULL >>>>> reference to Symbol* >>>>> indicates that it is a pseudo-string (patched string). >>>>> This creates nasty issues for the constant pool reconstitution. >>>>> >>>>> Current suggestion is to avoid having a NULL reference and >>>>> retain the original >>>>> Symbol* reference for pseudo-strings. The pseudo-string >>>>> indication will be >>>>> if the Utf8 representation starts from "CONSTANT_PLACEHOLDER_". >>>>> This approach makes the fix much simpler. >>>>> >>>>> I need a confirmation from the Compiler team that this won't >>>>> break any assumptions or invariants. >>>>> Big thanks to Coleen for previous round reviews and good advices! >>>>> >>>>> >>>>> Testing: >>>>> Run: >>>>> - java/lang/instrument tests >>>>> - new jtreg test (see webrev) that was written by Filipp Zhinkin >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/18/14 2:00 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> Thank you for reviewing! >>>>>> >>>>>> >>>>>> On 12/18/14 11:23 AM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Thank you for making the patches an optional field. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/oops/constantPool.hpp.sdiff.html >>>>>>> 198 if (!patched()) { >>>>>>> 199 assert(false, "a pseudo-string map may exists for patched CP only"); >>>>>>> 200 return 0; >>>>>>> 201 } >>>>>>> Why not >>>>>>> assert(patched(), "a pseud-string map must exist >>>>>>> for patched CP only"); >>>>>> >>>>>> Wanted it to be more reliable but it looks pointless. >>>>>> Will make this change. >>>>>> >>>>>>> >>>>>>> >>>>>>> Why is this? Is this really a ShouldNotReachHere? should it be >>>>>>> false? >>>>>>> >>>>>>> 215 assert(true, "not found a matching entry in pseudo-string map"); >>>>>> >>>>>> >>>>>> A typo, must be false. >>>>>> It is the last minute change. >>>>>> Thanks for the catch! >>>>>> >>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/src/share/vm/prims/jvmtiRedefineClasses.cpp.udiff.html >>>>>>> >>>>>>> Don't you have to move the value of the patched field from the >>>>>>> old constant pool to the new one? I hate to ask but is there >>>>>>> merging that needs to be done? I don't know how to write this >>>>>>> test case though. Is it possible to redefine a class with a >>>>>>> constant pool patches with another that has constant pool patches? >>>>>> >>>>>> Thank you for asking this question. >>>>>> If I understand correctly, the patching comes from the compiler >>>>>> side for anonymous classes only. >>>>>> I saw it for LambdaForm's only. >>>>>> I think, the patching can not be changed with a retransformation. >>>>>> But I'm not sure if it can not be changed with a redefinition. >>>>>> >>>>>> But if it can - then it would be safe to merge the 'patched' >>>>>> condition, i.e. make it patched >>>>>> if either the_class or scratch class is patched. >>>>>> >>>>>>> >>>>>>> Somehow I thought you'd have to save the value of the cp_patches >>>>>>> oops passed in. >>>>>>> >>>>>>> So I was wondering why you can't change this instead: >>>>>>> >>>>>>> bool is_pseudo_string_at(int which) { >>>>>>> // A pseudo string is a string that doesn't have a symbol in >>>>>>> the cpSlot >>>>>>> - return unresolved_string_at(which) == NULL; >>>>>>> + return (strncmp(unresolved_string_at(which)->as_utf8(), >>>>>>> "CONSTANT_PLACEHOLDER_" , strlen("CONSTANT_PLACEHOLDER")) == 0); >>>>>>> } >>>>>> >>>>>> I was thinking about the same but was not sure if it would work >>>>>> for the compiler team. >>>>>> We have to ask John about this (added John and Christian to the >>>>>> cc-list). >>>>>> This question to John was in my plan! :) >>>>>> >>>>>> The beauty of the above approach is that there is no need to >>>>>> create an intermediate >>>>>> pseudo-string map and most of the code in from this webrev is not >>>>>> needed. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> And the asserts in the other functions below it. >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> On 12/17/14, 12:26 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the second round fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.2/ >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> This fix implements a footprint saving approach suggested by >>>>>>>> Coleen. >>>>>>>> To be able to reconstitute a class constant pool, an >>>>>>>> intermediate pseudo-string map is used. >>>>>>>> Now, this field is accounted optionally, only if the >>>>>>>> 'cp_patches' is provided in the >>>>>>>> ClassFileParser::parseClassFile() before ConstantPool is >>>>>>>> allocated. >>>>>>>> This fix is not elegant, even a little bit ugly, but it is >>>>>>>> the only way I see so far. >>>>>>>> >>>>>>>> Unfortunately, this approach did not help much to make some >>>>>>>> other fields (eg., 'operands') optional. >>>>>>>> The problem is that we have to account optional fields before >>>>>>>> parsing, at the CP allocation time. >>>>>>>> It is possible to re-allocate the ConstantPool when any >>>>>>>> InvokeDynamic bytecode is discovered, >>>>>>>> but it looks too complicated. >>>>>>>> >>>>>>>> Testing: >>>>>>>> - the unit test from bug report >>>>>>>> - nsk.jvmti,testlist, nsk.jdi.testlist, JTREG >>>>>>>> java/lang/instrument >>>>>>>> - vm.mlvm.testlist, vm.quick.testlist, >>>>>>>> vm.parallel_class_loading.testlist (in progress) >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 11/26/14 11:53 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Coleen, >>>>>>>>> >>>>>>>>> Thank you for looking at this! >>>>>>>>> I'll check how this can be improved. >>>>>>>>> It is my concern too. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 11/26/14 9:17 AM, Coleen Phillimore wrote: >>>>>>>>>> >>>>>>>>>> Serguei, >>>>>>>>>> I had a quick look at this. I was wondering if we could make >>>>>>>>>> the pseudo_string_map conditional in ConstantPool and not >>>>>>>>>> make all classes pay in footprint for this field? The same >>>>>>>>>> thing probably could be done for operands too. There are >>>>>>>>>> flags that you can set to conditionally add a pointer to >>>>>>>>>> base() in this function. >>>>>>>>>> >>>>>>>>>> Typical C++ would subclass ConstantPool to add >>>>>>>>>> InvokeDynamicConstantPool fields, but this is not typical C++ >>>>>>>>>> so the trick we use is like the one in ConstMethod. I think >>>>>>>>>> it's worth doing in this case. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>> On 11/26/14, 3:59 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review the fix for: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8008678 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Open webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> The pseudo-strings are currently not supported in >>>>>>>>>>> reconstitution of constant pool. >>>>>>>>>>> >>>>>>>>>>> This is an explanation from John Rose about what the >>>>>>>>>>> pseudo-strings are: >>>>>>>>>>> >>>>>>>>>>> "We still need "live" oop constants pre-linked into the >>>>>>>>>>> constant pool of bytecodes which >>>>>>>>>>> implement some method handles. We use the anonymous >>>>>>>>>>> class pseudo-string feature for that. >>>>>>>>>>> The relevant code is here: >>>>>>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java >>>>>>>>>>> >>>>>>>>>>> These oops are what "pseudo-strings" are. >>>>>>>>>>> The odd name refers to the fact that, even though they >>>>>>>>>>> are random oops, they appear in the constant pool >>>>>>>>>>> where one would expect (because of class file syntax) to >>>>>>>>>>> find a string." >>>>>>>>>>> ... >>>>>>>>>>> If you really wanted to reconstitute a class file for an >>>>>>>>>>> anonymous class, and >>>>>>>>>>> if that class has oop patching (pseudo-strings), you >>>>>>>>>>> would need either to (a) reconstitute the patches array >>>>>>>>>>> handed to Unsafe.defineAnonymousClass, or (b) accept >>>>>>>>>>> whatever odd strings were there first, as an approximation. >>>>>>>>>>> The "odd strings" are totally insignificant, and are >>>>>>>>>>> typically something like "CONSTANT_PLACEHOLDER_42" >>>>>>>>>>> (see java/lang/invoke/InvokerBytecodeGenerator.java)." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Reconstitution of the ConstantPool is needed for both the >>>>>>>>>>> JVMTI GetConstantPool() and RetransformClasses(). >>>>>>>>>>> Finally, it goes to the ConstantPool::copy_cpool_bytes(). >>>>>>>>>>> >>>>>>>>>>> The problem is that a pseudo-string is a patched string >>>>>>>>>>> that does not have >>>>>>>>>>> a reference to the string symbol anymore: >>>>>>>>>>> unresolved_string_at(idx) == NULL >>>>>>>>>>> >>>>>>>>>>> The fix is to create and fill in a map from >>>>>>>>>>> JVM_CONSTANT_String cp index to the JVM_CONSTANT_Utf8 cp index >>>>>>>>>>> to be able to restore this assotiation in the >>>>>>>>>>> JvmtiConstantPoolReconstituter. >>>>>>>>>>> >>>>>>>>>>> Testing: >>>>>>>>>>> Run: >>>>>>>>>>> - java/lang/instrument tests >>>>>>>>>>> - new jtreg test (see webrev) that was written by Filipp >>>>>>>>>>> Zhinkin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.walls at oracle.com Wed Jan 28 20:59:59 2015 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 28 Jan 2015 20:59:59 +0000 Subject: RFR(S) (8u): 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54C92032.3040007@oracle.com> References: <54B95862.4020305@oracle.com> <54C91DB3.5000609@oracle.com> <54C92032.3040007@oracle.com> Message-ID: <54C94DCF.50208@oracle.com> Thanks! On 28/01/2015 17:45, Daniel D. Daugherty wrote: > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > No comments. > > Thumbs up. > > Dan > > > On 1/28/15 10:34 AM, Kevin Walls wrote: >> Hi, >> >> I'd like a sanity check review for backporting this from latest/9 to >> jdk8u. It's changing os:free to delete. >> >> In 8u the same change is relevant, the changeset does not import >> directly as we have to remove an (unnecessary) NMT parameter (which >> gets removed by 8060074 in jdk9). >> >> Thanks >> Kevin >> >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> @@ -68,11 +68,11 @@ >> >> ~JvmtiConstantPoolReconstituter() { >> if (_symmap != NULL) { >> - os::free(_symmap, mtClass); >> + delete _symmap; >> _symmap = NULL; >> } >> if (_classmap != NULL) { >> - os::free(_classmap, mtClass); >> + delete _classmap; >> _classmap = NULL; >> } >> } >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool >> Date: Fri, 16 Jan 2015 18:28:50 +0000 >> From: Kevin Walls >> Organization: Oracle Corporation >> To: daniel.daugherty at oracle.com, Mattis Castegren >> >> CC: serviceability-dev at openjdk.java.net >> >> >> >> Thanks Serguei, thanks Dan! >> >> >> On 16/01/2015 17:51, Daniel D. Daugherty wrote: >> > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> > >> > These lines allocate: >> > >> > line 59: _symmap = new SymbolHashMap(); >> > line 60: _classmap = new SymbolHashMap(); >> > >> > and these lines free incorrectly: >> > >> > line 71: os::free(_symmap); >> > line 75: os::free(_classmap); >> > >> > so the proposed fix looks good! >> > >> > >> > Dan >> > >> > >> > On 1/16/15 3:17 AM, Mattis Castegren wrote: >> >> Hi >> >> >> >> This bug is targeted for 7u80, with rdp2 next Tuesday. It would be >> >> great to get a review for this fix as soon as possible, so that we >> >> can get this fix out in the last public JDK 7 release. >> >> >> >> Kind Regards >> >> /Mattis >> >> >> >> -----Original Message----- >> >> From: Kevin Walls >> >> Sent: den 15 januari 2015 15:18 >> >> To:serviceability-dev at openjdk.java.net >> >> Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool >> >> >> >> Hi, >> >> >> >> This is a review request for a change in JVMTI, where we os::free() some >> >> objects where we should delete them. The problem was logged against 7, >> >> though it exists up to the present day, below is a diff in current >> >> latesthttp://hg.openjdk.java.net/jdk9/hs-rt/hotspot >> >> >> >> >> >> Testing: >> >> I've used a native JVMTI agent to call GetConstantPool() during an >> >> object allocation callback. Memory usage does appear less after the >> >> change, it can be 5-6MB in a trivial testcase with a small number of >> >> allocations monitored, each inoking GetConstantlPool(). >> >> >> >> (In my test agent the GetConstantPool() call returns a JVMTI error 101 >> >> after a fairly short time and a relatively small number of allocations >> >> are monitored.) >> >> >> >> If this is OK to submit without testcase that's great. I don't see >> >> other examples of native agents in the standard hotspot tests. >> >> >> >> bug >> >>https://bugs.openjdk.java.net/browse/JDK-8035938 >> >> >> >> diff: >> >> $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> >> b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp >> >> @@ -68,11 +68,11 @@ >> >> >> >> ~JvmtiConstantPoolReconstituter() { >> >> if (_symmap != NULL) { >> >> - os::free(_symmap); >> >> + delete _symmap; >> >> _symmap = NULL; >> >> } >> >> if (_classmap != NULL) { >> >> - os::free(_classmap); >> >> + delete _classmap; >> >> _classmap = NULL; >> >> } >> >> } >> >> >> >> >> >> >> >> Thanks >> >> Kevin >> >> >> >> >> >> >> > >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Jan 28 21:51:35 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 28 Jan 2015 13:51:35 -0800 Subject: RFR(S) (8u): 8035938: Memory leak in JvmtiEnv::GetConstantPool In-Reply-To: <54C91DB3.5000609@oracle.com> References: <54B95862.4020305@oracle.com> <54C91DB3.5000609@oracle.com> Message-ID: <54C959E7.1040008@oracle.com> Looks good. Thanks, Serguei On 1/28/15 9:34 AM, Kevin Walls wrote: > Hi, > > I'd like a sanity check review for backporting this from latest/9 to > jdk8u. It's changing os:free to delete. > > In 8u the same change is relevant, the changeset does not import > directly as we have to remove an (unnecessary) NMT parameter (which > gets removed by 8060074 in jdk9). > > Thanks > Kevin > > diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > @@ -68,11 +68,11 @@ > > ~JvmtiConstantPoolReconstituter() { > if (_symmap != NULL) { > - os::free(_symmap, mtClass); > + delete _symmap; > _symmap = NULL; > } > if (_classmap != NULL) { > - os::free(_classmap, mtClass); > + delete _classmap; > _classmap = NULL; > } > } > > > > -------- Forwarded Message -------- > Subject: Re: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > Date: Fri, 16 Jan 2015 18:28:50 +0000 > From: Kevin Walls > Organization: Oracle Corporation > To: daniel.daugherty at oracle.com, Mattis Castegren > > CC: serviceability-dev at openjdk.java.net > > > > Thanks Serguei, thanks Dan! > > > On 16/01/2015 17:51, Daniel D. Daugherty wrote: > > > src/share/vm/prims/jvmtiClassFileReconstituter.hpp > > > > These lines allocate: > > > > line 59: _symmap = new SymbolHashMap(); > > line 60: _classmap = new SymbolHashMap(); > > > > and these lines free incorrectly: > > > > line 71: os::free(_symmap); > > line 75: os::free(_classmap); > > > > so the proposed fix looks good! > > > > > > Dan > > > > > > On 1/16/15 3:17 AM, Mattis Castegren wrote: > >> Hi > >> > >> This bug is targeted for 7u80, with rdp2 next Tuesday. It would be > >> great to get a review for this fix as soon as possible, so that we > >> can get this fix out in the last public JDK 7 release. > >> > >> Kind Regards > >> /Mattis > >> > >> -----Original Message----- > >> From: Kevin Walls > >> Sent: den 15 januari 2015 15:18 > >> To:serviceability-dev at openjdk.java.net > >> Subject: RFR: 8035938: Memory leak in JvmtiEnv::GetConstantPool > >> > >> Hi, > >> > >> This is a review request for a change in JVMTI, where we os::free() some > >> objects where we should delete them. The problem was logged against 7, > >> though it exists up to the present day, below is a diff in current > >> latesthttp://hg.openjdk.java.net/jdk9/hs-rt/hotspot > >> > >> > >> Testing: > >> I've used a native JVMTI agent to call GetConstantPool() during an > >> object allocation callback. Memory usage does appear less after the > >> change, it can be 5-6MB in a trivial testcase with a small number of > >> allocations monitored, each inoking GetConstantlPool(). > >> > >> (In my test agent the GetConstantPool() call returns a JVMTI error 101 > >> after a fairly short time and a relatively small number of allocations > >> are monitored.) > >> > >> If this is OK to submit without testcase that's great. I don't see > >> other examples of native agents in the standard hotspot tests. > >> > >> bug > >>https://bugs.openjdk.java.net/browse/JDK-8035938 > >> > >> diff: > >> $ hg diff src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> diff --git a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> --- a/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> +++ b/src/share/vm/prims/jvmtiClassFileReconstituter.hpp > >> @@ -68,11 +68,11 @@ > >> > >> ~JvmtiConstantPoolReconstituter() { > >> if (_symmap != NULL) { > >> - os::free(_symmap); > >> + delete _symmap; > >> _symmap = NULL; > >> } > >> if (_classmap != NULL) { > >> - os::free(_classmap); > >> + delete _classmap; > >> _classmap = NULL; > >> } > >> } > >> > >> > >> > >> Thanks > >> Kevin > >> > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Jan 29 01:15:06 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 28 Jan 2015 17:15:06 -0800 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: References: <54C70F7D.3010003@oracle.com> Message-ID: <54C9899A.2070206@oracle.com> Adding serviceability-dev at openjdk.java.net. Can I get another review for this please? thanks, dl On 1/26/2015 11:02 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 27 jan 2015, at 05:09, Dean Long wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8069030 >> >> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >> >> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so that the new code >> would get triggered, then stepping through "jstack -m " with gdb to make sure the new >> code executed correctly. >> >> dl >> From david.holmes at oracle.com Thu Jan 29 07:26:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Jan 2015 17:26:30 +1000 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C8EB6E.5020301@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> <54C88EAF.2060604@oracle.com> <54C8EB6E.5020301@oracle.com> Message-ID: <54C9E0A6.9030302@oracle.com> On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: > David, > >> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? > > done. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ Not quite how I envisaged the fix: JNI_FUNC_PTR(env,PopLocalFrame)(env, NULL); // END_WITH_LOCAL_REFS inlining the macro defeats the purpose the macro to some extent - if it were changed then this code would not get the change. I was thinking more along the lines of: WITH_LOCAL_REFS(env, 1) { char *utf; utf = (char *)JNI_FUNC_PTR(env,GetStringUTFChars)(env, string, NULL); if (!(*env)->ExceptionCheck(env)) { (void)outStream_writeString(out, utf); JNI_FUNC_PTR(env,ReleaseStringUTFChars)(env, string, utf); } } END_WITH_LOCAL_REFS(env); David > -Dmitry > > On 2015-01-28 10:24, David Holmes wrote: >> Hi Dmitry, >> >> Sorry this slipped through the cracks. >> >> On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: >>> David, >>> >>> Please, take a look at updated webrev >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ >> >> src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. >> >> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >> >> Otherwise seems okay. >> >> Thanks, >> David >> >>> -Dmitry >>> >>> >>> On 2014-10-16 16:07, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>> Changed. Thank you for review! >>>>> >>>>> please, see: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>>> >>>> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >>>> >>>> Isn't the only time it will return NULL when an exception occurs? >>>> Conversely if an exception occurs then it must return NULL - so the >>>> exception check seems redundant. >>>> >>>> But this also suggests you need similar logic at: >>>> >>>> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, >>>> node->ref); >>>> >>>> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, >>>> node->ref); >>>> >>>> Or more generally any JNI call from JVMTI should be wrapped in a way >>>> that checks for exceptions and clears them. >>>> >>>> David >>>> >>>>> -Dmitry >>>>> >>>>> On 2014-10-16 04:24, David Holmes wrote: >>>>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>>>> David, >>>>>>> >>>>>>> Sorry, copied wrong function! >>>>>>> >>>>>>> I mean this call >>>>>>> >>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>> >>>>>>> that can post OutOfMemoryError >>>>>> >>>>>> Okay, so shouldn't that be where the exception is cleared: >>>>>> >>>>>> /* Create weak reference to make sure we have a reference */ >>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>> if (weakRef == NULL) { >>>>>> + // < clear exception here > >>>>>> jvmtiDeallocate(node); >>>>>> return NULL; >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> commonRef_refToID() -> >>>>>>> >>>>>>> createNode(JNIEnv *env, jobject ref) -> >>>>>>> >>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>>>> Please review the fix: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Added missed exception checks. >>>>>>>>>> >>>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>>>> >>>>>>>>>> What is potentially posting the exception? >>>>>>>>> >>>>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>>>> commonRef_refToID() >>>>>>>> >>>>>>>> You mean this call: >>>>>>>> >>>>>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>>>> &tag); >>>>>>> >>>>>>> x >>>>>>>> >>>>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI >>>>>>>> doesn't >>>>>>>> post exceptions. >>>>>>>> >>>>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>>>> communicated via the function return value. Any existing exception >>>>>>>> state >>>>>>>> is preserved across a call to a JVM TI function." >>>>>>>> >>>>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From staffan.larsen at oracle.com Thu Jan 29 08:02:12 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 29 Jan 2015 09:02:12 +0100 Subject: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar In-Reply-To: References: Message-ID: <02579E59-7362-43D1-B1B8-C24E4743B8FB@oracle.com> Looks good! nit: test/com/sun/jdi/ShellScaffold.sh:947, the alignment for ">&2? got broken. Thanks, /Staffan > On 28 jan 2015, at 17:24, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071464 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8071464/webrev.01/ > > References to the jre layout are removed from ShellScaffold.sh and DemoRun.java. > Other files mentioned in the CR have not been changed as they don't contain any JRE-related artifacts anymore. > > Thanks, > Alex From serguei.spitsyn at oracle.com Thu Jan 29 08:06:45 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Jan 2015 00:06:45 -0800 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <543F992D.6010000@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> Message-ID: <54C9EA15.9060202@oracle.com> Hi Dmitry, It looks good in general. src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c I agree with David, the fix needs the "END_WITH_LOCAL_REFS(env);" before the line 50. src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c 159 * It never throws OOM Minor: Could you, please, add a dot at the end of the comment statement? No need to re-review after the above is fixed. Thanks, Serguei On 10/16/14 3:08 AM, Dmitry Samersoff wrote: > David, > > Changed. Thank you for review! > > please, see: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ > > -Dmitry > > On 2014-10-16 04:24, David Holmes wrote: >> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>> David, >>> >>> Sorry, copied wrong function! >>> >>> I mean this call >>> >>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>> >>> that can post OutOfMemoryError >> Okay, so shouldn't that be where the exception is cleared: >> >> /* Create weak reference to make sure we have a reference */ >> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >> if (weakRef == NULL) { >> + // < clear exception here > >> jvmtiDeallocate(node); >> return NULL; >> } >> >> Thanks, >> David >> ----- >> >>> commonRef_refToID() -> >>> >>> createNode(JNIEnv *env, jobject ref) -> >>> >>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>> >>> -Dmitry >>> >>> On 2014-10-15 16:21, David Holmes wrote: >>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>> Please review the fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>> >>>>>>> Added missed exception checks. >>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>> >>>>>> What is potentially posting the exception? >>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>> commonRef_refToID() >>>> You mean this call: >>>> >>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>> &tag); >>> x >>>> in findNodeByRef which is called by commonRef_refToID? JVM TI doesn't >>>> post exceptions. >>>> >>>> "JVM TI functions never throw exceptions; error conditions are >>>> communicated via the function return value. Any existing exception state >>>> is preserved across a call to a JVM TI function." >>>> >>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>> >>>> David >>>> >>>>> -Dmitry >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jan 29 08:10:10 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Jan 2015 00:10:10 -0800 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C9EA15.9060202@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <54C9EA15.9060202@oracle.com> Message-ID: <54C9EAE2.4020604@oracle.com> On 1/29/15 12:06 AM, serguei.spitsyn at oracle.com wrote: > Hi Dmitry, > > > It looks good in general. In fact, I've reviewed the webrev.3 (but replied on the wrong email with webrev.2): http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ Thanks, Serguei > > src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c > > I agree with David, the fix needs the "END_WITH_LOCAL_REFS(env);" > before the line 50. > > src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c > 159 * It never throws OOM > > Minor: Could you, please, add a dot at the end of the comment statement? > > No need to re-review after the above is fixed. > > Thanks, > Serguei > > > On 10/16/14 3:08 AM, Dmitry Samersoff wrote: >> David, >> >> Changed. Thank you for review! >> >> please, see: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >> >> -Dmitry >> >> On 2014-10-16 04:24, David Holmes wrote: >>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Sorry, copied wrong function! >>>> >>>> I mean this call >>>> >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> >>>> that can post OutOfMemoryError >>> Okay, so shouldn't that be where the exception is cleared: >>> >>> /* Create weak reference to make sure we have a reference */ >>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>> if (weakRef == NULL) { >>> + // < clear exception here > >>> jvmtiDeallocate(node); >>> return NULL; >>> } >>> >>> Thanks, >>> David >>> ----- >>> >>>> commonRef_refToID() -> >>>> >>>> createNode(JNIEnv *env, jobject ref) -> >>>> >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> >>>> -Dmitry >>>> >>>> On 2014-10-15 16:21, David Holmes wrote: >>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>> Please review the fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>> >>>>>>>> Added missed exception checks. >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>> >>>>>>> What is potentially posting the exception? >>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>> commonRef_refToID() >>>>> You mean this call: >>>>> >>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>> &tag); >>>> x >>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI doesn't >>>>> post exceptions. >>>>> >>>>> "JVM TI functions never throw exceptions; error conditions are >>>>> communicated via the function return value. Any existing exception state >>>>> is preserved across a call to a JVM TI function." >>>>> >>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Jan 29 08:48:06 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 29 Jan 2015 11:48:06 +0300 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C9EAE2.4020604@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <54C9EA15.9060202@oracle.com> <54C9EAE2.4020604@oracle.com> Message-ID: <54C9F3C6.3040505@oracle.com> Serguei, Thanks. -Dmitry On 2015-01-29 11:10, serguei.spitsyn at oracle.com wrote: > > > On 1/29/15 12:06 AM, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, >> >> >> It looks good in general. > > In fact, I've reviewed the webrev.3 (but replied on the wrong email with > webrev.2): > http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ > > > Thanks, > Serguei >> >> src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c >> >> I agree with David, the fix needs the "END_WITH_LOCAL_REFS(env);" >> before the line 50. >> >> src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c >> 159 * It never throws OOM >> >> Minor: Could you, please, add a dot at the end of the comment statement? >> >> No need to re-review after the above is fixed. >> >> Thanks, >> Serguei >> >> >> On 10/16/14 3:08 AM, Dmitry Samersoff wrote: >>> David, >>> >>> Changed. Thank you for review! >>> >>> please, see: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>> >>> -Dmitry >>> >>> On 2014-10-16 04:24, David Holmes wrote: >>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>> Sorry, copied wrong function! >>>>> >>>>> I mean this call >>>>> >>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>> >>>>> that can post OutOfMemoryError >>>> Okay, so shouldn't that be where the exception is cleared: >>>> >>>> /* Create weak reference to make sure we have a reference */ >>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>> if (weakRef == NULL) { >>>> + // < clear exception here > >>>> jvmtiDeallocate(node); >>>> return NULL; >>>> } >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> commonRef_refToID() -> >>>>> >>>>> createNode(JNIEnv *env, jobject ref) -> >>>>> >>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>> >>>>> -Dmitry >>>>> >>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>> Please review the fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>> >>>>>>>>> Added missed exception checks. >>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>> >>>>>>>> What is potentially posting the exception? >>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>> commonRef_refToID() >>>>>> You mean this call: >>>>>> >>>>>> error = JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>> &tag); >>>>> x >>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI doesn't >>>>>> post exceptions. >>>>>> >>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>> communicated via the function return value. Any existing exception state >>>>>> is preserved across a call to a JVM TI function." >>>>>> >>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>> >>>>>> David >>>>>> >>>>>>> -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 dmitry.samersoff at oracle.com Thu Jan 29 08:49:02 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 29 Jan 2015 11:49:02 +0300 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C9E0A6.9030302@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> <54C88EAF.2060604@oracle.com> <54C8EB6E.5020301@oracle.com> <54C9E0A6.9030302@oracle.com> Message-ID: <54C9F3FE.6080604@oracle.com> David, Agree! Will change it. -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >> >> done. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ > > Not quite how I envisaged the fix: > > JNI_FUNC_PTR(env,PopLocalFrame)(env, NULL); // END_WITH_LOCAL_REFS > > inlining the macro defeats the purpose the macro to some extent - if it > were changed then this code would not get the change. I was thinking > more along the lines of: > > WITH_LOCAL_REFS(env, 1) { > > char *utf; > > utf = (char *)JNI_FUNC_PTR(env,GetStringUTFChars)(env, string, NULL); > if (!(*env)->ExceptionCheck(env)) { > (void)outStream_writeString(out, utf); > JNI_FUNC_PTR(env,ReleaseStringUTFChars)(env, string, utf); > } > > } END_WITH_LOCAL_REFS(env); > > David > >> -Dmitry >> >> On 2015-01-28 10:24, David Holmes wrote: >>> Hi Dmitry, >>> >>> Sorry this slipped through the cracks. >>> >>> On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Please, take a look at updated webrev >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. >>> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >>> >>> Otherwise seems okay. >>> >>> Thanks, >>> David >>> >>>> -Dmitry >>>> >>>> >>>> On 2014-10-16 16:07, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>> David, >>>>>> >>>>>> Changed. Thank you for review! >>>>>> >>>>>> please, see: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>>>> >>>>> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >>>>> >>>>> Isn't the only time it will return NULL when an exception occurs? >>>>> Conversely if an exception occurs then it must return NULL - so the >>>>> exception check seems redundant. >>>>> >>>>> But this also suggests you need similar logic at: >>>>> >>>>> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, >>>>> node->ref); >>>>> >>>>> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, >>>>> node->ref); >>>>> >>>>> Or more generally any JNI call from JVMTI should be wrapped in a way >>>>> that checks for exceptions and clears them. >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-10-16 04:24, David Holmes wrote: >>>>>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> Sorry, copied wrong function! >>>>>>>> >>>>>>>> I mean this call >>>>>>>> >>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>> >>>>>>>> that can post OutOfMemoryError >>>>>>> >>>>>>> Okay, so shouldn't that be where the exception is cleared: >>>>>>> >>>>>>> /* Create weak reference to make sure we have a reference */ >>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>> if (weakRef == NULL) { >>>>>>> + // < clear exception here > >>>>>>> jvmtiDeallocate(node); >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> commonRef_refToID() -> >>>>>>>> >>>>>>>> createNode(JNIEnv *env, jobject ref) -> >>>>>>>> >>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>>>>> Please review the fix: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Added missed exception checks. >>>>>>>>>>> >>>>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>>>>> >>>>>>>>>>> What is potentially posting the exception? >>>>>>>>>> >>>>>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>>>>> commonRef_refToID() >>>>>>>>> >>>>>>>>> You mean this call: >>>>>>>>> >>>>>>>>> error = >>>>>>>>> JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>>>>> &tag); >>>>>>>> >>>>>>>> x >>>>>>>>> >>>>>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI >>>>>>>>> doesn't >>>>>>>>> post exceptions. >>>>>>>>> >>>>>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>>>>> communicated via the function return value. Any existing exception >>>>>>>>> state >>>>>>>>> is preserved across a call to a JVM TI function." >>>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> -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 dmitry.samersoff at oracle.com Thu Jan 29 10:29:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 29 Jan 2015 13:29:52 +0300 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54C9E0A6.9030302@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> <54C88EAF.2060604@oracle.com> <54C8EB6E.5020301@oracle.com> <54C9E0A6.9030302@oracle.com> Message-ID: <54CA0BA0.9020507@oracle.com> David, Fixed in place (press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >> >> done. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ > > Not quite how I envisaged the fix: > > JNI_FUNC_PTR(env,PopLocalFrame)(env, NULL); // END_WITH_LOCAL_REFS > > inlining the macro defeats the purpose the macro to some extent - if it > were changed then this code would not get the change. I was thinking > more along the lines of: > > WITH_LOCAL_REFS(env, 1) { > > char *utf; > > utf = (char *)JNI_FUNC_PTR(env,GetStringUTFChars)(env, string, NULL); > if (!(*env)->ExceptionCheck(env)) { > (void)outStream_writeString(out, utf); > JNI_FUNC_PTR(env,ReleaseStringUTFChars)(env, string, utf); > } > > } END_WITH_LOCAL_REFS(env); > > David > >> -Dmitry >> >> On 2015-01-28 10:24, David Holmes wrote: >>> Hi Dmitry, >>> >>> Sorry this slipped through the cracks. >>> >>> On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Please, take a look at updated webrev >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ >>> >>> src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. >>> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >>> >>> Otherwise seems okay. >>> >>> Thanks, >>> David >>> >>>> -Dmitry >>>> >>>> >>>> On 2014-10-16 16:07, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>> David, >>>>>> >>>>>> Changed. Thank you for review! >>>>>> >>>>>> please, see: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>>>> >>>>> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >>>>> >>>>> Isn't the only time it will return NULL when an exception occurs? >>>>> Conversely if an exception occurs then it must return NULL - so the >>>>> exception check seems redundant. >>>>> >>>>> But this also suggests you need similar logic at: >>>>> >>>>> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, >>>>> node->ref); >>>>> >>>>> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, >>>>> node->ref); >>>>> >>>>> Or more generally any JNI call from JVMTI should be wrapped in a way >>>>> that checks for exceptions and clears them. >>>>> >>>>> David >>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2014-10-16 04:24, David Holmes wrote: >>>>>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> Sorry, copied wrong function! >>>>>>>> >>>>>>>> I mean this call >>>>>>>> >>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>> >>>>>>>> that can post OutOfMemoryError >>>>>>> >>>>>>> Okay, so shouldn't that be where the exception is cleared: >>>>>>> >>>>>>> /* Create weak reference to make sure we have a reference */ >>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>> if (weakRef == NULL) { >>>>>>> + // < clear exception here > >>>>>>> jvmtiDeallocate(node); >>>>>>> return NULL; >>>>>>> } >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> commonRef_refToID() -> >>>>>>>> >>>>>>>> createNode(JNIEnv *env, jobject ref) -> >>>>>>>> >>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>>>>> Please review the fix: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Added missed exception checks. >>>>>>>>>>> >>>>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>>>>> >>>>>>>>>>> What is potentially posting the exception? >>>>>>>>>> >>>>>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>>>>> commonRef_refToID() >>>>>>>>> >>>>>>>>> You mean this call: >>>>>>>>> >>>>>>>>> error = >>>>>>>>> JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>>>>> &tag); >>>>>>>> >>>>>>>> x >>>>>>>>> >>>>>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI >>>>>>>>> doesn't >>>>>>>>> post exceptions. >>>>>>>>> >>>>>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>>>>> communicated via the function return value. Any existing exception >>>>>>>>> state >>>>>>>>> is preserved across a call to a JVM TI function." >>>>>>>>> >>>>>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> -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 daniel.fuchs at oracle.com Thu Jan 29 11:07:26 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Jan 2015 12:07:26 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C885DB.50304@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> Message-ID: <54CA146E.5000307@oracle.com> On 28/01/15 07:46, Mandy Chung wrote: > com/sun/management/internal/PlatformMBeanProviderImpl.java > line 43: does this mxbeanList have to be created lazily? > Would it be better to make it a final field and create it at the > constructor? Hi Mandy, I was the one to suggest the lazy initialization. Given that the constructor is going to be invoked by the ServiceLoader, I thought it would be better to delay any heavy initialization until such time that the loaded service provider is actually used. best regards, -- daniel From david.holmes at oracle.com Thu Jan 29 11:31:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Jan 2015 21:31:45 +1000 Subject: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending In-Reply-To: <54CA0BA0.9020507@oracle.com> References: <543E4797.9050302@oracle.com> <543E4C06.2080601@oracle.com> <543E4EC7.2060204@oracle.com> <543E66E3.6040400@oracle.com> <543E85D0.8080701@oracle.com> <543F104C.3010208@oracle.com> <543F992D.6010000@oracle.com> <543FB4EF.5050706@oracle.com> <54BFA432.10500@oracle.com> <54C88EAF.2060604@oracle.com> <54C8EB6E.5020301@oracle.com> <54C9E0A6.9030302@oracle.com> <54CA0BA0.9020507@oracle.com> Message-ID: <54CA1A21.4070600@oracle.com> Looks good. Thanks, David On 29/01/2015 8:29 PM, Dmitry Samersoff wrote: > David, > > Fixed in place (press shift-reload) > > http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ > > -Dmitry > > > On 2015-01-29 10:26, David Holmes wrote: >> On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >>> David, >>> >>>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >>> >>> done. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ >> >> Not quite how I envisaged the fix: >> >> JNI_FUNC_PTR(env,PopLocalFrame)(env, NULL); // END_WITH_LOCAL_REFS >> >> inlining the macro defeats the purpose the macro to some extent - if it >> were changed then this code would not get the change. I was thinking >> more along the lines of: >> >> WITH_LOCAL_REFS(env, 1) { >> >> char *utf; >> >> utf = (char *)JNI_FUNC_PTR(env,GetStringUTFChars)(env, string, NULL); >> if (!(*env)->ExceptionCheck(env)) { >> (void)outStream_writeString(out, utf); >> JNI_FUNC_PTR(env,ReleaseStringUTFChars)(env, string, utf); >> } >> >> } END_WITH_LOCAL_REFS(env); >> >> David >> >>> -Dmitry >>> >>> On 2015-01-28 10:24, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> Sorry this slipped through the cracks. >>>> >>>> On 21/01/2015 11:05 PM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>> Please, take a look at updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ >>>> >>>> src/jdk.jdwp.agent/share/native/libjdwp/StringReferenceImpl.c. >>>> >>>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >>>> >>>> Otherwise seems okay. >>>> >>>> Thanks, >>>> David >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2014-10-16 16:07, David Holmes wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>> David, >>>>>>> >>>>>>> Changed. Thank you for review! >>>>>>> >>>>>>> please, see: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.02/ >>>>>> >>>>>> 102 if (weakRef == NULL || (*env)->ExceptionCheck(env)) { >>>>>> >>>>>> Isn't the only time it will return NULL when an exception occurs? >>>>>> Conversely if an exception occurs then it must return NULL - so the >>>>>> exception check seems redundant. >>>>>> >>>>>> But this also suggests you need similar logic at: >>>>>> >>>>>> 182 weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, >>>>>> node->ref); >>>>>> >>>>>> 456 lref = JNI_FUNC_PTR(env,NewLocalRef)(env, >>>>>> node->ref); >>>>>> >>>>>> Or more generally any JNI call from JVMTI should be wrapped in a way >>>>>> that checks for exceptions and clears them. >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> On 2014-10-16 04:24, David Holmes wrote: >>>>>>>> On 16/10/2014 12:33 AM, Dmitry Samersoff wrote: >>>>>>>>> David, >>>>>>>>> >>>>>>>>> Sorry, copied wrong function! >>>>>>>>> >>>>>>>>> I mean this call >>>>>>>>> >>>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>>> >>>>>>>>> that can post OutOfMemoryError >>>>>>>> >>>>>>>> Okay, so shouldn't that be where the exception is cleared: >>>>>>>> >>>>>>>> /* Create weak reference to make sure we have a reference */ >>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>> if (weakRef == NULL) { >>>>>>>> + // < clear exception here > >>>>>>>> jvmtiDeallocate(node); >>>>>>>> return NULL; >>>>>>>> } >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> commonRef_refToID() -> >>>>>>>>> >>>>>>>>> createNode(JNIEnv *env, jobject ref) -> >>>>>>>>> >>>>>>>>> weakRef = JNI_FUNC_PTR(env,NewWeakGlobalRef)(env, ref); >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> On 2014-10-15 16:21, David Holmes wrote: >>>>>>>>>> On 15/10/2014 8:39 PM, Dmitry Samersoff wrote: >>>>>>>>>>> On 2014-10-15 14:27, David Holmes wrote: >>>>>>>>>>>> On 15/10/2014 8:08 PM, Dmitry Samersoff wrote: >>>>>>>>>>>>> Please review the fix: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Added missed exception checks. >>>>>>>>>>>> >>>>>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/outStream.c >>>>>>>>>>>> >>>>>>>>>>>> What is potentially posting the exception? >>>>>>>>>>> >>>>>>>>>>> JvmtiEnv::GetTag(jobject object, jlong* tag_ptr) called from >>>>>>>>>>> commonRef_refToID() >>>>>>>>>> >>>>>>>>>> You mean this call: >>>>>>>>>> >>>>>>>>>> error = >>>>>>>>>> JVMTI_FUNC_PTR(gdata->jvmti,GetTag)(gdata->jvmti, ref, >>>>>>>>>> &tag); >>>>>>>>> >>>>>>>>> x >>>>>>>>>> >>>>>>>>>> in findNodeByRef which is called by commonRef_refToID? JVM TI >>>>>>>>>> doesn't >>>>>>>>>> post exceptions. >>>>>>>>>> >>>>>>>>>> "JVM TI functions never throw exceptions; error conditions are >>>>>>>>>> communicated via the function return value. Any existing exception >>>>>>>>>> state >>>>>>>>>> is preserved across a call to a JVM TI function." >>>>>>>>>> >>>>>>>>>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> -Dmitry >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From alexander.kulyakhtin at oracle.com Thu Jan 29 12:21:12 2015 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 29 Jan 2015 04:21:12 -0800 (PST) Subject: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar Message-ID: <17a5269f-0e9a-4d7f-91c3-5220d10045d3@default> Hi Katja, Stafan I've corrected the alignment issue, per Stafan's review, and attached the patch. Could it be possible to push the patch? Thank you very much for your help. Best regards, Alex ----- Original Message ----- From: staffan.larsen at oracle.com To: alexander.kulyakhtin at oracle.com Cc: serviceability-dev at openjdk.java.net Sent: Thursday, January 29, 2015 11:02:12 AM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar Looks good! nit: test/com/sun/jdi/ShellScaffold.sh:947, the alignment for ">&2? got broken. Thanks, /Staffan > On 28 jan 2015, at 17:24, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the fix below. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071464 > webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8071464/webrev.01/ > > References to the jre layout are removed from ShellScaffold.sh and DemoRun.java. > Other files mentioned in the CR have not been changed as they don't contain any JRE-related artifacts anymore. > > Thanks, > Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk8071464.patch Type: text/x-patch Size: 2628 bytes Desc: not available URL: From staffan.larsen at oracle.com Thu Jan 29 12:27:34 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 29 Jan 2015 13:27:34 +0100 Subject: RFR 8068976: Remove JSDT implementation In-Reply-To: <54B677B5.3080809@oracle.com> References: <54B677B5.3080809@oracle.com> Message-ID: <762CF5C2-A799-46D3-A6E9-84FDB07F89CC@oracle.com> Looks good to me. Thanks, /Staffan > On 14 jan 2015, at 15:05, Jaroslav Bachorik wrote: > > Please, review the following removal of functionality. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068976 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068976/webrev.00 > > JDK-8062303 [1] requests the removal of com.sun.tracing API. This API was added as experimental in JDK7 [2][3] and haven't seen any significant uptake since then. > > JSDT builds on top of the com.sun.tracing API and provides the bridge to DTrace. It allows Java programs to fire custom DTrace probes. As an implementation of com.sun.tracing API it needs to be removed before proceeding with the removal of that API. > > This change is basically an anti-delta to [4] - minus the changes not related to JSDT and/or DTrace. > > This change passes all the regression and JCK tests. > > Thanks, > > -JB- > > > [1] https://bugs.openjdk.java.net/browse/JDK-8062303 > [2] https://bugs.openjdk.java.net/browse/JDK-6537506 > [3] https://bugs.openjdk.java.net/browse/JDK-7037081 > [4] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/018d5b58dd4f From yekaterina.kantserova at oracle.com Thu Jan 29 12:35:35 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 29 Jan 2015 13:35:35 +0100 Subject: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar In-Reply-To: <17a5269f-0e9a-4d7f-91c3-5220d10045d3@default> References: <17a5269f-0e9a-4d7f-91c3-5220d10045d3@default> Message-ID: <54CA2917.2030206@oracle.com> Alex, I'll push. // Katja On 01/29/2015 01:21 PM, Alexander Kulyakhtin wrote: > Hi Katja, Stafan > > I've corrected the alignment issue, per Stafan's review, and attached the patch. > > Could it be possible to push the patch? > > Thank you very much for your help. > > Best regards, > Alex > > ----- Original Message ----- > From: staffan.larsen at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: serviceability-dev at openjdk.java.net > Sent: Thursday, January 29, 2015 11:02:12 AM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: JDK-8071464: Clear up SVC jdk/test/* JRE layout dependencies other than those on tools.jar > > Looks good! > > nit: test/com/sun/jdi/ShellScaffold.sh:947, the alignment for ">&2? got broken. > > Thanks, > /Staffan > > >> On 28 jan 2015, at 17:24, Alexander Kulyakhtin wrote: >> >> Hi, >> >> Could you, please, review the fix below. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8071464 >> webrev: http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8071464/webrev.01/ >> >> References to the jre layout are removed from ShellScaffold.sh and DemoRun.java. >> Other files mentioned in the CR have not been changed as they don't contain any JRE-related artifacts anymore. >> >> Thanks, >> Alex From jaroslav.bachorik at oracle.com Thu Jan 29 13:03:53 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 29 Jan 2015 14:03:53 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE Message-ID: <54CA2FB9.9020108@oracle.com> Please, review the following test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ The test fails very intermittently with NPE. This seems to be caused by a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but the ThreadInfo still contains a stale information (lockname == null). The solution would be re-retrieving the ThreadInfo until it reflects the actual thread state. -JB- From yekaterina.kantserova at oracle.com Thu Jan 29 13:23:33 2015 From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova) Date: Thu, 29 Jan 2015 14:23:33 +0100 Subject: RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined Message-ID: <54CA3455.6050405@oracle.com> Hi, Could I please have a review of this very small fix. bug: https://bugs.openjdk.java.net/browse/JDK-8071784 webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ Thanks, Katja From jaroslav.bachorik at oracle.com Thu Jan 29 13:33:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 29 Jan 2015 14:33:08 +0100 Subject: RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined In-Reply-To: <54CA3455.6050405@oracle.com> References: <54CA3455.6050405@oracle.com> Message-ID: <54CA3694.5020801@oracle.com> Looks good! -JB- On 29.1.2015 14:23, Yekaterina Kantserova wrote: > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071784 > webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ > > Thanks, > Katja From shanliang.jiang at oracle.com Thu Jan 29 13:43:28 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 29 Jan 2015 14:43:28 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA2FB9.9020108@oracle.com> References: <54CA2FB9.9020108@oracle.com> Message-ID: <54CA3900.6090402@oracle.com> Jaroslav Bachorik wrote: > Please, review the following test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 > Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ > > The test fails very intermittently with NPE. This seems to be caused > by a data race between Thread.getStatus() and > ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but > the ThreadInfo still contains a stale information (lockname == null). > > The solution would be re-retrieving the ThreadInfo until it reflects > the actual thread state. > > -JB- 77 private static void waitForThreadState(Thread t, Thread.State state) throws InterruptedException { 78 while (!t.isInterrupted() && t.getState() != state) { 79 Thread.sleep(3); 80 } 81 } Better to throw an exception if t.isInterrupted()? Not sure when will happen t.isInterrupted(), but the method waitForThreadState tests it, so it is supposed to be possible to get it, when it is true then the testing method might return with a thread state different to the waited one. Shanliang From daniel.fuchs at oracle.com Thu Jan 29 13:58:41 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Jan 2015 14:58:41 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA2FB9.9020108@oracle.com> References: <54CA2FB9.9020108@oracle.com> Message-ID: <54CA3C91.3000801@oracle.com> Hi Jaroslav, The only thread state that this test is waiting on seems to be Thread.State.BLOCKED - which makes me wonder if you could add a method: String waitForBlockedState(Thread t) throws InterruptedException { long tid = lt.getId(); ThreadInfo ti; while ( (ti = mbean.getThreadInfo(tid)).getThreadState() != Thread.State.BLOCKED) { Thread.sleep(3); } return ti.getLockName(); } Would that be feasible - or would it have side effects on what the test is testing? best regards, -- daniel On 29/01/15 14:03, Jaroslav Bachorik wrote: > Please, review the following test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 > Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ > > The test fails very intermittently with NPE. This seems to be caused by > a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo() > - thread state is reported as BLOCKED but the ThreadInfo still contains > a stale information (lockname == null). > > The solution would be re-retrieving the ThreadInfo until it reflects the > actual thread state. > > -JB- From staffan.larsen at oracle.com Thu Jan 29 14:01:23 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 29 Jan 2015 15:01:23 +0100 Subject: RFR(XXS): 8071784: serviceability/attach/AttachWithStalePidFile.java should be quarantined In-Reply-To: <54CA3455.6050405@oracle.com> References: <54CA3455.6050405@oracle.com> Message-ID: <8BA7AE2D-D2F2-4D95-A478-41D12C4B1656@oracle.com> Looks good! Thanks, /Staffan > On 29 jan 2015, at 14:23, Yekaterina Kantserova wrote: > > Hi, > > Could I please have a review of this very small fix. > > bug: https://bugs.openjdk.java.net/browse/JDK-8071784 > webrev: http://cr.openjdk.java.net/~ykantser/8071784/webrev.00/ > > Thanks, > Katja From jaroslav.bachorik at oracle.com Thu Jan 29 15:21:44 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 29 Jan 2015 16:21:44 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA3C91.3000801@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3C91.3000801@oracle.com> Message-ID: <54CA5008.8070007@oracle.com> On 29.1.2015 14:58, Daniel Fuchs wrote: > Hi Jaroslav, > > The only thread state that this test is waiting on seems to be > Thread.State.BLOCKED - which makes me wonder if you could add a > method: > > String waitForBlockedState(Thread t) throws InterruptedException { > long tid = lt.getId(); > ThreadInfo ti; > while ( (ti = mbean.getThreadInfo(tid)).getThreadState() != > Thread.State.BLOCKED) { > Thread.sleep(3); > } > return ti.getLockName(); > } Retrieving ThreadInfo is a rather extensive operation involving security checks and as such might interfere with the test. It would require a thorough analysis to prove that it wouldn't interfere with the counters the test checks in any situation. -JB- > > Would that be feasible - or would it have side effects on what the > test is testing? > > best regards, > > -- daniel > > On 29/01/15 14:03, Jaroslav Bachorik wrote: >> Please, review the following test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >> >> The test fails very intermittently with NPE. This seems to be caused by >> a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo() >> - thread state is reported as BLOCKED but the ThreadInfo still contains >> a stale information (lockname == null). >> >> The solution would be re-retrieving the ThreadInfo until it reflects the >> actual thread state. >> >> -JB- > From jaroslav.bachorik at oracle.com Thu Jan 29 15:27:40 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 29 Jan 2015 16:27:40 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA3900.6090402@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3900.6090402@oracle.com> Message-ID: <54CA516C.4090408@oracle.com> On 29.1.2015 14:43, shanliang wrote: > Jaroslav Bachorik wrote: >> Please, review the following test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >> >> The test fails very intermittently with NPE. This seems to be caused >> by a data race between Thread.getStatus() and >> ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but >> the ThreadInfo still contains a stale information (lockname == null). >> >> The solution would be re-retrieving the ThreadInfo until it reflects >> the actual thread state. >> >> -JB- > 77 private static void waitForThreadState(Thread t, Thread.State > state) throws InterruptedException { > 78 while (!t.isInterrupted() && t.getState() != state) { > 79 Thread.sleep(3); > 80 } > 81 } > Better to throw an exception if t.isInterrupted()? > Not sure when will happen t.isInterrupted(), but the method > waitForThreadState tests it, so it is supposed to be possible to get it, > when it is true then the testing method might return with a thread state > different to the waited one. Yes, it might get to an undefined state. But given that the thread would get interrupted only when the harness is timing out the test this discrepancy would not actually matter - the test would fail with timeout anyway. -JB- > > Shanliang > > From daniel.fuchs at oracle.com Thu Jan 29 15:44:09 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 29 Jan 2015 16:44:09 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA5008.8070007@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3C91.3000801@oracle.com> <54CA5008.8070007@oracle.com> Message-ID: <54CA5549.6020009@oracle.com> On 29/01/15 16:21, Jaroslav Bachorik wrote: > On 29.1.2015 14:58, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> The only thread state that this test is waiting on seems to be >> Thread.State.BLOCKED - which makes me wonder if you could add a >> method: >> >> String waitForBlockedState(Thread t) throws InterruptedException { >> long tid = lt.getId(); >> ThreadInfo ti; >> while ( (ti = mbean.getThreadInfo(tid)).getThreadState() != >> Thread.State.BLOCKED) { >> Thread.sleep(3); >> } >> return ti.getLockName(); >> } > > Retrieving ThreadInfo is a rather extensive operation involving security > checks and as such might interfere with the test. It would require a > thorough analysis to prove that it wouldn't interfere with the counters > the test checks in any situation. Well then - I guess that what you have is good to go... -- daniel > > -JB- > >> >> Would that be feasible - or would it have side effects on what the >> test is testing? >> >> best regards, >> >> -- daniel >> >> On 29/01/15 14:03, Jaroslav Bachorik wrote: >>> Please, review the following test change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >>> >>> The test fails very intermittently with NPE. This seems to be caused by >>> a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo() >>> - thread state is reported as BLOCKED but the ThreadInfo still contains >>> a stale information (lockname == null). >>> >>> The solution would be re-retrieving the ThreadInfo until it reflects the >>> actual thread state. >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Thu Jan 29 15:46:16 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 29 Jan 2015 16:46:16 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA5549.6020009@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3C91.3000801@oracle.com> <54CA5008.8070007@oracle.com> <54CA5549.6020009@oracle.com> Message-ID: <54CA55C8.8000808@oracle.com> On 29.1.2015 16:44, Daniel Fuchs wrote: > On 29/01/15 16:21, Jaroslav Bachorik wrote: >> On 29.1.2015 14:58, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> The only thread state that this test is waiting on seems to be >>> Thread.State.BLOCKED - which makes me wonder if you could add a >>> method: >>> >>> String waitForBlockedState(Thread t) throws InterruptedException { >>> long tid = lt.getId(); >>> ThreadInfo ti; >>> while ( (ti = mbean.getThreadInfo(tid)).getThreadState() != >>> Thread.State.BLOCKED) { >>> Thread.sleep(3); >>> } >>> return ti.getLockName(); >>> } >> >> Retrieving ThreadInfo is a rather extensive operation involving security >> checks and as such might interfere with the test. It would require a >> thorough analysis to prove that it wouldn't interfere with the counters >> the test checks in any situation. > > Well then - I guess that what you have is good to go... Yep, thanks. Testing the thread level counters has proved to be very tricky :( -JB- > > -- daniel > >> >> -JB- >> >>> >>> Would that be feasible - or would it have side effects on what the >>> test is testing? >>> >>> best regards, >>> >>> -- daniel >>> >>> On 29/01/15 14:03, Jaroslav Bachorik wrote: >>>> Please, review the following test change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >>>> >>>> The test fails very intermittently with NPE. This seems to be caused by >>>> a data race between Thread.getStatus() and ThreadMXBean.getThreadInfo() >>>> - thread state is reported as BLOCKED but the ThreadInfo still contains >>>> a stale information (lockname == null). >>>> >>>> The solution would be re-retrieving the ThreadInfo until it reflects >>>> the >>>> actual thread state. >>>> >>>> -JB- >>> >> > From shanliang.jiang at oracle.com Thu Jan 29 15:59:54 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 29 Jan 2015 16:59:54 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA516C.4090408@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3900.6090402@oracle.com> <54CA516C.4090408@oracle.com> Message-ID: <54CA58FA.4050104@oracle.com> Jaroslav Bachorik wrote: > On 29.1.2015 14:43, shanliang wrote: >> Jaroslav Bachorik wrote: >>> Please, review the following test change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >>> >>> The test fails very intermittently with NPE. This seems to be caused >>> by a data race between Thread.getStatus() and >>> ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but >>> the ThreadInfo still contains a stale information (lockname == null). >>> >>> The solution would be re-retrieving the ThreadInfo until it reflects >>> the actual thread state. >>> >>> -JB- >> 77 private static void waitForThreadState(Thread t, Thread.State >> state) throws InterruptedException { >> 78 while (!t.isInterrupted() && t.getState() != state) { >> 79 Thread.sleep(3); >> 80 } >> 81 } >> Better to throw an exception if t.isInterrupted()? >> Not sure when will happen t.isInterrupted(), but the method >> waitForThreadState tests it, so it is supposed to be possible to get it, >> when it is true then the testing method might return with a thread state >> different to the waited one. > > Yes, it might get to an undefined state. But given that the thread > would get interrupted only when the harness is timing out the test > this discrepancy would not actually matter - the test would fail with > timeout anyway. In this case it is useless to test t.isInterrupted() in waitForThreadState. Shanliang > > -JB- > >> >> Shanliang >> >> > From poonam.bajaj at oracle.com Thu Jan 29 19:42:20 2015 From: poonam.bajaj at oracle.com (Poonam Bajaj Parhar) Date: Thu, 29 Jan 2015 11:42:20 -0800 Subject: Review request: Backport of JDK-8046282 to 8u Message-ID: <54CA8D1C.6010408@oracle.com> Hello, Review request for the backport of 8046282 to 8u: Bug: JDK-8046282 SA update Webrev: http://cr.openjdk.java.net/~poonam/8046282/webrev.00/ Thanks, Poonam -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Jan 29 19:48:31 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 29 Jan 2015 11:48:31 -0800 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CA146E.5000307@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CA146E.5000307@oracle.com> Message-ID: <54CA8E8F.8030404@oracle.com> On 1/29/15 3:07 AM, Daniel Fuchs wrote: > On 28/01/15 07:46, Mandy Chung wrote: >> com/sun/management/internal/PlatformMBeanProviderImpl.java >> line 43: does this mxbeanList have to be created lazily? >> Would it be better to make it a final field and create it at the >> constructor? > > Hi Mandy, > > I was the one to suggest the lazy initialization. > Given that the constructor is going to be invoked by the > ServiceLoader, I thought it would be better to delay any > heavy initialization until such time that the loaded > service provider is actually used. > These providers will need to be loaded and the mxbeanList will be looked at except for the cases that we are sure that the MXBean only comes from the default provider. I see the cost of constructing mxbeanList involves loading several classes. If performance is an issue, perhaps the fast-path would be in ManagementFactory to defer loading providers and may be better to follow up the performance side in the second phase (that I expect more changes to sun/management classes) You may want to consider using limited doPrivileged (that can be done in the second phase). Mandy > best regards, > > -- daniel From mandy.chung at oracle.com Thu Jan 29 21:52:44 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 29 Jan 2015 13:52:44 -0800 Subject: RFR 8068976: Remove JSDT implementation In-Reply-To: <54B677B5.3080809@oracle.com> References: <54B677B5.3080809@oracle.com> Message-ID: <54CAABAC.8090905@oracle.com> Looks good to me. Do you plan to push the jdk side change to remove com.sun.tracing together with the hotspot change? I notice that you have a separate bug JDK-8062303 for jdk change. It's fine to choose to do. It'd also be fine to push the jdk change together with this hotspot change. Mandy On 1/14/15 6:05 AM, Jaroslav Bachorik wrote: > Please, review the following removal of functionality. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8068976 > Webrev: http://cr.openjdk.java.net/~jbachorik/8068976/webrev.00 > > JDK-8062303 [1] requests the removal of com.sun.tracing API. This API > was added as experimental in JDK7 [2][3] and haven't seen any > significant uptake since then. > > JSDT builds on top of the com.sun.tracing API and provides the bridge > to DTrace. It allows Java programs to fire custom DTrace probes. As an > implementation of com.sun.tracing API it needs to be removed before > proceeding with the removal of that API. > > This change is basically an anti-delta to [4] - minus the changes not > related to JSDT and/or DTrace. > > This change passes all the regression and JCK tests. > > Thanks, > > -JB- > > > [1] https://bugs.openjdk.java.net/browse/JDK-8062303 > [2] https://bugs.openjdk.java.net/browse/JDK-6537506 > [3] https://bugs.openjdk.java.net/browse/JDK-7037081 > [4] http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/018d5b58dd4f From jiangli.zhou at oracle.com Fri Jan 30 01:13:45 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 29 Jan 2015 17:13:45 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive Message-ID: Hi, Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ Tested on both 32-bit and 64-bit platforms: bin/java sun.jvm.hotspot.tools.DumpJFR JPRT tests in progress. Thanks, Jiangli -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 30 01:40:03 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Jan 2015 17:40:03 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: References: Message-ID: <54CAE0F3.1050608@oracle.com> On 1/29/15 5:13 PM, Jiangli Zhou wrote: > Hi, > > Please review the change for JDK-8071962 > , "The SA code needs > to be updated to support Symbol lookup from the shared archive?. > > In JDK-8059510 , we > introduced a compact form of hash table for the symbols in shared > archive. The shared symbols are stored separately from the regular > symbol table. The VM looks up both tables when searching for existing > symbol at runtime. The SA code needs to do the same when looking up > symbols. > > Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ > Jiangli, I'm not reviewing, just wanted to make sure there is no typo here ... The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. Thanks, Serguei > > Tested on both 32-bit and 64-bit platforms: > bin/java sun.jvm.hotspot.tools.DumpJFR > > JPRT tests in progress. > > Thanks, > Jiangli > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Fri Jan 30 01:46:36 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 29 Jan 2015 17:46:36 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CAE0F3.1050608@oracle.com> References: <54CAE0F3.1050608@oracle.com> Message-ID: <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> Hi Serguei, Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. Thanks, Jiangli On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: > On 1/29/15 5:13 PM, Jiangli Zhou wrote: >> Hi, >> >> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >> >> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >> >> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ > > Jiangli, > > I'm not reviewing, just wanted to make sure there is no typo here ... > The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. > > Thanks, > Serguei > >> >> Tested on both 32-bit and 64-bit platforms: >> bin/java sun.jvm.hotspot.tools.DumpJFR >> >> JPRT tests in progress. >> >> Thanks, >> Jiangli >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Jan 30 01:48:42 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Jan 2015 17:48:42 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> Message-ID: <54CAE2FA.4080705@oracle.com> Hi Jiangli, Thank you for fixing this! Serguei On 1/29/15 5:46 PM, Jiangli Zhou wrote: > Hi Serguei, > > Thanks for noticing that. It?s actually a duplicated bug ID for the > same issue. I just fixed the web rev: > http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/ > . > > Thanks, > Jiangli > > On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com > wrote: > >> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the change for JDK-8071962 >>> , "The SA code >>> needs to be updated to support Symbol lookup from the shared archive?. >>> >>> In JDK-8059510 , >>> we introduced a compact form of hash table for the symbols in shared >>> archive. The shared symbols are stored separately from the regular >>> symbol table. The VM looks up both tables when searching for >>> existing symbol at runtime. The SA code needs to do the same when >>> looking up symbols. >>> >>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>> >> >> Jiangli, >> >> I'm not reviewing, just wanted to make sure there is no typo here ... >> The webrev bug number is 8067977, but the RFR bug number is 8071962 >> which is strange. >> >> Thanks, >> Serguei >> >>> >>> Tested on both 32-bit and 64-bit platforms: >>> bin/java sun.jvm.hotspot.tools.DumpJFR >>> >>> JPRT tests in progress. >>> >>> Thanks, >>> Jiangli >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.qi at oracle.com Fri Jan 30 02:03:12 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Thu, 29 Jan 2015 18:03:12 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> Message-ID: <54CAE660.9060409@oracle.com> Looks good to me. Not a 'R'eviwer. Thanks Yumin On 1/29/2015 5:46 PM, Jiangli Zhou wrote: > Hi Serguei, > > Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. > > Thanks, > Jiangli > > On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: > >> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>> >>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>> >>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >> Jiangli, >> >> I'm not reviewing, just wanted to make sure there is no typo here ... >> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >> >> Thanks, >> Serguei >> >>> Tested on both 32-bit and 64-bit platforms: >>> bin/java sun.jvm.hotspot.tools.DumpJFR >>> >>> JPRT tests in progress. >>> >>> Thanks, >>> Jiangli >>> >>> From jiangli.zhou at oracle.com Fri Jan 30 02:04:41 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 29 Jan 2015 18:04:41 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CAE660.9060409@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CAE660.9060409@oracle.com> Message-ID: <7F37826D-D140-4BC9-A159-84EC394C2B5F@oracle.com> Hi Yumin, Thank you for the quick review! Jiangli On Jan 29, 2015, at 6:03 PM, Yumin Qi wrote: > Looks good to me. Not a 'R'eviwer. > > Thanks > Yumin > > On 1/29/2015 5:46 PM, Jiangli Zhou wrote: >> Hi Serguei, >> >> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >> >> Thanks, >> Jiangli >> >> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >> >>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>> Hi, >>>> >>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>> >>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>> Jiangli, >>> >>> I'm not reviewing, just wanted to make sure there is no typo here ... >>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>> >>> Thanks, >>> Serguei >>> >>>> Tested on both 32-bit and 64-bit platforms: >>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>> >>>> JPRT tests in progress. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> > From serguei.spitsyn at oracle.com Fri Jan 30 07:53:24 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Jan 2015 23:53:24 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> Message-ID: <54CB3874.9030304@oracle.com> Jiangli, The fix looks good. One minor comment/question though. It looks like the comment needs an update as it does not return null anymore if the string has not been found in the symbol table. agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java @@ -74,20 +81,23 @@ /** Clone of VM's "temporary" probe routine, as the SA currently does not support mutation so lookup() would have no effect anyway. Returns null if the given string is not in the symbol table. */ public Symbol probe(byte[] name) { + Symbol sym; long hashValue = hashSymbol(name); for (HashtableEntry e = (HashtableEntry) bucket(hashToIndex(hashValue)); e != null; e = (HashtableEntry) e.next()) { if (e.hash() == hashValue) { - Symbol sym = Symbol.create(e.literalValue()); + sym = Symbol.create(e.literalValue()); if (sym.equals(name)) { return sym; } } } - return null; + + sym = sharedTable.probe(name, hashValue); + return sym; } You may also want to update the copyright comments. Thanks, Serguei On 1/29/15 5:46 PM, Jiangli Zhou wrote: > Hi Serguei, > > Thanks for noticing that. It?s actually a duplicated bug ID for the > same issue. I just fixed the web rev: > http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/ > . > > Thanks, > Jiangli > > On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com > wrote: > >> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the change for JDK-8071962 >>> , "The SA code >>> needs to be updated to support Symbol lookup from the shared archive?. >>> >>> In JDK-8059510 , >>> we introduced a compact form of hash table for the symbols in shared >>> archive. The shared symbols are stored separately from the regular >>> symbol table. The VM looks up both tables when searching for >>> existing symbol at runtime. The SA code needs to do the same when >>> looking up symbols. >>> >>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>> >> >> Jiangli, >> >> I'm not reviewing, just wanted to make sure there is no typo here ... >> The webrev bug number is 8067977, but the RFR bug number is 8071962 >> which is strange. >> >> Thanks, >> Serguei >> >>> >>> Tested on both 32-bit and 64-bit platforms: >>> bin/java sun.jvm.hotspot.tools.DumpJFR >>> >>> JPRT tests in progress. >>> >>> Thanks, >>> Jiangli >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaroslav.bachorik at oracle.com Fri Jan 30 09:34:26 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 10:34:26 +0100 Subject: RFR 8071641: java/lang/management/ThreadMXBean/SynchronizationStatistics.java intermittently failed with NPE In-Reply-To: <54CA58FA.4050104@oracle.com> References: <54CA2FB9.9020108@oracle.com> <54CA3900.6090402@oracle.com> <54CA516C.4090408@oracle.com> <54CA58FA.4050104@oracle.com> Message-ID: <54CB5022.7040508@oracle.com> On 29.1.2015 16:59, shanliang wrote: > Jaroslav Bachorik wrote: >> On 29.1.2015 14:43, shanliang wrote: >>> Jaroslav Bachorik wrote: >>>> Please, review the following test change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8071641 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8071641/webrev.00/ >>>> >>>> The test fails very intermittently with NPE. This seems to be caused >>>> by a data race between Thread.getStatus() and >>>> ThreadMXBean.getThreadInfo() - thread state is reported as BLOCKED but >>>> the ThreadInfo still contains a stale information (lockname == null). >>>> >>>> The solution would be re-retrieving the ThreadInfo until it reflects >>>> the actual thread state. >>>> >>>> -JB- >>> 77 private static void waitForThreadState(Thread t, Thread.State >>> state) throws InterruptedException { >>> 78 while (!t.isInterrupted() && t.getState() != state) { >>> 79 Thread.sleep(3); >>> 80 } >>> 81 } >>> Better to throw an exception if t.isInterrupted()? >>> Not sure when will happen t.isInterrupted(), but the method >>> waitForThreadState tests it, so it is supposed to be possible to get it, >>> when it is true then the testing method might return with a thread state >>> different to the waited one. >> >> Yes, it might get to an undefined state. But given that the thread >> would get interrupted only when the harness is timing out the test >> this discrepancy would not actually matter - the test would fail with >> timeout anyway. > In this case it is useless to test t.isInterrupted() in waitForThreadState. Probably it is. I will remove it before pushing then. -JB- > > Shanliang >> >> -JB- >> >>> >>> Shanliang >>> >>> >> > From mikael.auno at oracle.com Fri Jan 30 09:44:27 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 30 Jan 2015 10:44:27 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) Message-ID: <54CB527B.4060503@oracle.com> Hi, could I please some reviews for this test port? Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 https://bugs.openjdk.java.net/browse/JDK-8071909 Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ Read on for the rationale on a few questions that might arise. * Why two issues? These changes are mainly a port of the Diagnostic Command (DCMD) tests and corresponding framework/utility classes from an internal (non-open) test framework to jtreg. The reason for the two issues is that the changes depend on a few modifications to testlibrary that are available in jdk/test but not yet in hotspot/test, as well as a small new addition to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD tests). To keep the history as clean and coherent as possible, those changes will go in under JDK-8071909 while the new tests and DCMD-related additions to testlibrary go in under JDK-8071908. * Isn't there already utility classes for calling Diagnostic Commands? The main idea with the new utility classes in testlibrary is to provide a single interface to call Diagnostic Commands from tests, regardless of the transport used (e.g. jcmd or JMX). There are a few tests scattered around jdk/test and hotspot/test today that already utilize Diagnostic Commands in some way, but they either use different utility classes for this in different places or just do it directly in the test. Also, some of these utility classes or tests go through jcmd and some through JMX (most often without any real requirement for one transport over the other in the test). All this means that there are, today, numerous different implementations for calling Diagnostic Commands, and consequently a lot of code duplication. These utility classes are meant to replace all of these implementations, and with a single interface regardless of the transport at that. * You've missed this or that test using one of the existing utility classes! This is "by design". In order to keep the change at a more manageable size and to get the core of this change in sooner, we've chosen to do this transition in multiple steps. The first of those steps is what is in this review request; the core utility classes, the tests ported from the internal test framework and the adaption of the tests already in hotspot/test/serviceability/dcmd (since they happened to reside in the directory where we wanted to put the ported tests). When this is integrated and have gone a few rounds through nightly testing, the adaption of other tests in hotspot/test will follow, and after that jdk/test. Thanks, Mikael From jaroslav.bachorik at oracle.com Fri Jan 30 10:18:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 11:18:08 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CB527B.4060503@oracle.com> References: <54CB527B.4060503@oracle.com> Message-ID: <54CB5A60.8020401@oracle.com> Hi Mikael, it's great to see this moving forward! Comments follow: * instead of throwing a RuntimeException from within the test classes you could use o.testng.Assert.fail(...) method * all the newly introduced tests are missing @summary * test/serviceability/dcmd/compiler/CodelistTest.java L43 - unused import L68 - an unused, commented out, line * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java L436-438 - use Arrays.asList() * test/serviceability/dcmd/vm/UptimeTest.java L44 - spurious wakeups may cause the test fail intermittently; should make sure the wait was at least 'someUptime' seconds long -JB- On 30.1.2015 10:44, Mikael Auno wrote: > Hi, could I please some reviews for this test port? > > Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 > https://bugs.openjdk.java.net/browse/JDK-8071909 > Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ > > Read on for the rationale on a few questions that might arise. > > * Why two issues? > > These changes are mainly a port of the Diagnostic Command (DCMD) tests > and corresponding framework/utility classes from an internal (non-open) > test framework to jtreg. The reason for the two issues is that the > changes depend on a few modifications to testlibrary that are available > in jdk/test but not yet in hotspot/test, as well as a small new addition > to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD > tests). To keep the history as clean and coherent as possible, those > changes will go in under JDK-8071909 while the new tests and > DCMD-related additions to testlibrary go in under JDK-8071908. > > * Isn't there already utility classes for calling Diagnostic Commands? > > The main idea with the new utility classes in testlibrary is to provide > a single interface to call Diagnostic Commands from tests, regardless of > the transport used (e.g. jcmd or JMX). There are a few tests scattered > around jdk/test and hotspot/test today that already utilize Diagnostic > Commands in some way, but they either use different utility classes for > this in different places or just do it directly in the test. Also, some > of these utility classes or tests go through jcmd and some through JMX > (most often without any real requirement for one transport over the > other in the test). All this means that there are, today, numerous > different implementations for calling Diagnostic Commands, and > consequently a lot of code duplication. These utility classes are meant > to replace all of these implementations, and with a single interface > regardless of the transport at that. > > * You've missed this or that test using one of the existing utility classes! > > This is "by design". In order to keep the change at a more manageable > size and to get the core of this change in sooner, we've chosen to do > this transition in multiple steps. The first of those steps is what is > in this review request; the core utility classes, the tests ported from > the internal test framework and the adaption of the tests already in > hotspot/test/serviceability/dcmd (since they happened to reside in the > directory where we wanted to put the ported tests). When this is > integrated and have gone a few rounds through nightly testing, the > adaption of other tests in hotspot/test will follow, and after that > jdk/test. > > Thanks, > Mikael > From dmitry.samersoff at oracle.com Fri Jan 30 11:08:52 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 30 Jan 2015 14:08:52 +0300 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: References: Message-ID: <54CB6644.3060705@oracle.com> Jiangli, Looks good for me. SymbolTable.java 97 I would prefer to just return sharedTable.probe(name, hashValue); to avoid unnecessary changes, but it's not a concern - you can leave it as is. -Dmitry On 2015-01-30 04:13, Jiangli Zhou wrote: > Hi, > > Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. > > In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. > > Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ > > Tested on both 32-bit and 64-bit platforms: > bin/java sun.jvm.hotspot.tools.DumpJFR > > JPRT tests in progress. > > Thanks, > Jiangli > > -- 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 erik.gahlin at oracle.com Fri Jan 30 13:20:10 2015 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 30 Jan 2015 14:20:10 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CB527B.4060503@oracle.com> References: <54CB527B.4060503@oracle.com> Message-ID: <54CB850A.9050305@oracle.com> Looks good! Erik Mikael Auno skrev 2015-01-30 10:44: > Hi, could I please some reviews for this test port? > > Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 > https://bugs.openjdk.java.net/browse/JDK-8071909 > Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ > > Read on for the rationale on a few questions that might arise. > > * Why two issues? > > These changes are mainly a port of the Diagnostic Command (DCMD) tests > and corresponding framework/utility classes from an internal (non-open) > test framework to jtreg. The reason for the two issues is that the > changes depend on a few modifications to testlibrary that are available > in jdk/test but not yet in hotspot/test, as well as a small new addition > to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD > tests). To keep the history as clean and coherent as possible, those > changes will go in under JDK-8071909 while the new tests and > DCMD-related additions to testlibrary go in under JDK-8071908. > > * Isn't there already utility classes for calling Diagnostic Commands? > > The main idea with the new utility classes in testlibrary is to provide > a single interface to call Diagnostic Commands from tests, regardless of > the transport used (e.g. jcmd or JMX). There are a few tests scattered > around jdk/test and hotspot/test today that already utilize Diagnostic > Commands in some way, but they either use different utility classes for > this in different places or just do it directly in the test. Also, some > of these utility classes or tests go through jcmd and some through JMX > (most often without any real requirement for one transport over the > other in the test). All this means that there are, today, numerous > different implementations for calling Diagnostic Commands, and > consequently a lot of code duplication. These utility classes are meant > to replace all of these implementations, and with a single interface > regardless of the transport at that. > > * You've missed this or that test using one of the existing utility classes! > > This is "by design". In order to keep the change at a more manageable > size and to get the core of this change in sooner, we've chosen to do > this transition in multiple steps. The first of those steps is what is > in this review request; the core utility classes, the tests ported from > the internal test framework and the adaption of the tests already in > hotspot/test/serviceability/dcmd (since they happened to reside in the > directory where we wanted to put the ported tests). When this is > integrated and have gone a few rounds through nightly testing, the > adaption of other tests in hotspot/test will follow, and after that > jdk/test. > > Thanks, > Mikael From shanliang.jiang at oracle.com Fri Jan 30 17:38:46 2015 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 30 Jan 2015 18:38:46 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54C885DB.50304@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> Message-ID: <54CBC1A6.8090302@oracle.com> Hi, Thanks for all your comments, here is the new version: http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ Mandy Chung wrote: > ManagementFactory.java > line 760: would be helpful to add some comments describing > that the implementation of this method. You can use > MemoryManagerMXBean and GarageCollectorMXBean as the example. Done. > > Comments for the addProxyNames Changed the method name to getProxyNames and added the comments > > line 867: it would be more readable if you break this into > two statements. > List providers = > AccessController.doPrivileged(...); > providers.stream() > .forEachOrdered(...); Done > line 875-886: worths formatting > > line 885 - instead of creating a HashMap and put entry in the > forEach call. > You could have do: > .collect(toMap(PlatformComponent::getObjectNamePattern, > Function.identity()) Yes, as: .collect(toMap(PlatformComponent::getObjectNamePattern, Function.identity(), (p1, p2) -> p1)); > > You could also have the getMap() be called to initialize the > componentMap > static field (i.e. initialize it in the static initializer rather > than lazily > so the providers must be loaded anyway. componentMap is now initialized statically. > > Can you add comments for the PlatformMBeanFinder methods? Yes done > > com/sun/management/internal/PlatformMBeanProviderImpl.java > line 43: does this mxbeanList have to be created lazily? > Would it be better to make it a final field and create it at the > constructor? Done as final > line 58-59, 66-67, 111-112, 118-119: nit formatting > > java/lang/management/DefaultPlatformMBeanProvider.java > line 42: should this mxbeanList be a final field? Done > you can replace java.lang.management.MemoryManagerMXBean.class > with MemoryManagerMXBean.class as it's in the same package. > Same apply to other java.lang.management classes. Done >>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>> line 43: does this mxbeanList have to be created lazily? >>> Would it be better to make it a final field and create it at the >>> constructor? > > These providers will need to be loaded and the mxbeanList will be > looked at except for the cases that we are sure that the MXBean only > comes from the default provider. I see the cost of constructing > mxbeanList involves loading several classes. If performance is an > issue, perhaps the fast-path would be in ManagementFactory to defer > loading providers and may be better to follow up the performance side > in the second phase (that I expect more changes to sun/management > classes) > > You may want to consider using limited doPrivileged (that can be done > in the second phase). OK, now they are final, I will add doPrivileged in next version. Daniel Fuchs wrote: > ManagementFactory.java: > > line 871: there's a stray debug trace that you probably > forgot to remove: > > 871 System.out.println("\n\n===== jsl adding: "+provider); :) > > > lines 877-885: > > I believe it would improved readability if the content of the > forEachOrdered statement was factored out in a private static > method. Something like: > > .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) > > > private static void addToComponentMap( > Map> cmpMap, > PlatformMBeanProvider provider) { > provider.getPlatformComponentList().stream() > .collect(toMap(p -> p.getObjectNamePattern(), p -> p, > (p1, p2) -> { > throw new InternalError(p1.getObjectNamePattern() > + " has been used as key for " + p1 > + ", it cannot be reused for " + p2); > })) > .values() > .stream() // put all components into a map, "putIfAbsent" > .forEach(p -> > cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); > } You must know that code was changed :) > > PlatformMBeanProviderImpl.java: > > 105 * 3 OperatingSystemMXBean > > Not sure what '3' means here - I suggest to remove it. OK Thanks, Shanliang From jiangli.zhou at oracle.com Fri Jan 30 17:43:12 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 09:43:12 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CB3874.9030304@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CB3874.9030304@oracle.com> Message-ID: <55545546-F2CF-420D-BA6A-FCCCAF934FEB@oracle.com> Hi Serguei, Thank you for the review. On Jan 29, 2015, at 11:53 PM, serguei.spitsyn at oracle.com wrote: > Jiangli, > > The fix looks good. > One minor comment/question though. > > It looks like the comment needs an update as it does not return null anymore > if the string has not been found in the symbol table. I?ll update the comments to reflect the latest code. > > agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java > @@ -74,20 +81,23 @@ > /** Clone of VM's "temporary" probe routine, as the SA currently > does not support mutation so lookup() would have no effect > anyway. Returns null if the given string is not in the symbol > table. */ > public Symbol probe(byte[] name) { > + Symbol sym; > long hashValue = hashSymbol(name); > for (HashtableEntry e = (HashtableEntry) bucket(hashToIndex(hashValue)); e != null; e = (HashtableEntry) e.next()) { > if (e.hash() == hashValue) { > - Symbol sym = Symbol.create(e.literalValue()); > + sym = Symbol.create(e.literalValue()); > if (sym.equals(name)) { > return sym; > } > } > } > - return null; > + > + sym = sharedTable.probe(name, hashValue); > + return sym; > } > > > You may also want to update the copyright comments. Yep, will do. David also sent me an offline reminder for the copyright headers. Thanks! Jiangli > > > Thanks, > Serguei > > > On 1/29/15 5:46 PM, Jiangli Zhou wrote: >> Hi Serguei, >> >> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >> >> Thanks, >> Jiangli >> >> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >> >>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>> Hi, >>>> >>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>> >>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>> >>> Jiangli, >>> >>> I'm not reviewing, just wanted to make sure there is no typo here ... >>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Tested on both 32-bit and 64-bit platforms: >>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>> >>>> JPRT tests in progress. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Fri Jan 30 17:46:38 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 09:46:38 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CB6644.3060705@oracle.com> References: <54CB6644.3060705@oracle.com> Message-ID: <76F72114-3A91-4B9F-A735-E7C6719497A8@oracle.com> Hi Dmitry, Thanks for the review. On Jan 30, 2015, at 3:08 AM, Dmitry Samersoff wrote: > Jiangli, > > Looks good for me. > > SymbolTable.java 97 > > I would prefer to just > > return sharedTable.probe(name, hashValue); > > to avoid unnecessary changes, but it's not a concern - you can leave it > as is. Thanks you for the suggestion. Sounds good to me. I?ll make the change and post a new webrev that incorporates everyone?s feedback. Thanks! Jiangli > > -Dmitry > > On 2015-01-30 04:13, Jiangli Zhou wrote: >> Hi, >> >> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >> >> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >> >> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >> >> Tested on both 32-bit and 64-bit platforms: >> bin/java sun.jvm.hotspot.tools.DumpJFR >> >> JPRT tests in progress. >> >> Thanks, >> Jiangli >> >> > > > -- > 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 ioi.lam at oracle.com Fri Jan 30 17:49:36 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 30 Jan 2015 09:49:36 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> Message-ID: <54CBC430.3090508@oracle.com> Hi Jiangli, The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? Thanks - Ioi On 1/29/15, 5:46 PM, Jiangli Zhou wrote: > Hi Serguei, > > Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. > > Thanks, > Jiangli > > On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: > >> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>> >>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>> >>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >> Jiangli, >> >> I'm not reviewing, just wanted to make sure there is no typo here ... >> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >> >> Thanks, >> Serguei >> >>> Tested on both 32-bit and 64-bit platforms: >>> bin/java sun.jvm.hotspot.tools.DumpJFR >>> >>> JPRT tests in progress. >>> >>> Thanks, >>> Jiangli >>> >>> From mikael.auno at oracle.com Fri Jan 30 18:01:50 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 30 Jan 2015 19:01:50 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CB527B.4060503@oracle.com> References: <54CB527B.4060503@oracle.com> Message-ID: <54CBC70E.40005@oracle.com> I found an issue on Windows. DCMD output has Unix newlines even on Windows (and actually mixed Unix and Windows newlines when running through jcmd), so I've updated OutputAnalyzer.asLines() to split on "(\\r\\n|\\n|\\r)" instead of line.separator. I've also added better debug output in CodeCacheTest.java. New webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.01/ Thanks, Mikael On 2015-01-30 10:44, Mikael Auno wrote: > Hi, could I please some reviews for this test port? > > Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 > https://bugs.openjdk.java.net/browse/JDK-8071909 > Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ > > Read on for the rationale on a few questions that might arise. > > * Why two issues? > > These changes are mainly a port of the Diagnostic Command (DCMD) tests > and corresponding framework/utility classes from an internal (non-open) > test framework to jtreg. The reason for the two issues is that the > changes depend on a few modifications to testlibrary that are available > in jdk/test but not yet in hotspot/test, as well as a small new addition > to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD > tests). To keep the history as clean and coherent as possible, those > changes will go in under JDK-8071909 while the new tests and > DCMD-related additions to testlibrary go in under JDK-8071908. > > * Isn't there already utility classes for calling Diagnostic Commands? > > The main idea with the new utility classes in testlibrary is to provide > a single interface to call Diagnostic Commands from tests, regardless of > the transport used (e.g. jcmd or JMX). There are a few tests scattered > around jdk/test and hotspot/test today that already utilize Diagnostic > Commands in some way, but they either use different utility classes for > this in different places or just do it directly in the test. Also, some > of these utility classes or tests go through jcmd and some through JMX > (most often without any real requirement for one transport over the > other in the test). All this means that there are, today, numerous > different implementations for calling Diagnostic Commands, and > consequently a lot of code duplication. These utility classes are meant > to replace all of these implementations, and with a single interface > regardless of the transport at that. > > * You've missed this or that test using one of the existing utility classes! > > This is "by design". In order to keep the change at a more manageable > size and to get the core of this change in sooner, we've chosen to do > this transition in multiple steps. The first of those steps is what is > in this review request; the core utility classes, the tests ported from > the internal test framework and the adaption of the tests already in > hotspot/test/serviceability/dcmd (since they happened to reside in the > directory where we wanted to put the ported tests). When this is > integrated and have gone a few rounds through nightly testing, the > adaption of other tests in hotspot/test will follow, and after that > jdk/test. > > Thanks, > Mikael > From jiangli.zhou at oracle.com Fri Jan 30 18:05:26 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 10:05:26 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CBC430.3090508@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> Message-ID: <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> Hi Ioi, Thanks for the review. On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: > Hi Jiangli, > > The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. Thanks, Jiangli > > Thanks > - Ioi > > On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >> Hi Serguei, >> >> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >> >> Thanks, >> Jiangli >> >> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >> >>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>> Hi, >>>> >>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>> >>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>> Jiangli, >>> >>> I'm not reviewing, just wanted to make sure there is no typo here ... >>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>> >>> Thanks, >>> Serguei >>> >>>> Tested on both 32-bit and 64-bit platforms: >>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>> >>>> JPRT tests in progress. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> > From jaroslav.bachorik at oracle.com Fri Jan 30 18:40:53 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 19:40:53 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBC1A6.8090302@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> Message-ID: <54CBD035.20106@oracle.com> Hi, On 30.1.2015 18:38, shanliang wrote: > Hi, > > Thanks for all your comments, here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ * java/lang/management/ManagementFactory.java L775-788 Can't you use 'return getPlatformComponents().stream().flatMap(p->getProxyNames(p, connection, mxbeanInterface)).distinct().map(name->newPlatformMXBeanProxy(connection, name, mxbeanInterface)).collect(Collectors.toList())' instead of building up a new stream via concat? L846-851 There is no real need to use 'tmp' for validating the object name. Just instantiate the object name within the try block starting at L854 and adjust the catch handler and you are good to go. * sun/management/Flag.java Changes in this class (making certain methods public) do not relate to any other changes in this changeset. Perhaps a mistake? -JB- > > > Mandy Chung wrote: >> ManagementFactory.java >> line 760: would be helpful to add some comments describing >> that the implementation of this method. You can use >> MemoryManagerMXBean and GarageCollectorMXBean as the example. > Done. >> >> Comments for the addProxyNames > Changed the method name to getProxyNames and added the comments >> >> line 867: it would be more readable if you break this into >> two statements. >> List providers = >> AccessController.doPrivileged(...); >> providers.stream() >> .forEachOrdered(...); > Done >> line 875-886: worths formatting >> >> line 885 - instead of creating a HashMap and put entry in the >> forEach call. >> You could have do: >> .collect(toMap(PlatformComponent::getObjectNamePattern, >> Function.identity()) > Yes, as: > .collect(toMap(PlatformComponent::getObjectNamePattern, > Function.identity(), (p1, p2) -> p1)); >> >> You could also have the getMap() be called to initialize the >> componentMap >> static field (i.e. initialize it in the static initializer rather >> than lazily >> so the providers must be loaded anyway. > componentMap is now initialized statically. >> >> Can you add comments for the PlatformMBeanFinder methods? > Yes done >> >> com/sun/management/internal/PlatformMBeanProviderImpl.java >> line 43: does this mxbeanList have to be created lazily? >> Would it be better to make it a final field and create it at the >> constructor? > Done as final >> line 58-59, 66-67, 111-112, 118-119: nit formatting >> >> java/lang/management/DefaultPlatformMBeanProvider.java >> line 42: should this mxbeanList be a final field? > Done >> you can replace java.lang.management.MemoryManagerMXBean.class >> with MemoryManagerMXBean.class as it's in the same package. >> Same apply to other java.lang.management classes. > Done > >>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>> line 43: does this mxbeanList have to be created lazily? >>>> Would it be better to make it a final field and create it at the >>>> constructor? >> >> These providers will need to be loaded and the mxbeanList will be >> looked at except for the cases that we are sure that the MXBean only >> comes from the default provider. I see the cost of constructing >> mxbeanList involves loading several classes. If performance is an >> issue, perhaps the fast-path would be in ManagementFactory to defer >> loading providers and may be better to follow up the performance side >> in the second phase (that I expect more changes to sun/management >> classes) >> >> You may want to consider using limited doPrivileged (that can be done >> in the second phase). > OK, now they are final, I will add doPrivileged in next version. > > > > > Daniel Fuchs wrote: >> ManagementFactory.java: >> >> line 871: there's a stray debug trace that you probably >> forgot to remove: >> >> 871 System.out.println("\n\n===== jsl adding: "+provider); > :) >> >> >> lines 877-885: >> >> I believe it would improved readability if the content of the >> forEachOrdered statement was factored out in a private static >> method. Something like: >> >> .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) >> >> >> private static void addToComponentMap( >> Map> cmpMap, >> PlatformMBeanProvider provider) { >> provider.getPlatformComponentList().stream() >> .collect(toMap(p -> p.getObjectNamePattern(), p -> p, >> (p1, p2) -> { >> throw new InternalError(p1.getObjectNamePattern() >> + " has been used as key for " + p1 >> + ", it cannot be reused for " + p2); >> })) >> .values() >> .stream() // put all components into a map, "putIfAbsent" >> .forEach(p -> >> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); >> } > You must know that code was changed :) >> >> PlatformMBeanProviderImpl.java: >> >> 105 * 3 OperatingSystemMXBean >> >> Not sure what '3' means here - I suggest to remove it. > OK > > Thanks, > Shanliang > From daniel.fuchs at oracle.com Fri Jan 30 18:52:22 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 30 Jan 2015 19:52:22 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBD035.20106@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54CBD035.20106@oracle.com> Message-ID: <54CBD2E6.1090704@oracle.com> Hi Jaroslav, On 30/01/15 19:40, Jaroslav Bachorik wrote: > Hi, > > On 30.1.2015 18:38, shanliang wrote: >> Hi, >> >> Thanks for all your comments, here is the new version: >> http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ > > * java/lang/management/ManagementFactory.java > L775-788 Can't you use 'return > getPlatformComponents().stream().flatMap(p->getProxyNames(p, connection, > mxbeanInterface)).distinct().map(name->newPlatformMXBeanProxy(connection, name, > mxbeanInterface)).collect(Collectors.toList())' instead of building up a > new stream via concat? distinct() is a nice idea - but the crux of the issue is that getProxyNames throws IOException. We could change it to catch IOException and throw UncheckedIOException instead, then catch UncheckedIOException and unwrap it to throw the wrapped IO, but I believe it would end up being more ugly than what we have today... cheers, -- daniel > > L846-851 There is no real need to use 'tmp' for validating the object > name. Just instantiate the object name within the try block starting at > L854 and adjust the catch handler and you are good to go. > > * sun/management/Flag.java > Changes in this class (making certain methods public) do not relate to > any other changes in this changeset. Perhaps a mistake? > > -JB- > >> >> >> Mandy Chung wrote: >>> ManagementFactory.java >>> line 760: would be helpful to add some comments describing >>> that the implementation of this method. You can use >>> MemoryManagerMXBean and GarageCollectorMXBean as the example. >> Done. >>> >>> Comments for the addProxyNames >> Changed the method name to getProxyNames and added the comments >>> >>> line 867: it would be more readable if you break this into >>> two statements. >>> List providers = >>> AccessController.doPrivileged(...); >>> providers.stream() >>> .forEachOrdered(...); >> Done >>> line 875-886: worths formatting >>> >>> line 885 - instead of creating a HashMap and put entry in the >>> forEach call. >>> You could have do: >>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>> Function.identity()) >> Yes, as: >> .collect(toMap(PlatformComponent::getObjectNamePattern, >> Function.identity(), (p1, p2) -> p1)); >>> >>> You could also have the getMap() be called to initialize the >>> componentMap >>> static field (i.e. initialize it in the static initializer rather >>> than lazily >>> so the providers must be loaded anyway. >> componentMap is now initialized statically. >>> >>> Can you add comments for the PlatformMBeanFinder methods? >> Yes done >>> >>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>> line 43: does this mxbeanList have to be created lazily? >>> Would it be better to make it a final field and create it at the >>> constructor? >> Done as final >>> line 58-59, 66-67, 111-112, 118-119: nit formatting >>> >>> java/lang/management/DefaultPlatformMBeanProvider.java >>> line 42: should this mxbeanList be a final field? >> Done >>> you can replace java.lang.management.MemoryManagerMXBean.class >>> with MemoryManagerMXBean.class as it's in the same package. >>> Same apply to other java.lang.management classes. >> Done >> >>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>> line 43: does this mxbeanList have to be created lazily? >>>>> Would it be better to make it a final field and create it at the >>>>> constructor? >>> >>> These providers will need to be loaded and the mxbeanList will be >>> looked at except for the cases that we are sure that the MXBean only >>> comes from the default provider. I see the cost of constructing >>> mxbeanList involves loading several classes. If performance is an >>> issue, perhaps the fast-path would be in ManagementFactory to defer >>> loading providers and may be better to follow up the performance side >>> in the second phase (that I expect more changes to sun/management >>> classes) >>> >>> You may want to consider using limited doPrivileged (that can be done >>> in the second phase). >> OK, now they are final, I will add doPrivileged in next version. >> >> >> >> >> Daniel Fuchs wrote: >>> ManagementFactory.java: >>> >>> line 871: there's a stray debug trace that you probably >>> forgot to remove: >>> >>> 871 System.out.println("\n\n===== jsl adding: "+provider); >> :) >>> >>> >>> lines 877-885: >>> >>> I believe it would improved readability if the content of the >>> forEachOrdered statement was factored out in a private static >>> method. Something like: >>> >>> .forEachOrdered(provider -> addToComponentMap(componentMap, provider)) >>> >>> >>> private static void addToComponentMap( >>> Map> cmpMap, >>> PlatformMBeanProvider provider) { >>> provider.getPlatformComponentList().stream() >>> .collect(toMap(p -> p.getObjectNamePattern(), p -> p, >>> (p1, p2) -> { >>> throw new InternalError(p1.getObjectNamePattern() >>> + " has been used as key for " + p1 >>> + ", it cannot be reused for " + p2); >>> })) >>> .values() >>> .stream() // put all components into a map, "putIfAbsent" >>> .forEach(p -> >>> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); >>> } >> You must know that code was changed :) >>> >>> PlatformMBeanProviderImpl.java: >>> >>> 105 * 3 OperatingSystemMXBean >>> >>> Not sure what '3' means here - I suggest to remove it. >> OK >> >> Thanks, >> Shanliang >> > From jaroslav.bachorik at oracle.com Fri Jan 30 19:05:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 20:05:08 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBD2E6.1090704@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54CBD035.20106@oracle.com> <54CBD2E6.1090704@oracle.com> Message-ID: <54CBD5E4.5030100@oracle.com> On 30.1.2015 19:52, Daniel Fuchs wrote: > Hi Jaroslav, > > On 30/01/15 19:40, Jaroslav Bachorik wrote: >> Hi, >> >> On 30.1.2015 18:38, shanliang wrote: >>> Hi, >>> >>> Thanks for all your comments, here is the new version: >>> http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ >> >> * java/lang/management/ManagementFactory.java >> L775-788 Can't you use 'return >> getPlatformComponents().stream().flatMap(p->getProxyNames(p, connection, >> mxbeanInterface)).distinct().map(name->newPlatformMXBeanProxy(connection, >> name, >> mxbeanInterface)).collect(Collectors.toList())' instead of building up a >> new stream via concat? > > distinct() is a nice idea - but the crux of the issue is that > getProxyNames throws IOException. We could change it to catch > IOException and throw UncheckedIOException instead, then catch > UncheckedIOException and unwrap it to throw the wrapped IO, but > I believe it would end up being more ugly than what we have today... IDK, since getProxyNames() is used only in this particular method, making it throw UncheckedIOException would mean two additional try/catch blocks. And we wouldn't mess with the evaluation optimizations by creating the intermediary set. -JB- > > cheers, > > -- daniel > >> >> L846-851 There is no real need to use 'tmp' for validating the object >> name. Just instantiate the object name within the try block starting at >> L854 and adjust the catch handler and you are good to go. >> >> * sun/management/Flag.java >> Changes in this class (making certain methods public) do not relate to >> any other changes in this changeset. Perhaps a mistake? >> >> -JB- >> >>> >>> >>> Mandy Chung wrote: >>>> ManagementFactory.java >>>> line 760: would be helpful to add some comments describing >>>> that the implementation of this method. You can use >>>> MemoryManagerMXBean and GarageCollectorMXBean as the example. >>> Done. >>>> >>>> Comments for the addProxyNames >>> Changed the method name to getProxyNames and added the comments >>>> >>>> line 867: it would be more readable if you break this into >>>> two statements. >>>> List providers = >>>> AccessController.doPrivileged(...); >>>> providers.stream() >>>> .forEachOrdered(...); >>> Done >>>> line 875-886: worths formatting >>>> >>>> line 885 - instead of creating a HashMap and put entry in the >>>> forEach call. >>>> You could have do: >>>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>>> Function.identity()) >>> Yes, as: >>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>> Function.identity(), (p1, p2) -> p1)); >>>> >>>> You could also have the getMap() be called to initialize the >>>> componentMap >>>> static field (i.e. initialize it in the static initializer rather >>>> than lazily >>>> so the providers must be loaded anyway. >>> componentMap is now initialized statically. >>>> >>>> Can you add comments for the PlatformMBeanFinder methods? >>> Yes done >>>> >>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>> line 43: does this mxbeanList have to be created lazily? >>>> Would it be better to make it a final field and create it at the >>>> constructor? >>> Done as final >>>> line 58-59, 66-67, 111-112, 118-119: nit formatting >>>> >>>> java/lang/management/DefaultPlatformMBeanProvider.java >>>> line 42: should this mxbeanList be a final field? >>> Done >>>> you can replace java.lang.management.MemoryManagerMXBean.class >>>> with MemoryManagerMXBean.class as it's in the same package. >>>> Same apply to other java.lang.management classes. >>> Done >>> >>>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>>> line 43: does this mxbeanList have to be created lazily? >>>>>> Would it be better to make it a final field and create it at the >>>>>> constructor? >>>> >>>> These providers will need to be loaded and the mxbeanList will be >>>> looked at except for the cases that we are sure that the MXBean only >>>> comes from the default provider. I see the cost of constructing >>>> mxbeanList involves loading several classes. If performance is an >>>> issue, perhaps the fast-path would be in ManagementFactory to defer >>>> loading providers and may be better to follow up the performance side >>>> in the second phase (that I expect more changes to sun/management >>>> classes) >>>> >>>> You may want to consider using limited doPrivileged (that can be done >>>> in the second phase). >>> OK, now they are final, I will add doPrivileged in next version. >>> >>> >>> >>> >>> Daniel Fuchs wrote: >>>> ManagementFactory.java: >>>> >>>> line 871: there's a stray debug trace that you probably >>>> forgot to remove: >>>> >>>> 871 System.out.println("\n\n===== jsl adding: "+provider); >>> :) >>>> >>>> >>>> lines 877-885: >>>> >>>> I believe it would improved readability if the content of the >>>> forEachOrdered statement was factored out in a private static >>>> method. Something like: >>>> >>>> .forEachOrdered(provider -> addToComponentMap(componentMap, >>>> provider)) >>>> >>>> >>>> private static void addToComponentMap( >>>> Map> cmpMap, >>>> PlatformMBeanProvider provider) { >>>> provider.getPlatformComponentList().stream() >>>> .collect(toMap(p -> p.getObjectNamePattern(), p -> p, >>>> (p1, p2) -> { >>>> throw new InternalError(p1.getObjectNamePattern() >>>> + " has been used as key for " + p1 >>>> + ", it cannot be reused for " + p2); >>>> })) >>>> .values() >>>> .stream() // put all components into a map, "putIfAbsent" >>>> .forEach(p -> >>>> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); >>>> } >>> You must know that code was changed :) >>>> >>>> PlatformMBeanProviderImpl.java: >>>> >>>> 105 * 3 OperatingSystemMXBean >>>> >>>> Not sure what '3' means here - I suggest to remove it. >>> OK >>> >>> Thanks, >>> Shanliang >>> >> > From mikael.auno at oracle.com Fri Jan 30 19:32:30 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 30 Jan 2015 20:32:30 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CB5A60.8020401@oracle.com> References: <54CB527B.4060503@oracle.com> <54CB5A60.8020401@oracle.com> Message-ID: <54CBDC4E.2010002@oracle.com> Jaroslav, First of all, thanks for the quick response and sorry for my slow one (your message didn't sort into the mail folder I expected, so didn't see it until now). Secondly, all good comments; all fixed. Updated webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.02/ Thanks, Mikael On 2015-01-30 11:18, Jaroslav Bachorik wrote: > Hi Mikael, > > it's great to see this moving forward! > > Comments follow: > > * instead of throwing a RuntimeException from within the test classes > you could use o.testng.Assert.fail(...) method > > * all the newly introduced tests are missing @summary > > * test/serviceability/dcmd/compiler/CodelistTest.java > L43 - unused import > L68 - an unused, commented out, line > > * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java > L436-438 - use Arrays.asList() > > * test/serviceability/dcmd/vm/UptimeTest.java > L44 - spurious wakeups may cause the test fail intermittently; should > make sure the wait was at least 'someUptime' seconds long > > > -JB- > > On 30.1.2015 10:44, Mikael Auno wrote: >> Hi, could I please some reviews for this test port? >> >> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 >> https://bugs.openjdk.java.net/browse/JDK-8071909 >> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ >> >> Read on for the rationale on a few questions that might arise. >> >> * Why two issues? >> >> These changes are mainly a port of the Diagnostic Command (DCMD) tests >> and corresponding framework/utility classes from an internal (non-open) >> test framework to jtreg. The reason for the two issues is that the >> changes depend on a few modifications to testlibrary that are available >> in jdk/test but not yet in hotspot/test, as well as a small new addition >> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD >> tests). To keep the history as clean and coherent as possible, those >> changes will go in under JDK-8071909 while the new tests and >> DCMD-related additions to testlibrary go in under JDK-8071908. >> >> * Isn't there already utility classes for calling Diagnostic Commands? >> >> The main idea with the new utility classes in testlibrary is to provide >> a single interface to call Diagnostic Commands from tests, regardless of >> the transport used (e.g. jcmd or JMX). There are a few tests scattered >> around jdk/test and hotspot/test today that already utilize Diagnostic >> Commands in some way, but they either use different utility classes for >> this in different places or just do it directly in the test. Also, some >> of these utility classes or tests go through jcmd and some through JMX >> (most often without any real requirement for one transport over the >> other in the test). All this means that there are, today, numerous >> different implementations for calling Diagnostic Commands, and >> consequently a lot of code duplication. These utility classes are meant >> to replace all of these implementations, and with a single interface >> regardless of the transport at that. >> >> * You've missed this or that test using one of the existing utility >> classes! >> >> This is "by design". In order to keep the change at a more manageable >> size and to get the core of this change in sooner, we've chosen to do >> this transition in multiple steps. The first of those steps is what is >> in this review request; the core utility classes, the tests ported from >> the internal test framework and the adaption of the tests already in >> hotspot/test/serviceability/dcmd (since they happened to reside in the >> directory where we wanted to put the ported tests). When this is >> integrated and have gone a few rounds through nightly testing, the >> adaption of other tests in hotspot/test will follow, and after that >> jdk/test. >> >> Thanks, >> Mikael >> > From daniel.fuchs at oracle.com Fri Jan 30 19:41:32 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 30 Jan 2015 20:41:32 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBD5E4.5030100@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54CBD035.20106@oracle.com> <54CBD2E6.1090704@oracle.com> <54CBD5E4.5030100@oracle.com> Message-ID: <54CBDE6C.9080207@oracle.com> On 30/01/15 20:05, Jaroslav Bachorik wrote: > On 30.1.2015 19:52, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> On 30/01/15 19:40, Jaroslav Bachorik wrote: >>> Hi, >>> >>> On 30.1.2015 18:38, shanliang wrote: >>>> Hi, >>>> >>>> Thanks for all your comments, here is the new version: >>>> http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ >>> >>> * java/lang/management/ManagementFactory.java >>> L775-788 Can't you use 'return >>> getPlatformComponents().stream().flatMap(p->getProxyNames(p, connection, >>> mxbeanInterface)).distinct().map(name->newPlatformMXBeanProxy(connection, >>> >>> name, >>> mxbeanInterface)).collect(Collectors.toList())' instead of building up a >>> new stream via concat? >> >> distinct() is a nice idea - but the crux of the issue is that >> getProxyNames throws IOException. We could change it to catch >> IOException and throw UncheckedIOException instead, then catch >> UncheckedIOException and unwrap it to throw the wrapped IO, but >> I believe it would end up being more ugly than what we have today... > > IDK, since getProxyNames() is used only in this particular method, > making it throw UncheckedIOException would mean two additional try/catch > blocks. And we wouldn't mess with the evaluation optimizations by > creating the intermediary set. I forgot to mention that newMXBeanProxy also throws an IOException ;-( I wouldn't be too much concerned about performances here. Creation of an intermediary set containing a few names is nothing compared to calling MBeanServerConnection.queryNames. Also it doesn't look like something that could be on the critical path. If we can avoid manipulating exceptions it's IMO much better. best regards, -- daniel > > -JB- > >> >> cheers, >> >> -- daniel >> >>> >>> L846-851 There is no real need to use 'tmp' for validating the object >>> name. Just instantiate the object name within the try block starting at >>> L854 and adjust the catch handler and you are good to go. >>> >>> * sun/management/Flag.java >>> Changes in this class (making certain methods public) do not relate to >>> any other changes in this changeset. Perhaps a mistake? >>> >>> -JB- >>> >>>> >>>> >>>> Mandy Chung wrote: >>>>> ManagementFactory.java >>>>> line 760: would be helpful to add some comments describing >>>>> that the implementation of this method. You can use >>>>> MemoryManagerMXBean and GarageCollectorMXBean as the example. >>>> Done. >>>>> >>>>> Comments for the addProxyNames >>>> Changed the method name to getProxyNames and added the comments >>>>> >>>>> line 867: it would be more readable if you break this into >>>>> two statements. >>>>> List providers = >>>>> AccessController.doPrivileged(...); >>>>> providers.stream() >>>>> .forEachOrdered(...); >>>> Done >>>>> line 875-886: worths formatting >>>>> >>>>> line 885 - instead of creating a HashMap and put entry in the >>>>> forEach call. >>>>> You could have do: >>>>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>>>> Function.identity()) >>>> Yes, as: >>>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>>> Function.identity(), (p1, p2) -> p1)); >>>>> >>>>> You could also have the getMap() be called to initialize the >>>>> componentMap >>>>> static field (i.e. initialize it in the static initializer rather >>>>> than lazily >>>>> so the providers must be loaded anyway. >>>> componentMap is now initialized statically. >>>>> >>>>> Can you add comments for the PlatformMBeanFinder methods? >>>> Yes done >>>>> >>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>> line 43: does this mxbeanList have to be created lazily? >>>>> Would it be better to make it a final field and create it at the >>>>> constructor? >>>> Done as final >>>>> line 58-59, 66-67, 111-112, 118-119: nit formatting >>>>> >>>>> java/lang/management/DefaultPlatformMBeanProvider.java >>>>> line 42: should this mxbeanList be a final field? >>>> Done >>>>> you can replace java.lang.management.MemoryManagerMXBean.class >>>>> with MemoryManagerMXBean.class as it's in the same package. >>>>> Same apply to other java.lang.management classes. >>>> Done >>>> >>>>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>>>> line 43: does this mxbeanList have to be created lazily? >>>>>>> Would it be better to make it a final field and create it at the >>>>>>> constructor? >>>>> >>>>> These providers will need to be loaded and the mxbeanList will be >>>>> looked at except for the cases that we are sure that the MXBean only >>>>> comes from the default provider. I see the cost of constructing >>>>> mxbeanList involves loading several classes. If performance is an >>>>> issue, perhaps the fast-path would be in ManagementFactory to defer >>>>> loading providers and may be better to follow up the performance side >>>>> in the second phase (that I expect more changes to sun/management >>>>> classes) >>>>> >>>>> You may want to consider using limited doPrivileged (that can be done >>>>> in the second phase). >>>> OK, now they are final, I will add doPrivileged in next version. >>>> >>>> >>>> >>>> >>>> Daniel Fuchs wrote: >>>>> ManagementFactory.java: >>>>> >>>>> line 871: there's a stray debug trace that you probably >>>>> forgot to remove: >>>>> >>>>> 871 System.out.println("\n\n===== jsl adding: "+provider); >>>> :) >>>>> >>>>> >>>>> lines 877-885: >>>>> >>>>> I believe it would improved readability if the content of the >>>>> forEachOrdered statement was factored out in a private static >>>>> method. Something like: >>>>> >>>>> .forEachOrdered(provider -> addToComponentMap(componentMap, >>>>> provider)) >>>>> >>>>> >>>>> private static void addToComponentMap( >>>>> Map> cmpMap, >>>>> PlatformMBeanProvider provider) { >>>>> provider.getPlatformComponentList().stream() >>>>> .collect(toMap(p -> p.getObjectNamePattern(), p -> p, >>>>> (p1, p2) -> { >>>>> throw new InternalError(p1.getObjectNamePattern() >>>>> + " has been used as key for " + p1 >>>>> + ", it cannot be reused for " + p2); >>>>> })) >>>>> .values() >>>>> .stream() // put all components into a map, "putIfAbsent" >>>>> .forEach(p -> >>>>> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); >>>>> } >>>> You must know that code was changed :) >>>>> >>>>> PlatformMBeanProviderImpl.java: >>>>> >>>>> 105 * 3 OperatingSystemMXBean >>>>> >>>>> Not sure what '3' means here - I suggest to remove it. >>>> OK >>>> >>>> Thanks, >>>> Shanliang >>>> >>> >> > From jaroslav.bachorik at oracle.com Fri Jan 30 19:48:50 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 20:48:50 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CBDC4E.2010002@oracle.com> References: <54CB527B.4060503@oracle.com> <54CB5A60.8020401@oracle.com> <54CBDC4E.2010002@oracle.com> Message-ID: <54CBE022.20502@oracle.com> Nice! For me it's good to go. -JB- On 30.1.2015 20:32, Mikael Auno wrote: > Jaroslav, > > First of all, thanks for the quick response and sorry for my slow one > (your message didn't sort into the mail folder I expected, so didn't see > it until now). > > Secondly, all good comments; all fixed. > > Updated webrev: > http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.02/ > > Thanks, > Mikael > > On 2015-01-30 11:18, Jaroslav Bachorik wrote: >> Hi Mikael, >> >> it's great to see this moving forward! >> >> Comments follow: >> >> * instead of throwing a RuntimeException from within the test classes >> you could use o.testng.Assert.fail(...) method >> >> * all the newly introduced tests are missing @summary >> >> * test/serviceability/dcmd/compiler/CodelistTest.java >> L43 - unused import >> L68 - an unused, commented out, line >> >> * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java >> L436-438 - use Arrays.asList() >> >> * test/serviceability/dcmd/vm/UptimeTest.java >> L44 - spurious wakeups may cause the test fail intermittently; should >> make sure the wait was at least 'someUptime' seconds long >> >> >> -JB- >> >> On 30.1.2015 10:44, Mikael Auno wrote: >>> Hi, could I please some reviews for this test port? >>> >>> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 >>> https://bugs.openjdk.java.net/browse/JDK-8071909 >>> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ >>> >>> Read on for the rationale on a few questions that might arise. >>> >>> * Why two issues? >>> >>> These changes are mainly a port of the Diagnostic Command (DCMD) tests >>> and corresponding framework/utility classes from an internal (non-open) >>> test framework to jtreg. The reason for the two issues is that the >>> changes depend on a few modifications to testlibrary that are available >>> in jdk/test but not yet in hotspot/test, as well as a small new addition >>> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD >>> tests). To keep the history as clean and coherent as possible, those >>> changes will go in under JDK-8071909 while the new tests and >>> DCMD-related additions to testlibrary go in under JDK-8071908. >>> >>> * Isn't there already utility classes for calling Diagnostic Commands? >>> >>> The main idea with the new utility classes in testlibrary is to provide >>> a single interface to call Diagnostic Commands from tests, regardless of >>> the transport used (e.g. jcmd or JMX). There are a few tests scattered >>> around jdk/test and hotspot/test today that already utilize Diagnostic >>> Commands in some way, but they either use different utility classes for >>> this in different places or just do it directly in the test. Also, some >>> of these utility classes or tests go through jcmd and some through JMX >>> (most often without any real requirement for one transport over the >>> other in the test). All this means that there are, today, numerous >>> different implementations for calling Diagnostic Commands, and >>> consequently a lot of code duplication. These utility classes are meant >>> to replace all of these implementations, and with a single interface >>> regardless of the transport at that. >>> >>> * You've missed this or that test using one of the existing utility >>> classes! >>> >>> This is "by design". In order to keep the change at a more manageable >>> size and to get the core of this change in sooner, we've chosen to do >>> this transition in multiple steps. The first of those steps is what is >>> in this review request; the core utility classes, the tests ported from >>> the internal test framework and the adaption of the tests already in >>> hotspot/test/serviceability/dcmd (since they happened to reside in the >>> directory where we wanted to put the ported tests). When this is >>> integrated and have gone a few rounds through nightly testing, the >>> adaption of other tests in hotspot/test will follow, and after that >>> jdk/test. >>> >>> Thanks, >>> Mikael >>> >> > From jaroslav.bachorik at oracle.com Fri Jan 30 19:54:45 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 30 Jan 2015 20:54:45 +0100 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBDE6C.9080207@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> <54CBD035.20106@oracle.com> <54CBD2E6.1090704@oracle.com> <54CBD5E4.5030100@oracle.com> <54CBDE6C.9080207@oracle.com> Message-ID: <54CBE185.3090409@oracle.com> On 30.1.2015 20:41, Daniel Fuchs wrote: > On 30/01/15 20:05, Jaroslav Bachorik wrote: >> On 30.1.2015 19:52, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> On 30/01/15 19:40, Jaroslav Bachorik wrote: >>>> Hi, >>>> >>>> On 30.1.2015 18:38, shanliang wrote: >>>>> Hi, >>>>> >>>>> Thanks for all your comments, here is the new version: >>>>> http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ >>>> >>>> * java/lang/management/ManagementFactory.java >>>> L775-788 Can't you use 'return >>>> getPlatformComponents().stream().flatMap(p->getProxyNames(p, >>>> connection, >>>> mxbeanInterface)).distinct().map(name->newPlatformMXBeanProxy(connection, >>>> >>>> >>>> name, >>>> mxbeanInterface)).collect(Collectors.toList())' instead of building >>>> up a >>>> new stream via concat? >>> >>> distinct() is a nice idea - but the crux of the issue is that >>> getProxyNames throws IOException. We could change it to catch >>> IOException and throw UncheckedIOException instead, then catch >>> UncheckedIOException and unwrap it to throw the wrapped IO, but >>> I believe it would end up being more ugly than what we have today... >> >> IDK, since getProxyNames() is used only in this particular method, >> making it throw UncheckedIOException would mean two additional try/catch >> blocks. And we wouldn't mess with the evaluation optimizations by >> creating the intermediary set. > > I forgot to mention that newMXBeanProxy also throws an IOException ;-( > I wouldn't be too much concerned about performances here. > Creation of an intermediary set containing a few names is nothing > compared to calling MBeanServerConnection.queryNames. > Also it doesn't look like something that could be on the critical path. > If we can avoid manipulating exceptions it's IMO much better. Ok, I see. With this method being public API it's getting trickier. I still don't like the functional/imperative mix but, as you say, probably less messy then dealing with checked exceptions. -JB- > > best regards, > > -- daniel > >> >> -JB- >> >>> >>> cheers, >>> >>> -- daniel >>> >>>> >>>> L846-851 There is no real need to use 'tmp' for validating the object >>>> name. Just instantiate the object name within the try block starting at >>>> L854 and adjust the catch handler and you are good to go. >>>> >>>> * sun/management/Flag.java >>>> Changes in this class (making certain methods public) do not relate to >>>> any other changes in this changeset. Perhaps a mistake? >>>> >>>> -JB- >>>> >>>>> >>>>> >>>>> Mandy Chung wrote: >>>>>> ManagementFactory.java >>>>>> line 760: would be helpful to add some comments describing >>>>>> that the implementation of this method. You can use >>>>>> MemoryManagerMXBean and GarageCollectorMXBean as the example. >>>>> Done. >>>>>> >>>>>> Comments for the addProxyNames >>>>> Changed the method name to getProxyNames and added the comments >>>>>> >>>>>> line 867: it would be more readable if you break this into >>>>>> two statements. >>>>>> List providers = >>>>>> AccessController.doPrivileged(...); >>>>>> providers.stream() >>>>>> .forEachOrdered(...); >>>>> Done >>>>>> line 875-886: worths formatting >>>>>> >>>>>> line 885 - instead of creating a HashMap and put entry in the >>>>>> forEach call. >>>>>> You could have do: >>>>>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>>>>> Function.identity()) >>>>> Yes, as: >>>>> .collect(toMap(PlatformComponent::getObjectNamePattern, >>>>> Function.identity(), (p1, p2) -> p1)); >>>>>> >>>>>> You could also have the getMap() be called to initialize the >>>>>> componentMap >>>>>> static field (i.e. initialize it in the static initializer rather >>>>>> than lazily >>>>>> so the providers must be loaded anyway. >>>>> componentMap is now initialized statically. >>>>>> >>>>>> Can you add comments for the PlatformMBeanFinder methods? >>>>> Yes done >>>>>> >>>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>>> line 43: does this mxbeanList have to be created lazily? >>>>>> Would it be better to make it a final field and create it at the >>>>>> constructor? >>>>> Done as final >>>>>> line 58-59, 66-67, 111-112, 118-119: nit formatting >>>>>> >>>>>> java/lang/management/DefaultPlatformMBeanProvider.java >>>>>> line 42: should this mxbeanList be a final field? >>>>> Done >>>>>> you can replace java.lang.management.MemoryManagerMXBean.class >>>>>> with MemoryManagerMXBean.class as it's in the same package. >>>>>> Same apply to other java.lang.management classes. >>>>> Done >>>>> >>>>>>>> com/sun/management/internal/PlatformMBeanProviderImpl.java >>>>>>>> line 43: does this mxbeanList have to be created lazily? >>>>>>>> Would it be better to make it a final field and create it at >>>>>>>> the >>>>>>>> constructor? >>>>>> >>>>>> These providers will need to be loaded and the mxbeanList will be >>>>>> looked at except for the cases that we are sure that the MXBean only >>>>>> comes from the default provider. I see the cost of constructing >>>>>> mxbeanList involves loading several classes. If performance is an >>>>>> issue, perhaps the fast-path would be in ManagementFactory to defer >>>>>> loading providers and may be better to follow up the performance side >>>>>> in the second phase (that I expect more changes to sun/management >>>>>> classes) >>>>>> >>>>>> You may want to consider using limited doPrivileged (that can be done >>>>>> in the second phase). >>>>> OK, now they are final, I will add doPrivileged in next version. >>>>> >>>>> >>>>> >>>>> >>>>> Daniel Fuchs wrote: >>>>>> ManagementFactory.java: >>>>>> >>>>>> line 871: there's a stray debug trace that you probably >>>>>> forgot to remove: >>>>>> >>>>>> 871 System.out.println("\n\n===== jsl adding: >>>>>> "+provider); >>>>> :) >>>>>> >>>>>> >>>>>> lines 877-885: >>>>>> >>>>>> I believe it would improved readability if the content of the >>>>>> forEachOrdered statement was factored out in a private static >>>>>> method. Something like: >>>>>> >>>>>> .forEachOrdered(provider -> addToComponentMap(componentMap, >>>>>> provider)) >>>>>> >>>>>> >>>>>> private static void addToComponentMap( >>>>>> Map> cmpMap, >>>>>> PlatformMBeanProvider provider) { >>>>>> provider.getPlatformComponentList().stream() >>>>>> .collect(toMap(p -> p.getObjectNamePattern(), p -> p, >>>>>> (p1, p2) -> { >>>>>> throw new InternalError(p1.getObjectNamePattern() >>>>>> + " has been used as key for " + p1 >>>>>> + ", it cannot be reused for " + p2); >>>>>> })) >>>>>> .values() >>>>>> .stream() // put all components into a map, "putIfAbsent" >>>>>> .forEach(p -> >>>>>> cmpMap.putIfAbsent(p.getObjectNamePattern(), p)); >>>>>> } >>>>> You must know that code was changed :) >>>>>> >>>>>> PlatformMBeanProviderImpl.java: >>>>>> >>>>>> 105 * 3 OperatingSystemMXBean >>>>>> >>>>>> Not sure what '3' means here - I suggest to remove it. >>>>> OK >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>> >>> >> > From mikael.auno at oracle.com Fri Jan 30 20:19:23 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Fri, 30 Jan 2015 21:19:23 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CBE022.20502@oracle.com> References: <54CB527B.4060503@oracle.com> <54CB5A60.8020401@oracle.com> <54CBDC4E.2010002@oracle.com> <54CBE022.20502@oracle.com> Message-ID: <54CBE74B.7040104@oracle.com> Thanks Jaroslav! I'll leave this open for further comments if someone else has them until Monday afternoon (CET). If there are no more comments by then I'll get it pushed at that time. Mikael On 2015-01-30 20:48, Jaroslav Bachorik wrote: > Nice! For me it's good to go. > > -JB- > > On 30.1.2015 20:32, Mikael Auno wrote: >> Jaroslav, >> >> First of all, thanks for the quick response and sorry for my slow one >> (your message didn't sort into the mail folder I expected, so didn't see >> it until now). >> >> Secondly, all good comments; all fixed. >> >> Updated webrev: >> http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.02/ >> >> Thanks, >> Mikael >> >> On 2015-01-30 11:18, Jaroslav Bachorik wrote: >>> Hi Mikael, >>> >>> it's great to see this moving forward! >>> >>> Comments follow: >>> >>> * instead of throwing a RuntimeException from within the test classes >>> you could use o.testng.Assert.fail(...) method >>> >>> * all the newly introduced tests are missing @summary >>> >>> * test/serviceability/dcmd/compiler/CodelistTest.java >>> L43 - unused import >>> L68 - an unused, commented out, line >>> >>> * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java >>> L436-438 - use Arrays.asList() >>> >>> * test/serviceability/dcmd/vm/UptimeTest.java >>> L44 - spurious wakeups may cause the test fail intermittently; should >>> make sure the wait was at least 'someUptime' seconds long >>> >>> >>> -JB- >>> >>> On 30.1.2015 10:44, Mikael Auno wrote: >>>> Hi, could I please some reviews for this test port? >>>> >>>> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 >>>> https://bugs.openjdk.java.net/browse/JDK-8071909 >>>> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ >>>> >>>> Read on for the rationale on a few questions that might arise. >>>> >>>> * Why two issues? >>>> >>>> These changes are mainly a port of the Diagnostic Command (DCMD) tests >>>> and corresponding framework/utility classes from an internal (non-open) >>>> test framework to jtreg. The reason for the two issues is that the >>>> changes depend on a few modifications to testlibrary that are available >>>> in jdk/test but not yet in hotspot/test, as well as a small new >>>> addition >>>> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD >>>> tests). To keep the history as clean and coherent as possible, those >>>> changes will go in under JDK-8071909 while the new tests and >>>> DCMD-related additions to testlibrary go in under JDK-8071908. >>>> >>>> * Isn't there already utility classes for calling Diagnostic Commands? >>>> >>>> The main idea with the new utility classes in testlibrary is to provide >>>> a single interface to call Diagnostic Commands from tests, >>>> regardless of >>>> the transport used (e.g. jcmd or JMX). There are a few tests scattered >>>> around jdk/test and hotspot/test today that already utilize Diagnostic >>>> Commands in some way, but they either use different utility classes for >>>> this in different places or just do it directly in the test. Also, some >>>> of these utility classes or tests go through jcmd and some through JMX >>>> (most often without any real requirement for one transport over the >>>> other in the test). All this means that there are, today, numerous >>>> different implementations for calling Diagnostic Commands, and >>>> consequently a lot of code duplication. These utility classes are meant >>>> to replace all of these implementations, and with a single interface >>>> regardless of the transport at that. >>>> >>>> * You've missed this or that test using one of the existing utility >>>> classes! >>>> >>>> This is "by design". In order to keep the change at a more manageable >>>> size and to get the core of this change in sooner, we've chosen to do >>>> this transition in multiple steps. The first of those steps is what is >>>> in this review request; the core utility classes, the tests ported from >>>> the internal test framework and the adaption of the tests already in >>>> hotspot/test/serviceability/dcmd (since they happened to reside in the >>>> directory where we wanted to put the ported tests). When this is >>>> integrated and have gone a few rounds through nightly testing, the >>>> adaption of other tests in hotspot/test will follow, and after that >>>> jdk/test. >>>> >>>> Thanks, >>>> Mikael >>>> >>> >> > From jiangli.zhou at oracle.com Fri Jan 30 22:31:54 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 14:31:54 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> Message-ID: <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> Here is the updated webrev that incorporates all feedbacks: http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ Thanks, Jiangli On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: > Hi Ioi, > > Thanks for the review. > > On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: > >> Hi Jiangli, >> >> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? > > My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. > > Thanks, > Jiangli > >> >> Thanks >> - Ioi >> >> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>> Hi Serguei, >>> >>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>> >>> Thanks, >>> Jiangli >>> >>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>> >>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>> Hi, >>>>> >>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>> >>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>> Jiangli, >>>> >>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> Tested on both 32-bit and 64-bit platforms: >>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>> >>>>> JPRT tests in progress. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> >> > From yumin.qi at oracle.com Fri Jan 30 22:55:36 2015 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 30 Jan 2015 14:55:36 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> Message-ID: <54CC0BE8.20504@oracle.com> Jiangli, Two minor suggestions (did not pay attention in first round, anyway, no harm): 1) CompactHashtable.java: 58 private static long uintxSize; I did not find the usage of this var, please remove it. 2) + anyway. Searches the regular symbol table and the shared symbol + table. Null is returned if the given string is not in the symbol + tables. */ Maybe better with: "Return null if the given name is not found in both tables." ? No need to send review again if you change. Thanks Yumin On 1/30/2015 2:31 PM, Jiangli Zhou wrote: > Here is the updated webrev that incorporates all feedbacks: > > http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ > > Thanks, > Jiangli > > On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: > >> Hi Ioi, >> >> Thanks for the review. >> >> On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: >> >>> Hi Jiangli, >>> >>> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? >> My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. >> >> Thanks, >> Jiangli >> >>> Thanks >>> - Ioi >>> >>> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>>> Hi Serguei, >>>> >>>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>>> >>>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>>> Jiangli, >>>>> >>>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Tested on both 32-bit and 64-bit platforms: >>>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>>> >>>>>> JPRT tests in progress. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Fri Jan 30 23:12:06 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 15:12:06 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CC0BE8.20504@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> <54CC0BE8.20504@oracle.com> Message-ID: <95F826F5-1754-4791-92BB-826C562DED67@oracle.com> Thank you, Yumin. I incorporated your following suggestions with slight modification for the comment change. Thanks again, Jiangli On Jan 30, 2015, at 2:55 PM, Yumin Qi wrote: > Jiangli, > > Two minor suggestions (did not pay attention in first round, anyway, no harm): > > 1) CompactHashtable.java: > > 58 private static long uintxSize; > > I did not find the usage of this var, please remove it. > > 2) > + anyway. Searches the regular symbol table and the shared symbol > + table. Null is returned if the given string is not in the symbol > + tables. */ > > Maybe better with: "Return null if the given name is not found in both tables." ? > > No need to send review again if you change. > > Thanks > Yumin > > > On 1/30/2015 2:31 PM, Jiangli Zhou wrote: >> Here is the updated webrev that incorporates all feedbacks: >> >> http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ >> >> Thanks, >> Jiangli >> >> On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: >> >>> Hi Ioi, >>> >>> Thanks for the review. >>> >>> On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: >>> >>>> Hi Jiangli, >>>> >>>> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? >>> My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. >>> >>> Thanks, >>> Jiangli >>> >>>> Thanks >>>> - Ioi >>>> >>>> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>>>> >>>>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>>>> Jiangli, >>>>>> >>>>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> Tested on both 32-bit and 64-bit platforms: >>>>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>>>> >>>>>>> JPRT tests in progress. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Jan 31 01:12:28 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 30 Jan 2015 17:12:28 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> Message-ID: <54CC2BFC.9040207@oracle.com> Looks good. Thanks, Serguei On 1/30/15 2:31 PM, Jiangli Zhou wrote: > Here is the updated webrev that incorporates all feedbacks: > > http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ > > Thanks, > Jiangli > > On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: > >> Hi Ioi, >> >> Thanks for the review. >> >> On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: >> >>> Hi Jiangli, >>> >>> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? >> My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. >> >> Thanks, >> Jiangli >> >>> Thanks >>> - Ioi >>> >>> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>>> Hi Serguei, >>>> >>>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>>> >>>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>>> Jiangli, >>>>> >>>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Tested on both 32-bit and 64-bit platforms: >>>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>>> >>>>>> JPRT tests in progress. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> From mandy.chung at oracle.com Sat Jan 31 01:19:07 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jan 2015 17:19:07 -0800 Subject: RFR: 8065213 Specify and implement PlatformMBeanProvider for looking for all platform MBeans In-Reply-To: <54CBC1A6.8090302@oracle.com> References: <54C7CE2A.1090700@oracle.com> <54C885DB.50304@oracle.com> <54CBC1A6.8090302@oracle.com> Message-ID: <54CC2D8B.5080507@oracle.com> On 1/30/2015 9:38 AM, shanliang wrote: > Thanks for all your comments, here is the new version: > http://cr.openjdk.java.net/~sjiang/JDK-8065213/01/ Thank you for the update. Looks fine to me. Minor comment: PlatformMBeanProviderImpl.java line 43: better to rename it as "list" or other name. same as in DefaultPlatformMBeanProvider.java line 54 No need to generate new webrev. Mandy From jiangli.zhou at oracle.com Sat Jan 31 02:09:45 2015 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 30 Jan 2015 18:09:45 -0800 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <54CC2BFC.9040207@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> <54CC2BFC.9040207@oracle.com> Message-ID: <29A449BD-FB93-422D-ABBC-30D329F8CFF6@oracle.com> Hi Serguei, Thanks for double checking it. Pushing the change ? Thanks, Jiangli On Jan 30, 2015, at 5:12 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > On 1/30/15 2:31 PM, Jiangli Zhou wrote: >> Here is the updated webrev that incorporates all feedbacks: >> >> http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ >> >> Thanks, >> Jiangli >> >> On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: >> >>> Hi Ioi, >>> >>> Thanks for the review. >>> >>> On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: >>> >>>> Hi Jiangli, >>>> >>>> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? >>> My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. >>> >>> Thanks, >>> Jiangli >>> >>>> Thanks >>>> - Ioi >>>> >>>> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>>>> >>>>> Thanks, >>>>> Jiangli >>>>> >>>>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>>>> >>>>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>>>> >>>>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>>>> Jiangli, >>>>>> >>>>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> Tested on both 32-bit and 64-bit platforms: >>>>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>>>> >>>>>>> JPRT tests in progress. >>>>>>> >>>>>>> Thanks, >>>>>>> Jiangli >>>>>>> >>>>>>> > From dmitry.samersoff at oracle.com Sat Jan 31 07:22:46 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 31 Jan 2015 10:22:46 +0300 Subject: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive In-Reply-To: <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> References: <54CAE0F3.1050608@oracle.com> <81362112-FB6B-46B7-A948-1FD5DEDACE73@oracle.com> <54CBC430.3090508@oracle.com> <2D1FC65D-65B4-4CFC-947F-0BF3A6F56928@oracle.com> <9E42C0D3-70C3-4929-8D0A-AC9FE74C17A6@oracle.com> Message-ID: <54CC82C6.6070000@oracle.com> Jiangli, Looks good for me! -Dmitry On 2015-01-31 01:31, Jiangli Zhou wrote: > Here is the updated webrev that incorporates all feedbacks: > > http://cr.openjdk.java.net/~jiangli/8071962/webrev.01/ > > Thanks, > Jiangli > > On Jan 30, 2015, at 10:05 AM, Jiangli Zhou wrote: > >> Hi Ioi, >> >> Thanks for the review. >> >> On Jan 30, 2015, at 9:49 AM, Ioi Lam wrote: >> >>> Hi Jiangli, >>> >>> The code looks good. I am wondering if you need a more specific JTREG test for the new sun/jvm/hotspot/utilities/CompactHashTable.java. There's a lot of code in CompactHashTable.java. Will the existing test case in 8071962 provide enough coverage? >> >> My thinking would be yes. The symbol lookup is very foundational operations in sun.jvm.hotspot.tools.DumpJFR. If it fails, it would get exception immediately. We also have JTREG tests that uncovers the SA symbol lookup issue. >> >> Thanks, >> Jiangli >> >>> >>> Thanks >>> - Ioi >>> >>> On 1/29/15, 5:46 PM, Jiangli Zhou wrote: >>>> Hi Serguei, >>>> >>>> Thanks for noticing that. It?s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>> On Jan 29, 2015, at 5:40 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>>> On 1/29/15 5:13 PM, Jiangli Zhou wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the change for JDK-8071962, "The SA code needs to be updated to support Symbol lookup from the shared archive?. >>>>>> >>>>>> In JDK-8059510, we introduced a compact form of hash table for the symbols in shared archive. The shared symbols are stored separately from the regular symbol table. The VM looks up both tables when searching for existing symbol at runtime. The SA code needs to do the same when looking up symbols. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jiangli/8067977/webrev.00/ >>>>> Jiangli, >>>>> >>>>> I'm not reviewing, just wanted to make sure there is no typo here ... >>>>> The webrev bug number is 8067977, but the RFR bug number is 8071962 which is strange. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Tested on both 32-bit and 64-bit platforms: >>>>>> bin/java sun.jvm.hotspot.tools.DumpJFR >>>>>> >>>>>> JPRT tests in progress. >>>>>> >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>> >>> >> > -- 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 goetz.lindenmaier at sap.com Wed Jan 21 10:40:16 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Jan 2015 10:40:16 +0000 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <54B9970B.7040502@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF70D2F@DEWDFEMB12A.global.corp.sap> Hi, could please somebody from servicability sponsor this tiny change? Thanks, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 16. Januar 2015 23:56 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available This seems fine. Someone from the serviceability group should probably sponsor. Thanks, Coleen On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review for this small fix? I also please need a sponsor. > > Thanks, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Montag, 12. Januar 2015 09:23 > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > Hi, > > This test uses SA, thus fails on platforms where that's not implemented. > I see problems on mac and aix. > Call Platform.shouldSAAttach() to check whether SA should work. > > Please review this small fix. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ > > Best regards, > Goetz. From sherrylso at gmail.com Fri Jan 30 11:25:22 2015 From: sherrylso at gmail.com (San Hong Li) Date: Fri, 30 Jan 2015 19:25:22 +0800 Subject: RewriteFrequentPairs flag was disabled in debug model(and discussion for fix) In-Reply-To: <54C7990F.2030309@oracle.com> References: <54C7990F.2030309@oracle.com> Message-ID: Hi, Just add a few more words to explain the benefit on debug experience... If with that fix(hmmm, I just assumed that the fix in previous discussion already covered all the cases to make the RewriteFrequentPairs work in debug mode) we at least give the user another option to enable the RewriteFrequentPairs flag in debug mode, just like we did it for RewriteBytecodes flag, so that the debugger can also inspect these super instructions in interpreter in debug mode. your options? Thanks! San Hong On Tue, Jan 27, 2015 at 9:56 PM, Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Resending to include the Serviceability team since they own JVM/TI... > > Dan > > > On 1/26/15 11:53 PM, San Hong Li wrote: > >> HI All: >> When the JVM is running in debug model, the RewriteFrequentPairs >> optimization will be disabled by following code in >> JvmtiManageCapabilities::update(): >> >> * if (avail.can_generate_breakpoint_events) {* >> * RewriteFrequentPairs = false;* >> * }* >> >> *[ pls. check the above code @Line 328 in jvmtiManageCapabilities.cpp in >> jdk7 codebase]* >> >> I understand the reason why the RewriteFrequentPairs doesn't work in >> debug >> model is that the TOS cache will be disturbed after the execution of >> TemplateTable::aload_0 in such this case, >> >> Let us discuss it in more details about what will happen if we enable >> RewriteFrequentPairs flag in debugging model... >> >> >> The following code was excerpted from TemplateTable::aload_0 >> ( @L789 in templateTable_x86_64.cpp). >> For better discussion, I just skipped irrelevant parts: >> >> *void TemplateTable::aload_0() {* >> * transition(vtos, atos);* >> >> >> * if (RewriteFrequentPairs) {* >> * ...... * >> * // do actual aload_0* >> * aload(0); * >> * ......* >> * // rewrite* >> * // bc: fast bytecode* >> * __ bind(rewrite);* >> * patch_bytecode(Bytecodes::_aload_0, bc, rbx, false);* >> * __ bind(done);* >> * } else {* >> * aload(0);* >> * }* >> *}* >> >> In above code: >> The *aload(0) *happened before * patch_bytecode. * >> The TOS cache will be set correctly after *aload(0) *, that's, the state >> should be atos as we have expected. >> >> But the cache will be corrupted by the following *patch_bytecode >> *which actually >> calls out to InterpreterRuntime::set_original_bytecode_at: >> >> Pls. check the implementation around at L256 in templateTable_x86_64.cpp: >> >> * // Let breakpoint table handling rewrite to quicker bytecode* >> * __ call_VM(noreg, CAST_FROM_FN_PTR(address, >> InterpreterRuntime::set_original_bytecode_at), temp_reg, r13, bc_reg);* >> >> The problem here is: >> The call out into InterpreterRuntime::set_original_bytecode_at will >> eventually change the values cached in RAX. >> >> I would like to discuss and propose a fix for this issue: just do >> the * aload(0) >> *after *patch_bytecode!* >> (actually similar thing we did in TemplateTable::iload) , >> So the updated code with fix likes this: >> >> *void TemplateTable::aload_0() {* >> * transition(vtos, atos);* >> >> >> * if (RewriteFrequentPairs) {* >> * ...... * >> * // do actual aload_0* >> * //aload(0); * >> * ......* >> * // rewrite* >> * // bc: fast bytecode* >> * __ bind(rewrite);* >> * patch_bytecode(Bytecodes::_aload_0, bc, rbx, false);* >> * __ bind(done);* >> * } * >> * // do actual aload_0* >> * __ movptr(rax, aaddress(0)); * >> *}* >> >> So that the TOS has been cached correctly without disruption by >> *patch_bytecode, >> *safe use for next bytecode. >> >> Finally, just a summary for my questions: >> >> Whether or not *this is the only case t*hat explained why the current >> implementation of HotSpot has to disable RewriteFrequentPairs flag in >> debug mode? >> --- If so, how do u think about the fix? I did some tests in my >> environment, it works fine. >> --- if not, would you pls. point out in which case we also have to >> disable RewriteFrequentPairs during debugging? >> >> Thanks! >> San Hong >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: