From igor.ignatyev at oracle.com Sun Apr 2 17:09:08 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 2 Apr 2017 10:09:08 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> Message-ID: <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> Hi, http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next iteration w/ copyright years fixed, LineNumberOnBraceTarg and LambdaBreakpointTest made more unified w/ the rest. Thanks, -- Igor > On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com wrote: > > This one also does not look unified: > http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html > On 3/29/17 11:08, Mikhailo Seledtsov wrote: > > One style nit: > > LineNumberOnBraceTarg: > All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) for line number variables, but this test uses 'stopLine'. > Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. > On Mar 28, 2017, at 6:37 PM, David Holmes wrote: > > Two nits: > - test/com/sun/jdi/FetchLocals.java > - test/com/sun/jdi/LambdaBreakpointTest.java > > Second copyright year should be 2017. > On Mar 24, 2017, at 1:56 PM, Igor Ignatyev wrote: > Hi all, > > could you please review this fix for 8177507? > > due to their nature, some of jdi tests are line number sensitive. unfortunately different tests indicate that differently, so it's quite easy to overlook that and incidentally break tests, for example by changing module dependency declaration or license modification. this fix unifies the way line number sensitivity is indicated and also improves readability/maintainability of some tests by using constant fields instead of magic numbers. > > some of line number sensitive tests have been unexpectedly removed from execution because they had @test/nodynamiccopyright/ instead of @test tag. this changeset fixes and returns them to regular execution. > > webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 > testing: test/com/sun/jdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Apr 2 20:31:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Apr 2017 06:31:34 +1000 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> Message-ID: <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> Hi Igor, On 3/04/2017 3:09 AM, Igor Ignatyev wrote: > Hi, > > http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next > iteration w/ copyright years fixed, test/com/sun/jdi/BreakpointTest.java also needs fixing - says 2015. > LineNumberOnBraceTarg and test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. > LambdaBreakpointTest made more unified w/ the rest. I don't see any change here. Thanks, David ----- > Thanks, > -- Igor > >> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >> wrote: >> >> This one also does not look unified: >> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html > >> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >> >> One style nit: >> >> LineNumberOnBraceTarg: >> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >> for line number variables, but this test uses 'stopLine'. >> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. > >> On Mar 28, 2017, at 6:37 PM, David Holmes > > wrote: >> >> Two nits: >> - test/com/sun/jdi/FetchLocals.java >> - test/com/sun/jdi/LambdaBreakpointTest.java >> >> Second copyright year should be 2017. > >> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev > > wrote: >> Hi all, >> >> could you please review this fix for 8177507? >> >> due to their nature, some of jdi tests are line number sensitive. >> unfortunately different tests indicate that differently, so it's quite >> easy to overlook that and incidentally break tests, for example by >> changing module dependency declaration or license modification. this >> fix unifies the way line number sensitivity is indicated and also >> improves readability/maintainability of some tests by using constant >> fields instead of magic numbers. >> >> some of line number sensitive tests have been unexpectedly removed >> from execution because they had @test/nodynamiccopyright/ instead of >> @test tag. this changeset fixes and returns them to regular execution. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >> testing: test/com/sun/jdi From igor.ignatyev at oracle.com Mon Apr 3 16:46:04 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 3 Apr 2017 09:46:04 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> Message-ID: looks like I have uploaded the webrev before I saved files... uploaded a new webrev w/ all mentioned changes: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 -- Igor > On Apr 2, 2017, at 1:31 PM, David Holmes > wrote: > > Hi Igor, > > On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >> Hi, >> >> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >> iteration w/ copyright years fixed, > > test/com/sun/jdi/BreakpointTest.java > > also needs fixing - says 2015. > >> LineNumberOnBraceTarg and > > test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. > >> LambdaBreakpointTest made more unified w/ the rest. > > I don't see any change here. > > Thanks, > David > ----- > >> Thanks, >> -- Igor >> >>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>> > wrote: >>> >>> This one also does not look unified: >>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >> >>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>> >>> One style nit: >>> >>> LineNumberOnBraceTarg: >>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>> for line number variables, but this test uses 'stopLine'. >>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >> >>> On Mar 28, 2017, at 6:37 PM, David Holmes >>> >> wrote: >>> >>> Two nits: >>> - test/com/sun/jdi/FetchLocals.java >>> - test/com/sun/jdi/LambdaBreakpointTest.java >>> >>> Second copyright year should be 2017. >> >>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>> >> wrote: >>> Hi all, >>> >>> could you please review this fix for 8177507? >>> >>> due to their nature, some of jdi tests are line number sensitive. >>> unfortunately different tests indicate that differently, so it's quite >>> easy to overlook that and incidentally break tests, for example by >>> changing module dependency declaration or license modification. this >>> fix unifies the way line number sensitivity is indicated and also >>> improves readability/maintainability of some tests by using constant >>> fields instead of magic numbers. >>> >>> some of line number sensitive tests have been unexpectedly removed >>> from execution because they had @test/nodynamiccopyright/ instead of >>> @test tag. this changeset fixes and returns them to regular execution. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>> testing: test/com/sun/jdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 3 19:53:36 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 3 Apr 2017 12:53:36 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> Message-ID: <30f9c884-9e75-1fe2-9233-dd9858e2ef5f@oracle.com> Hi Igor, It looks good. Thank you for the update! Thanks, Serguei On 4/3/17 09:46, Igor Ignatyev wrote: > looks like I have uploaded the webrev before I saved files... uploaded > a new webrev w/ all mentioned changes: > http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 > > > -- Igor > >> On Apr 2, 2017, at 1:31 PM, David Holmes > > wrote: >> >> Hi Igor, >> >> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>> Hi, >>> >>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 >>> is the next >>> iteration w/ copyright years fixed, >> >> test/com/sun/jdi/BreakpointTest.java >> >> also needs fixing - says 2015. >> >>> LineNumberOnBraceTarg and >> >> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >> >>> LambdaBreakpointTest made more unified w/ the rest. >> >> I don't see any change here. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> -- Igor >>> >>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>> >>>> wrote: >>>> >>>> This one also does not look unified: >>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>> >>> >>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>> >>>> One style nit: >>>> >>>> LineNumberOnBraceTarg: >>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>> for line number variables, but this test uses 'stopLine'. >>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>> >>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>> >>>> > wrote: >>>> >>>> Two nits: >>>> - test/com/sun/jdi/FetchLocals.java >>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>> >>>> Second copyright year should be 2017. >>> >>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>> >>>> > wrote: >>>> Hi all, >>>> >>>> could you please review this fix for 8177507? >>>> >>>> due to their nature, some of jdi tests are line number sensitive. >>>> unfortunately different tests indicate that differently, so it's quite >>>> easy to overlook that and incidentally break tests, for example by >>>> changing module dependency declaration or license modification. this >>>> fix unifies the way line number sensitivity is indicated and also >>>> improves readability/maintainability of some tests by using constant >>>> fields instead of magic numbers. >>>> >>>> some of line number sensitive tests have been unexpectedly removed >>>> from execution because they had @test/nodynamiccopyright/ instead of >>>> @test tag. this changeset fixes and returns them to regular execution. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>> testing: test/com/sun/jdi > From david.holmes at oracle.com Mon Apr 3 20:53:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 06:53:42 +1000 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> Message-ID: <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> On 4/04/2017 2:46 AM, Igor Ignatyev wrote: > looks like I have uploaded the webrev before I saved files... uploaded a > new webrev w/ all mentioned changes: > http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 I don't see how the change to LambdaBreakpointTest can possibly work. The new test steps to each line in source code order, but that is not the execution order! David ----- > -- Igor > >> On Apr 2, 2017, at 1:31 PM, David Holmes > > wrote: >> >> Hi Igor, >> >> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>> Hi, >>> >>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >>> iteration w/ copyright years fixed, >> >> test/com/sun/jdi/BreakpointTest.java >> >> also needs fixing - says 2015. >> >>> LineNumberOnBraceTarg and >> >> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >> >>> LambdaBreakpointTest made more unified w/ the rest. >> >> I don't see any change here. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> -- Igor >>> >>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>> >>>> wrote: >>>> >>>> This one also does not look unified: >>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>> >>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>> >>>> One style nit: >>>> >>>> LineNumberOnBraceTarg: >>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>> for line number variables, but this test uses 'stopLine'. >>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>> >>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>> >>>> > wrote: >>>> >>>> Two nits: >>>> - test/com/sun/jdi/FetchLocals.java >>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>> >>>> Second copyright year should be 2017. >>> >>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>> >>>> > wrote: >>>> Hi all, >>>> >>>> could you please review this fix for 8177507? >>>> >>>> due to their nature, some of jdi tests are line number sensitive. >>>> unfortunately different tests indicate that differently, so it's quite >>>> easy to overlook that and incidentally break tests, for example by >>>> changing module dependency declaration or license modification. this >>>> fix unifies the way line number sensitivity is indicated and also >>>> improves readability/maintainability of some tests by using constant >>>> fields instead of magic numbers. >>>> >>>> some of line number sensitive tests have been unexpectedly removed >>>> from execution because they had @test/nodynamiccopyright/ instead of >>>> @test tag. this changeset fixes and returns them to regular execution. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>> testing: test/com/sun/jdi > From serguei.spitsyn at oracle.com Mon Apr 3 21:39:01 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 3 Apr 2017 14:39:01 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> Message-ID: On 4/3/17 13:53, David Holmes wrote: > On 4/04/2017 2:46 AM, Igor Ignatyev wrote: >> looks like I have uploaded the webrev before I saved files... uploaded a >> new webrev w/ all mentioned changes: >> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 > > I don't see how the change to LambdaBreakpointTest can possibly work. > The new test steps to each line in source code order, but that is not > the execution order! Nice catch! 62 private static void test() { 63 Runnable r = () -> { // B1: L62 64 String from = "lambda"; // B3: L63 65 System.out.println("Hello from " + from); // B4: L64 66 }; // B5: L65 67 r.run(); // B2: L66 68 System.out.println("Goodbye."); // B6: L67 69 } The B2 breakpoint is at the L66, but B3 is at L63. Thanks, Serguei > > David > ----- > >> -- Igor >> >>> On Apr 2, 2017, at 1:31 PM, David Holmes >> > wrote: >>> >>> Hi Igor, >>> >>> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >>>> iteration w/ copyright years fixed, >>> >>> test/com/sun/jdi/BreakpointTest.java >>> >>> also needs fixing - says 2015. >>> >>>> LineNumberOnBraceTarg and >>> >>> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >>> >>>> LambdaBreakpointTest made more unified w/ the rest. >>> >>> I don't see any change here. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>>> >>>>> wrote: >>>>> >>>>> This one also does not look unified: >>>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>>> >>>> >>>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>>> >>>>> One style nit: >>>>> >>>>> LineNumberOnBraceTarg: >>>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>>> for line number variables, but this test uses 'stopLine'. >>>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>>> >>>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>>> >>>>> > wrote: >>>>> >>>>> Two nits: >>>>> - test/com/sun/jdi/FetchLocals.java >>>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>>> >>>>> Second copyright year should be 2017. >>>> >>>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>> >>>>> > wrote: >>>>> Hi all, >>>>> >>>>> could you please review this fix for 8177507? >>>>> >>>>> due to their nature, some of jdi tests are line number sensitive. >>>>> unfortunately different tests indicate that differently, so it's >>>>> quite >>>>> easy to overlook that and incidentally break tests, for example by >>>>> changing module dependency declaration or license modification. this >>>>> fix unifies the way line number sensitivity is indicated and also >>>>> improves readability/maintainability of some tests by using constant >>>>> fields instead of magic numbers. >>>>> >>>>> some of line number sensitive tests have been unexpectedly removed >>>>> from execution because they had @test/nodynamiccopyright/ instead of >>>>> @test tag. this changeset fixes and returns them to regular >>>>> execution. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>>> testing: test/com/sun/jdi >> From igor.ignatyev at oracle.com Mon Apr 3 23:09:05 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 3 Apr 2017 16:09:05 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> Message-ID: yes, David you are right. it's so embarrassing ... besides uploading webrev w/o all changes, I have also tested it w/o all changes, I should have noticed that. Thank you for catching that. I have fixed that, tested and uploaded new webrev -- http://cr.openjdk.java.net/~iignatyev/8177507/webrev.03 Thanks, -- Igor > On Apr 3, 2017, at 1:53 PM, David Holmes wrote: > > On 4/04/2017 2:46 AM, Igor Ignatyev wrote: >> looks like I have uploaded the webrev before I saved files... uploaded a >> new webrev w/ all mentioned changes: >> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 > > I don't see how the change to LambdaBreakpointTest can possibly work. The new test steps to each line in source code order, but that is not the execution order! > > David > ----- > >> -- Igor >> >>> On Apr 2, 2017, at 1:31 PM, David Holmes >>> >> wrote: >>> >>> Hi Igor, >>> >>> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >>>> iteration w/ copyright years fixed, >>> >>> test/com/sun/jdi/BreakpointTest.java >>> >>> also needs fixing - says 2015. >>> >>>> LineNumberOnBraceTarg and >>> >>> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >>> >>>> LambdaBreakpointTest made more unified w/ the rest. >>> >>> I don't see any change here. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>>> > >>>>> > wrote: >>>>> >>>>> This one also does not look unified: >>>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>> >>>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>>> >>>>> One style nit: >>>>> >>>>> LineNumberOnBraceTarg: >>>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>>> for line number variables, but this test uses 'stopLine'. >>>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>>> >>>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>>>> > >>>>> >> wrote: >>>>> >>>>> Two nits: >>>>> - test/com/sun/jdi/FetchLocals.java >>>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>>> >>>>> Second copyright year should be 2017. >>>> >>>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>>> > >>>>> > wrote: >>>>> Hi all, >>>>> >>>>> could you please review this fix for 8177507? >>>>> >>>>> due to their nature, some of jdi tests are line number sensitive. >>>>> unfortunately different tests indicate that differently, so it's quite >>>>> easy to overlook that and incidentally break tests, for example by >>>>> changing module dependency declaration or license modification. this >>>>> fix unifies the way line number sensitivity is indicated and also >>>>> improves readability/maintainability of some tests by using constant >>>>> fields instead of magic numbers. >>>>> >>>>> some of line number sensitive tests have been unexpectedly removed >>>>> from execution because they had @test/nodynamiccopyright/ instead of >>>>> @test tag. this changeset fixes and returns them to regular execution. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>>> testing: test/com/sun/jdi -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Apr 3 23:28:29 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 3 Apr 2017 16:28:29 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> Message-ID: <85455de5-205e-be05-7e5d-1b6a06edf1b5@oracle.com> It is good now. Thanks, Serguei On 4/3/17 16:09, Igor Ignatyev wrote: > yes, David you are right. it's so embarrassing ... besides uploading > webrev w/o all changes, I have also tested it w/o all changes, I > should have noticed that. Thank you for catching that. > > I have fixed that, tested and uploaded new webrev -- > _http://cr.openjdk.java.net/~iignatyev/8177507/webrev.03 > _ > > Thanks, > -- Igor >> On Apr 3, 2017, at 1:53 PM, David Holmes > > wrote: >> >> On 4/04/2017 2:46 AM, Igor Ignatyev wrote: >>> looks like I have uploaded the webrev before I saved files... uploaded a >>> new webrev w/ all mentioned changes: >>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 >>> >> >> I don't see how the change to LambdaBreakpointTest can possibly work. >> The new test steps to each line in source code order, but that is not >> the execution order! >> >> David >> ----- >> >>> -- Igor >>> >>>> On Apr 2, 2017, at 1:31 PM, David Holmes >>> >>>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>>>> Hi, >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 >>>>> is >>>>> the next >>>>> iteration w/ copyright years fixed, >>>> >>>> test/com/sun/jdi/BreakpointTest.java >>>> >>>> also needs fixing - says 2015. >>>> >>>>> LineNumberOnBraceTarg and >>>> >>>> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >>>> >>>>> LambdaBreakpointTest made more unified w/ the rest. >>>> >>>> I don't see any change here. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Mar 29, 2017, at 12:57 PM,serguei.spitsyn at oracle.com >>>>>> >>>>>> >>>>>> wrote: >>>>>> >>>>>> This one also does not look unified: >>>>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>>>> >>>>> >>>>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>>>> >>>>>> One style nit: >>>>>> >>>>>> LineNumberOnBraceTarg: >>>>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>>>> for line number variables, but this test uses 'stopLine'. >>>>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>>>> >>>>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>>>>> >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Two nits: >>>>>> - test/com/sun/jdi/FetchLocals.java >>>>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>>>> >>>>>> Second copyright year should be 2017. >>>>> >>>>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>>>> >>>>>> >>>>>> > wrote: >>>>>> Hi all, >>>>>> >>>>>> could you please review this fix for 8177507? >>>>>> >>>>>> due to their nature, some of jdi tests are line number sensitive. >>>>>> unfortunately different tests indicate that differently, so it's >>>>>> quite >>>>>> easy to overlook that and incidentally break tests, for example by >>>>>> changing module dependency declaration or license modification. this >>>>>> fix unifies the way line number sensitivity is indicated and also >>>>>> improves readability/maintainability of some tests by using constant >>>>>> fields instead of magic numbers. >>>>>> >>>>>> some of line number sensitive tests have been unexpectedly removed >>>>>> from execution because they had @test/nodynamiccopyright/ instead of >>>>>> @test tag. this changeset fixes and returns them to regular >>>>>> execution. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>>>> testing: test/com/sun/jdi > From david.holmes at oracle.com Mon Apr 3 23:54:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 4 Apr 2017 09:54:12 +1000 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> Message-ID: On 4/04/2017 9:09 AM, Igor Ignatyev wrote: > yes, David you are right. it's so embarrassing ... besides uploading > webrev w/o all changes, I have also tested it w/o all changes, I should > have noticed that. Thank you for catching that. > > I have fixed that, tested and uploaded new webrev -- > _http://cr.openjdk.java.net/~iignatyev/8177507/webrev.03_ Looks fine now. Thanks, David > Thanks, > -- Igor >> On Apr 3, 2017, at 1:53 PM, David Holmes > > wrote: >> >> On 4/04/2017 2:46 AM, Igor Ignatyev wrote: >>> looks like I have uploaded the webrev before I saved files... uploaded a >>> new webrev w/ all mentioned changes: >>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 >> >> I don't see how the change to LambdaBreakpointTest can possibly work. >> The new test steps to each line in source code order, but that is not >> the execution order! >> >> David >> ----- >> >>> -- Igor >>> >>>> On Apr 2, 2017, at 1:31 PM, David Holmes >>> >>>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>>>> Hi, >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >>>>> iteration w/ copyright years fixed, >>>> >>>> test/com/sun/jdi/BreakpointTest.java >>>> >>>> also needs fixing - says 2015. >>>> >>>>> LineNumberOnBraceTarg and >>>> >>>> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >>>> >>>>> LambdaBreakpointTest made more unified w/ the rest. >>>> >>>> I don't see any change here. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>>>> >>>>>> >>>>>> wrote: >>>>>> >>>>>> This one also does not look unified: >>>>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>>> >>>>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>>>> >>>>>> One style nit: >>>>>> >>>>>> LineNumberOnBraceTarg: >>>>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>>>> for line number variables, but this test uses 'stopLine'. >>>>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>>>> >>>>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>>>> >>>>>> >>>>>> > wrote: >>>>>> >>>>>> Two nits: >>>>>> - test/com/sun/jdi/FetchLocals.java >>>>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>>>> >>>>>> Second copyright year should be 2017. >>>>> >>>>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>>>> >>>>>> >>>>>> > wrote: >>>>>> Hi all, >>>>>> >>>>>> could you please review this fix for 8177507? >>>>>> >>>>>> due to their nature, some of jdi tests are line number sensitive. >>>>>> unfortunately different tests indicate that differently, so it's quite >>>>>> easy to overlook that and incidentally break tests, for example by >>>>>> changing module dependency declaration or license modification. this >>>>>> fix unifies the way line number sensitivity is indicated and also >>>>>> improves readability/maintainability of some tests by using constant >>>>>> fields instead of magic numbers. >>>>>> >>>>>> some of line number sensitive tests have been unexpectedly removed >>>>>> from execution because they had @test/nodynamiccopyright/ instead of >>>>>> @test tag. this changeset fixes and returns them to regular execution. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>>>> testing: test/com/sun/jdi > From mikhailo.seledtsov at oracle.com Tue Apr 4 00:01:47 2017 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 03 Apr 2017 17:01:47 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> Message-ID: <58E2E26B.2020006@oracle.com> Looks good to me. Misha On 4/3/17, 4:54 PM, David Holmes wrote: > On 4/04/2017 9:09 AM, Igor Ignatyev wrote: >> yes, David you are right. it's so embarrassing ... besides uploading >> webrev w/o all changes, I have also tested it w/o all changes, I should >> have noticed that. Thank you for catching that. >> >> I have fixed that, tested and uploaded new webrev -- >> _http://cr.openjdk.java.net/~iignatyev/8177507/webrev.03_ > > Looks fine now. > > Thanks, > David > >> Thanks, >> -- Igor >>> On Apr 3, 2017, at 1:53 PM, David Holmes >> > wrote: >>> >>> On 4/04/2017 2:46 AM, Igor Ignatyev wrote: >>>> looks like I have uploaded the webrev before I saved files... >>>> uploaded a >>>> new webrev w/ all mentioned changes: >>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.02 >>> >>> I don't see how the change to LambdaBreakpointTest can possibly work. >>> The new test steps to each line in source code order, but that is not >>> the execution order! >>> >>> David >>> ----- >>> >>>> -- Igor >>>> >>>>> On Apr 2, 2017, at 1:31 PM, David Holmes >>>> >>>>> > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 3/04/2017 3:09 AM, Igor Ignatyev wrote: >>>>>> Hi, >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev//8177507/webrev.01 is the next >>>>>> iteration w/ copyright years fixed, >>>>> >>>>> test/com/sun/jdi/BreakpointTest.java >>>>> >>>>> also needs fixing - says 2015. >>>>> >>>>>> LineNumberOnBraceTarg and >>>>> >>>>> test/com/sun/jdi/LineNumberOnBraceTest.java - Ok. >>>>> >>>>>> LambdaBreakpointTest made more unified w/ the rest. >>>>> >>>>> I don't see any change here. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>>> On Mar 29, 2017, at 12:57 PM, serguei.spitsyn at oracle.com >>>>>>> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> This one also does not look unified: >>>>>>> http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00/test/com/sun/jdi/LambdaBreakpointTest.java.udiff.html >>>>>>> >>>>>> >>>>>>> On 3/29/17 11:08, Mikhailo Seledtsov wrote: >>>>>>> >>>>>>> One style nit: >>>>>>> >>>>>>> LineNumberOnBraceTarg: >>>>>>> All other Java tests use style of CAP_UNDERSCORE (e.g. STOP_LINE) >>>>>>> for line number variables, but this test uses 'stopLine'. >>>>>>> Consider changing it to STOP_LINE (and STOP_LINE_2) to be uniform. >>>>>> >>>>>>> On Mar 28, 2017, at 6:37 PM, David Holmes >>>>>> >>>>>>> >>>>>>> > wrote: >>>>>>> >>>>>>> Two nits: >>>>>>> - test/com/sun/jdi/FetchLocals.java >>>>>>> - test/com/sun/jdi/LambdaBreakpointTest.java >>>>>>> >>>>>>> Second copyright year should be 2017. >>>>>> >>>>>>> On Mar 24, 2017, at 1:56 PM, Igor Ignatyev >>>>>>> >>>>>>> >>>>>>> > wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this fix for 8177507? >>>>>>> >>>>>>> due to their nature, some of jdi tests are line number sensitive. >>>>>>> unfortunately different tests indicate that differently, so it's >>>>>>> quite >>>>>>> easy to overlook that and incidentally break tests, for example by >>>>>>> changing module dependency declaration or license modification. >>>>>>> this >>>>>>> fix unifies the way line number sensitivity is indicated and also >>>>>>> improves readability/maintainability of some tests by using >>>>>>> constant >>>>>>> fields instead of magic numbers. >>>>>>> >>>>>>> some of line number sensitive tests have been unexpectedly removed >>>>>>> from execution because they had @test/nodynamiccopyright/ >>>>>>> instead of >>>>>>> @test tag. this changeset fixes and returns them to regular >>>>>>> execution. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8177507/webrev.00 >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8177507 >>>>>>> testing: test/com/sun/jdi >> From igor.ignatyev at oracle.com Tue Apr 4 00:04:11 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 3 Apr 2017 17:04:11 -0700 Subject: RFR(M) : 8177507 : line number sensitive tests for jdi should be unified In-Reply-To: <58E2E26B.2020006@oracle.com> References: <58DBF832.2010902@oracle.com> <866DB157-A7DB-4CC2-B696-9A3EF3848365@oracle.com> <3d1c3744-c27a-6a9f-1296-d51e9745fa61@oracle.com> <5996e3be-e755-debf-384c-f30b7c8c6ceb@oracle.com> <58E2E26B.2020006@oracle.com> Message-ID: <8CD361AC-1AAB-4A3F-824D-FA566F10D7B1@oracle.com> Misha, David, Serguei, Thank you for review! -- Igor From staffan.larsen at gmail.com Tue Apr 4 07:30:48 2017 From: staffan.larsen at gmail.com (Staffan) Date: Tue, 04 Apr 2017 07:30:48 +0000 Subject: Resigning as Serviceability Group Lead Message-ID: Hi, Since I have recently changed jobs, I will no longer have time to engage in the serviceability side of OpenJDK. Thus I herby resign as the Serviceability Group Lead. Regards, /Staffan -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Apr 4 13:46:32 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 4 Apr 2017 07:46:32 -0600 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn Message-ID: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> I hereby nominate Serguei Spitsyn to Serviceability Group Lead [1]. Serguei is a Reviewer in the jdk10 and jdk9 projects, a Committer in the jdk8u project, a member of the OpenJDK Serviceability Group, and has so far committed > 70 changesets spread across multiple repos in JDK9 alone. Serguei is a longstanding member of the Hotspot Serviceability team, beginning in 2003 as a member of the original Serviceability team. Serguei's contributions to Hotspot are numerous over the years, including implementing features like JVM/TI ForceEarlyReturn, and bug fixes in JDI, JDWP, JVM/TI and java.util.logging API. He has also implemented Solaris pstack utility and dtrace jstack action support: i.e., libjvm_db.so and jhelper.d, and fixed a number of Hotspot non-JVM/TI bugs (e.g., improved time stamps (thread CPU time) on Linux and Solaris). One of Serguei's areas of expertise is class redefinition for which he is a valuable reviewer. He is currently working on Jigsaw native (JVM/TI) and java (java.lang.instrument) agents. Votes are due by April 18, 2017 18:00 PDT. Only current Members of the Serviceability Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Simple Majority voting instructions, see [3]. Thanks, Daniel Daugherty [1]: http://openjdk.java.net/bylaws#group-lead [2]: http://openjdk.java.net/census#serviceability [3]: http://openjdk.java.net/groups#lead-vote From daniel.daugherty at oracle.com Tue Apr 4 13:49:21 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 4 Apr 2017 07:49:21 -0600 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> References: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> Message-ID: Vote: yes Dan On 4/4/17 7:46 AM, Daniel D. Daugherty wrote: > I hereby nominate Serguei Spitsyn to Serviceability Group Lead [1]. > > Serguei is a Reviewer in the jdk10 and jdk9 projects, a Committer in > the jdk8u project, a member of the OpenJDK Serviceability Group, and > has so far committed > 70 changesets spread across multiple repos > in JDK9 alone. > > Serguei is a longstanding member of the Hotspot Serviceability team, > beginning in 2003 as a member of the original Serviceability team. > Serguei's contributions to Hotspot are numerous over the years, > including implementing features like JVM/TI ForceEarlyReturn, and bug > fixes in JDI, JDWP, JVM/TI and java.util.logging API. He has also > implemented Solaris pstack utility and dtrace jstack action support: > i.e., libjvm_db.so and jhelper.d, and fixed a number of Hotspot > non-JVM/TI bugs (e.g., improved time stamps (thread CPU time) on > Linux and Solaris). One of Serguei's areas of expertise is class > redefinition for which he is a valuable reviewer. He is currently > working on Jigsaw native (JVM/TI) and java (java.lang.instrument) > agents. > > Votes are due by April 18, 2017 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote > From tim.bell at oracle.com Tue Apr 4 14:02:34 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 4 Apr 2017 07:02:34 -0700 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> References: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> Message-ID: <86fceb7d-f276-c10d-6813-553588fd4b09@oracle.com> Vote: yes Tim On 04/04/17 06:46, Daniel D. Daugherty wrote: > I hereby nominate Serguei Spitsyn to Serviceability Group Lead From staffan.larsen at gmail.com Tue Apr 4 17:14:51 2017 From: staffan.larsen at gmail.com (Staffan Larsen) Date: Tue, 04 Apr 2017 17:14:51 +0000 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: <86fceb7d-f276-c10d-6813-553588fd4b09@oracle.com> References: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> <86fceb7d-f276-c10d-6813-553588fd4b09@oracle.com> Message-ID: Vote: yes On Tue, 4 Apr 2017 at 16:03 Tim Bell wrote: > Vote: yes > > Tim > > On 04/04/17 06:46, Daniel D. Daugherty wrote: > > I hereby nominate Serguei Spitsyn to Serviceability Group Lead > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Tue Apr 4 17:34:59 2017 From: robert.field at oracle.com (Robert Field) Date: Tue, 04 Apr 2017 10:34:59 -0700 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: References: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> <86fceb7d-f276-c10d-6813-553588fd4b09@oracle.com> Message-ID: <15b3a08adb8.2794.4011f3a8741ca2aabce58b8b81f42d24@oracle.com> Vote: yes On April 4, 2017 10:15:12 AM Staffan Larsen wrote: > Vote: yes > > On Tue, 4 Apr 2017 at 16:03 Tim Bell wrote: > >> Vote: yes >> >> Tim >> >> On 04/04/17 06:46, Daniel D. Daugherty wrote: >> > I hereby nominate Serguei Spitsyn to Serviceability Group Lead >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 4 22:55:03 2017 From: jcbeyler at google.com (JC Beyler) Date: Tue, 4 Apr 2017 15:55:03 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi all, To move the discussion forward, with Chuck Rasbold's help to make a webrev, we pushed this: http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/index.html 415 lines changed: 399 ins; 13 del; 3 mod; 51122 unchg This is not a final change that does the whole proposition from the JBS entry: https://bugs.openjdk.java.net/browse/JDK-8177374; what it does show is parts of the implementation that is proposed and hopefully can start the conversation going as I work through the details. For example, the changes to C2 are done here for the allocations: http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/src/share/vm/opto/macro.cpp.patch Hopefully this all makes sense and thank you for all your future comments! Jc On Tue, Dec 13, 2016 at 1:11 PM, JC Beyler wrote: > Hello all, > > This is a follow-up from Jeremy's initial email from last year: > http://mail.openjdk.java.net/pipermail/serviceability-dev/ > 2015-June/017543.html > > I've gone ahead and started working on preparing this and Jeremy and I > went down the route of actually writing it up in JEP form: > https://bugs.openjdk.java.net/browse/JDK-8171119 > > I think original conversation that happened last year in that thread still > holds true: > > - We have a patch at Google that we think others might be interested in > - It provides a means to understand where the allocation hotspots are > at a very low overhead > - Since it is at a low overhead, we can leave it on by default > > So I come to the mailing list with Jeremy's initial question: > "I thought I would ask if there is any interest / if I should write a JEP > / if I should just forget it." > > A year ago, it seemed some thought it was a good idea, is this still true? > > Thanks, > Jc > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Thu Apr 6 19:50:47 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 6 Apr 2017 22:50:47 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <69f44e02-2690-5643-a5d8-f982a6eac3d2@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> <09941e94-e755-0318-04fa-19117eb14195@oracle.com> <48211785-ef73-2a12-d449-813ea796bc66@oracle.com> <69f44e02-2690-5643-a5d8-f982a6eac3d2@oracle.com> Message-ID: Serguei, 1. New webrev with couple of issues addressed (see Robbin's e-mails): http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.15 2. We have to keep transport version in global variable because old transport doesn't initialize reserved1 field and we are loosing version information after first disconnect. i.e. if I remove this "dancing" debugger is not able to connect second time. I'd reorganized code a bit for better readability. 3. ccc tool doesn't have JDK10 so we can't go forward. -Dmitry On 2017-03-17 12:20, serguei.spitsyn at oracle.com wrote: > Dmitry, > > > Some quick comments on the webrev.12. > > > The style of comments must be /* */, not //. > > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/src/jdk.jdwp.agent/share/native/libjdwp/transport.c.frames.html > > > 205 // Pass MAXIMAL supported version, expect actual transport version in > > Would it better to replace 'MAXIMAL' with 'the latest' ? > > > 516 // interface version 1.0 doesn't support versioning, so we have to > 517 // a use global variable and set the version artifically. > 518 // Use (*t)->extra_data->version directly when 1.0 is gone > > 516: interface => Interface > 517: Typo: a use => use > 518: Dot is missed at the end. > > > 33 static unsigned transportVersion = JDWPTRANSPORT_VERSION_1_0; ... 207 > ver = (*onLoad)(jvm, &callback, JDWPTRANSPORT_VERSION_1_1, &t); > 208 if (ver == JNI_EVERSION) { > 209 ver = (*onLoad)(jvm, &callback, > JDWPTRANSPORT_VERSION_1_0, &t); > 210 // Special handling for versionless transports > 211 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; > 212 } > 213 else { > 214 info->transportVersion = (*t)->extra_data->version; > 215 } ...263 transportVersion = pTransportVersion; ... 459 > info->transportVersion = transportVersion; It is not clear why do you > need the static variable transportVersion and this dance with it. It > seems, the transport version is always enforced by the TransportOnLoad > function anyway. At the line 459, you could just have: > 459 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; Thanks, Serguei > > On 3/17/17 00:03, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, On 3/15/17 00:56, Dmitry Samersoff wrote: >>> Serguei, >>>> I still see the C .vs. C++ related change in the jdwpTransport.h. >>> done. http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/ >> Good. Thank you for the update! >>> see also inline. On 2017-03-15 00:40, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, We already had a big review thread back in 2014 on this. >>>> I think, it is again going in the wrong order. First, I think, it is >>>> better to start from a CCC (or its equivalent, CSR). This will allow >>>> to focus on and sort out the changes in interface/behavior first >>>> before going into the implementation details. >>> CCC was filed and approved. The only reason I withdraw it - the fix >>> didn't go to jdk9 but CCC tool doesn't have jdk10. CSR process is >>> also not yet implemented. >> The CSR preview message from Joe is attached. My understanding is that >> we can continue to use CCC. At some points the CCC process will be >> moved to the CSR. The CCC is out of date now as it does not match the >> webrev 12. Also, I do not like the addition of new function >> StartListening11() next to StartListening(). Does it mean, that for >> transport version 1.2 we might have more function clones with 12 >> suffix? Perhaps, we need something smarter here but I'm unsure yet >> what it has to be. >>>> Second, I'd suggest to separate a couple of other things. I still >>>> see the C .vs. C++ related change in the jdwpTransport.h. It is >>>> better to leave it along for now as it was suggested in early review >>>> rounds. If you still want to fix it then it is better to file a >>>> separate bug that should include the JNI as well (as it was >>>> discussed with Alan before). >>> Do you mean? 39 #ifdef __cplusplus 40 extern "C" { 41 #endif >>> I'll add it back to avoid any confusion. >> Yes. I see you added it back in new version of webrev. >>>> Also, I'm thinking if it is a good idea to separate the transport >>>> versioning to an RFE. It would allow to focus on this aspect as >>>> necessary. In this case, the 8061228 will depend on the versioning. >>>> However, it is much more simple and can be resolved faster. >>> It's hard to test versioning code without implementation of new, >>> VERSION_1_1 transport. Network part of 8061228 is simple and clear >>> separated from versioning, so I would prefer to keep it together in >>> one CR/one push. >> No pressure. I've got your point above. Thanks, Serguei >>> Restriction turned off by default (I'll file separate CR to enable it >>> later), so we have enough time to fix any issues that might come. >>> -Dmitry >>>> Thanks, Serguei On 2/28/17 01:41, Dmitry Samersoff wrote: >>>>> Everybody, Please review: >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ These >>>>> changes introduce new parameter[1] of the socket transport - allow. >>>>> Users can explicitly specify a list of hosts that allowed to >>>>> connect to jdwp server and it's the second part of JDWP >>>>> hardening[2]. No restrictions are applied by default now but I'll >>>>> file a separate CR to restrict list of allowed peers to localhost >>>>> by default. Also these changes implement versioning for jdwp >>>>> transport and therefor simplify feature development of jdwp. 1. >>>>> Example command line: >>>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>>>> address=*,allow="127.0.0.0/8;192.168.0.0/24" Possible values for >>>>> allow parameter: * - accept connections from >>>>> everywhere. N.N.N.N - accept connections from this IP >>>>> address only N.N.N.N/nn - accept connections from particular >>>>> ip subnet 2. JDK-8052136 JDWP hardening -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 Apr 6 19:57:39 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 6 Apr 2017 22:57:39 +0300 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <69f44e02-2690-5643-a5d8-f982a6eac3d2@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <2a9e5128-5c8a-804b-fa21-84c26d4c26a8@oracle.com> <09941e94-e755-0318-04fa-19117eb14195@oracle.com> <48211785-ef73-2a12-d449-813ea796bc66@oracle.com> <69f44e02-2690-5643-a5d8-f982a6eac3d2@oracle.com> Message-ID: <1ff6c2af-17ac-5512-c996-02753803a992@oracle.com> Serguei, (resending lost e-mail) Please, see: http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.15/ Nits fixed. > It is not clear why do you > need the static variable transportVersion and this dance with it. We have to keep transport version in the global variable because void *reserved1; (_extra_data in new code) is not initialized by old transport and we can't rely on it's content but have to keep transport version between subsequent connections. I'd reorganized this part of code a bit for better readability. -Dmitry On 2017-03-17 12:20, serguei.spitsyn at oracle.com wrote: > Dmitry, > > > Some quick comments on the webrev.12. > > > The style of comments must be /* */, not //. > > > http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/src/jdk.jdwp.agent/share/native/libjdwp/transport.c.frames.html > > > 205 // Pass MAXIMAL supported version, expect actual transport version in > > Would it better to replace 'MAXIMAL' with 'the latest' ? > > > 516 // interface version 1.0 doesn't support versioning, so we have to > 517 // a use global variable and set the version artifically. > 518 // Use (*t)->extra_data->version directly when 1.0 is gone > > 516: interface => Interface > 517: Typo: a use => use > 518: Dot is missed at the end. > > > 33 static unsigned transportVersion = JDWPTRANSPORT_VERSION_1_0; ... 207 > ver = (*onLoad)(jvm, &callback, JDWPTRANSPORT_VERSION_1_1, &t); > 208 if (ver == JNI_EVERSION) { > 209 ver = (*onLoad)(jvm, &callback, > JDWPTRANSPORT_VERSION_1_0, &t); > 210 // Special handling for versionless transports > 211 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; > 212 } > 213 else { > 214 info->transportVersion = (*t)->extra_data->version; > 215 } ...263 transportVersion = pTransportVersion; ... 459 > info->transportVersion = transportVersion; It is not clear why do you > need the static variable transportVersion and this dance with it. It > seems, the transport version is always enforced by the TransportOnLoad > function anyway. At the line 459, you could just have: > 459 info->transportVersion = JDWPTRANSPORT_VERSION_1_0; Thanks, Serguei > > On 3/17/17 00:03, serguei.spitsyn at oracle.com wrote: >> Hi Dmitry, On 3/15/17 00:56, Dmitry Samersoff wrote: >>> Serguei, >>>> I still see the C .vs. C++ related change in the jdwpTransport.h. >>> done. http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.12/ >> Good. Thank you for the update! >>> see also inline. On 2017-03-15 00:40, serguei.spitsyn at oracle.com wrote: >>>> Hi Dmitry, We already had a big review thread back in 2014 on this. >>>> I think, it is again going in the wrong order. First, I think, it is >>>> better to start from a CCC (or its equivalent, CSR). This will allow >>>> to focus on and sort out the changes in interface/behavior first >>>> before going into the implementation details. >>> CCC was filed and approved. The only reason I withdraw it - the fix >>> didn't go to jdk9 but CCC tool doesn't have jdk10. CSR process is >>> also not yet implemented. >> The CSR preview message from Joe is attached. My understanding is that >> we can continue to use CCC. At some points the CCC process will be >> moved to the CSR. The CCC is out of date now as it does not match the >> webrev 12. Also, I do not like the addition of new function >> StartListening11() next to StartListening(). Does it mean, that for >> transport version 1.2 we might have more function clones with 12 >> suffix? Perhaps, we need something smarter here but I'm unsure yet >> what it has to be. >>>> Second, I'd suggest to separate a couple of other things. I still >>>> see the C .vs. C++ related change in the jdwpTransport.h. It is >>>> better to leave it along for now as it was suggested in early review >>>> rounds. If you still want to fix it then it is better to file a >>>> separate bug that should include the JNI as well (as it was >>>> discussed with Alan before). >>> Do you mean? 39 #ifdef __cplusplus 40 extern "C" { 41 #endif >>> I'll add it back to avoid any confusion. >> Yes. I see you added it back in new version of webrev. >>>> Also, I'm thinking if it is a good idea to separate the transport >>>> versioning to an RFE. It would allow to focus on this aspect as >>>> necessary. In this case, the 8061228 will depend on the versioning. >>>> However, it is much more simple and can be resolved faster. >>> It's hard to test versioning code without implementation of new, >>> VERSION_1_1 transport. Network part of 8061228 is simple and clear >>> separated from versioning, so I would prefer to keep it together in >>> one CR/one push. >> No pressure. I've got your point above. Thanks, Serguei >>> Restriction turned off by default (I'll file separate CR to enable it >>> later), so we have enough time to fix any issues that might come. >>> -Dmitry >>>> Thanks, Serguei On 2/28/17 01:41, Dmitry Samersoff wrote: >>>>> Everybody, Please review: >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ These >>>>> changes introduce new parameter[1] of the socket transport - allow. >>>>> Users can explicitly specify a list of hosts that allowed to >>>>> connect to jdwp server and it's the second part of JDWP >>>>> hardening[2]. No restrictions are applied by default now but I'll >>>>> file a separate CR to restrict list of allowed peers to localhost >>>>> by default. Also these changes implement versioning for jdwp >>>>> transport and therefor simplify feature development of jdwp. 1. >>>>> Example command line: >>>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>>>> address=*,allow="127.0.0.0/8;192.168.0.0/24" Possible values for >>>>> allow parameter: * - accept connections from >>>>> everywhere. N.N.N.N - accept connections from this IP >>>>> address only N.N.N.N/nn - accept connections from particular >>>>> ip subnet 2. JDK-8052136 JDWP hardening -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 amit.sapre at oracle.com Fri Apr 7 11:57:10 2017 From: amit.sapre at oracle.com (Amit Sapre) Date: Fri, 7 Apr 2017 04:57:10 -0700 (PDT) Subject: RFR : JDK-8176204 - [DOC] ThreadMXBean Fails to Detect ReentrantReadWriteLock Deadlock. Message-ID: <62ff5719-c5b0-440d-8d39-5a258b3f7565@default> Hello, Please review this javadoc updates for java.lang.management.LockInfo class. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8176204 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8176204/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Apr 8 02:40:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 8 Apr 2017 12:40:22 +1000 Subject: RFR : JDK-8176204 - [DOC] ThreadMXBean Fails to Detect ReentrantReadWriteLock Deadlock. In-Reply-To: <62ff5719-c5b0-440d-8d39-5a258b3f7565@default> References: <62ff5719-c5b0-440d-8d39-5a258b3f7565@default> Message-ID: Looks good to me. (But that shouldn't be a surprise :) ). Thanks, David On 7/04/2017 9:57 PM, Amit Sapre wrote: > Hello, > > > > Please review this javadoc updates for java.lang.management.LockInfo class. > > > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8176204 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2017/JDK-8176204/webrev.00/ > > > > Thanks, > > Amit > From shafi.s.ahmad at oracle.com Wed Apr 12 13:39:30 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 12 Apr 2017 06:39:30 -0700 (PDT) Subject: FW: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: Message-ID: <3f3e68c3-eb21-4257-85cb-6e06bb02ee9b@default> Sending it to runtime alias too. Please note that the changes in the test case are done only for testing purpose. It will not be a part of final checkin. Any way attached webrev don't have this change. Regards, Shafi -----Original Message----- From: Shafi Ahmad Sent: Wednesday, April 12, 2017 5:45 PM To: serviceability-dev at openjdk.java.net Cc: Poonam Parhar Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() Hi, Please review the trivial code change for the fix of 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent()' to jdk10. Summary: In method exportMBeanServer of sun/management/jmxremote/ConnectorBootstrap.java, we wrap IOException in AgentConfigurationError. But in jdk/internal/agent/Agent.java this exception is caught and the wrapped exception is ignored. We just prints the error message and not the stack trace and ignores the wrapped exception. With the current code, we are getting message without the stack trace that caused this failure: STDERR: Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) We should fix this code to print information about the original exception as well. jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 webrev link: http://cr.openjdk.java.net/~shshahma/8177721/webrev.00/ I have unit tested the code change with the existing test case by doing below change in test case: diff -r 3696d4c26897 test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java --- a/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Tue Apr 11 11:24:12 2017 +0200 +++ b/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Wed Apr 12 02:51:01 2017 -0700 @@ -36,7 +36,7 @@ * @run build JvmstatCountersTest * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 1 * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote JvmstatCountersTest 2 - * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 + * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=2 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 4 */ We are getting below error message with the fix for the above modified test case: STDERR: Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:481) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:452) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:626) Caused by: java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:232) at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:202) at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:187) at jdk.management.agent/sun.management.jmxremote.SingleEntryRegistry.(SingleEntryRegistry.java:48) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:817) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:469) ... 2 more Caused by: java.net.BindException: Permission denied (Bind failed) at java.base/java.net.PlainSocketImpl.socketBind(Native Method) at java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:437) at java.base/java.net.ServerSocket.bind(ServerSocket.java:381) at java.base/java.net.ServerSocket.(ServerSocket.java:243) at java.base/java.net.ServerSocket.(ServerSocket.java:135) at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) ... 11 more I have run the jprt testset core and results are fine. Regards, Shafi From shafi.s.ahmad at oracle.com Wed Apr 12 12:14:35 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 12 Apr 2017 05:14:35 -0700 (PDT) Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() Message-ID: Hi, Please review the trivial code change for the fix of 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent()' to jdk10. Summary: In method exportMBeanServer of sun/management/jmxremote/ConnectorBootstrap.java, we wrap IOException in AgentConfigurationError. But in jdk/internal/agent/Agent.java this exception is caught and the wrapped exception is ignored. We just prints the error message and not the stack trace and ignores the wrapped exception. With the current code, we are getting message without the stack trace that caused this failure: STDERR: Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) We should fix this code to print information about the original exception as well. jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 webrev link: http://cr.openjdk.java.net/~shshahma/8177721/webrev.00/ I have unit tested the code change with the existing test case by doing below change in test case: diff -r 3696d4c26897 test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java --- a/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Tue Apr 11 11:24:12 2017 +0200 +++ b/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Wed Apr 12 02:51:01 2017 -0700 @@ -36,7 +36,7 @@ * @run build JvmstatCountersTest * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 1 * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote JvmstatCountersTest 2 - * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 + * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=2 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 4 */ We are getting below error message with the fix for the above modified test case: STDERR: Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:481) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:452) at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:626) Caused by: java.rmi.server.ExportException: Port already in use: 2; nested exception is: java.net.BindException: Permission denied (Bind failed) at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:232) at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:202) at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:187) at jdk.management.agent/sun.management.jmxremote.SingleEntryRegistry.(SingleEntryRegistry.java:48) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:817) at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:469) ... 2 more Caused by: java.net.BindException: Permission denied (Bind failed) at java.base/java.net.PlainSocketImpl.socketBind(Native Method) at java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:437) at java.base/java.net.ServerSocket.bind(ServerSocket.java:381) at java.base/java.net.ServerSocket.(ServerSocket.java:243) at java.base/java.net.ServerSocket.(ServerSocket.java:135) at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) ... 11 more I have run the jprt testset core and results are fine. Regards, Shafi From david.holmes at oracle.com Thu Apr 13 01:15:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 11:15:20 +1000 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: Message-ID: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> Hi Shafi, On 12/04/2017 10:14 PM, Shafi Ahmad wrote: > Hi, > > Please review the trivial code change for the fix of 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent()' to jdk10. > > Summary: > In method exportMBeanServer of sun/management/jmxremote/ConnectorBootstrap.java, we wrap IOException in AgentConfigurationError. > But in jdk/internal/agent/Agent.java this exception is caught and the wrapped exception is ignored. > We just prints the error message and not the stack trace and ignores the wrapped exception. I don't think this is the best way to fix this. You are basically extracting the other exception's stacktrace into a string and then using that string to print out (and some of the output seems to be doubled up). Instead of: 456 } catch (AgentConfigurationError e) { 457 error(e.getError(), e.getParams()); the error(e) variant could be called, which can then extract any additional info needed from an AgentConfigurationError, print it and then call printStackTrace, which will print the ACE stack plus the stack of any exception set as a cause. Overall the exception management in this code looks like it predate the existence of an "exception cause" and should probably be updated to utilize that more effectively. Thanks, David ----- > With the current code, we are getting message without the stack trace that caused this failure: > > STDERR: > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: > java.net.BindException: Permission denied (Bind failed) > > We should fix this code to print information about the original exception as well. > > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 > webrev link: http://cr.openjdk.java.net/~shshahma/8177721/webrev.00/ > > I have unit tested the code change with the existing test case by doing below change in test case: > > diff -r 3696d4c26897 test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java > --- a/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Tue Apr 11 11:24:12 2017 +0200 > +++ b/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java Wed Apr 12 02:51:01 2017 -0700 > @@ -36,7 +36,7 @@ > * @run build JvmstatCountersTest > * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 1 > * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote JvmstatCountersTest 2 > - * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 > + * @run main/othervm/timeout=600 -XX:+UsePerfData -Dcom.sun.management.jmxremote.port=2 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 > * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 4 > */ > > > We are getting below error message with the fix for the above modified test case: > > STDERR: > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 2; nested exception is: > java.net.BindException: Permission denied (Bind failed) > jdk.internal.agent.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 2; nested exception is: > java.net.BindException: Permission denied (Bind failed) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:481) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:452) > at jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:626) > Caused by: java.rmi.server.ExportException: Port already in use: 2; nested exception is: > java.net.BindException: Permission denied (Bind failed) > at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) > at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) > at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) > at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) > at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:232) > at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:202) > at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:187) > at jdk.management.agent/sun.management.jmxremote.SingleEntryRegistry.(SingleEntryRegistry.java:48) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:817) > at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:469) > ... 2 more > Caused by: java.net.BindException: Permission denied (Bind failed) > at java.base/java.net.PlainSocketImpl.socketBind(Native Method) > at java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:437) > at java.base/java.net.ServerSocket.bind(ServerSocket.java:381) > at java.base/java.net.ServerSocket.(ServerSocket.java:243) > at java.base/java.net.ServerSocket.(ServerSocket.java:135) > at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) > at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) > at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) > ... 11 more > > I have run the jprt testset core and results are fine. > > Regards, > Shafi > From david.holmes at oracle.com Thu Apr 13 01:18:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Apr 2017 11:18:22 +1000 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> Message-ID: <100300bd-afb5-44c1-a979-b0856e8ad4a7@oracle.com> Adding back runtime On 13/04/2017 11:15 AM, David Holmes wrote: > Hi Shafi, > > On 12/04/2017 10:14 PM, Shafi Ahmad wrote: >> Hi, >> >> Please review the trivial code change for the fix of 'JDK-8177721: >> Improve diagnostics in sun.management.Agent#startAgent()' to jdk10. >> >> Summary: >> In method exportMBeanServer of >> sun/management/jmxremote/ConnectorBootstrap.java, we wrap IOException >> in AgentConfigurationError. >> But in jdk/internal/agent/Agent.java this exception is caught and the >> wrapped exception is ignored. >> We just prints the error message and not the stack trace and ignores >> the wrapped exception. > > I don't think this is the best way to fix this. You are basically > extracting the other exception's stacktrace into a string and then using > that string to print out (and some of the output seems to be doubled up). > > Instead of: > > 456 } catch (AgentConfigurationError e) { > 457 error(e.getError(), e.getParams()); > > the error(e) variant could be called, which can then extract any > additional info needed from an AgentConfigurationError, print it and > then call printStackTrace, which will print the ACE stack plus the stack > of any exception set as a cause. > > Overall the exception management in this code looks like it predate the > existence of an "exception cause" and should probably be updated to > utilize that more effectively. > > Thanks, > David > ----- > >> With the current code, we are getting message without the stack trace >> that caused this failure: >> >> STDERR: >> Error: Exception thrown by the agent : >> java.rmi.server.ExportException: Port already in use: 2; nested >> exception is: >> java.net.BindException: Permission denied (Bind failed) >> >> We should fix this code to print information about the original >> exception as well. >> >> jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 >> webrev link: http://cr.openjdk.java.net/~shshahma/8177721/webrev.00/ >> >> I have unit tested the code change with the existing test case by >> doing below change in test case: >> >> diff -r 3696d4c26897 >> test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java >> --- >> a/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java >> Tue Apr 11 11:24:12 2017 +0200 >> +++ >> b/test/sun/management/jmxremote/bootstrap/JvmstatCountersTest.java >> Wed Apr 12 02:51:01 2017 -0700 >> @@ -36,7 +36,7 @@ >> * @run build JvmstatCountersTest >> * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 1 >> * @run main/othervm/timeout=600 -XX:+UsePerfData >> -Dcom.sun.management.jmxremote JvmstatCountersTest 2 >> - * @run main/othervm/timeout=600 -XX:+UsePerfData >> -Dcom.sun.management.jmxremote.port=0 >> -Dcom.sun.management.jmxremote.authenticate=false >> -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 >> + * @run main/othervm/timeout=600 -XX:+UsePerfData >> -Dcom.sun.management.jmxremote.port=2 >> -Dcom.sun.management.jmxremote.authenticate=false >> -Dcom.sun.management.jmxremote.ssl=false JvmstatCountersTest 3 >> * @run main/othervm/timeout=600 -XX:+UsePerfData JvmstatCountersTest 4 >> */ >> >> >> We are getting below error message with the fix for the above >> modified test case: >> >> STDERR: >> Error: Exception thrown by the agent : >> java.rmi.server.ExportException: Port already in use: 2; nested >> exception is: >> java.net.BindException: Permission denied (Bind failed) >> jdk.internal.agent.AgentConfigurationError: >> java.rmi.server.ExportException: Port already in use: 2; nested >> exception is: >> java.net.BindException: Permission denied (Bind failed) >> at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:481) >> >> at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:452) >> at >> jdk.management.agent/jdk.internal.agent.Agent.startAgent(Agent.java:626) >> Caused by: java.rmi.server.ExportException: Port already in use: 2; >> nested exception is: >> java.net.BindException: Permission denied (Bind failed) >> at >> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:340) >> at >> java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:248) >> >> at >> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) >> >> at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) >> at >> java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:232) >> >> at >> java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:202) >> at >> java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:187) >> at >> jdk.management.agent/sun.management.jmxremote.SingleEntryRegistry.(SingleEntryRegistry.java:48) >> >> at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:817) >> >> at >> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:469) >> >> ... 2 more >> Caused by: java.net.BindException: Permission denied (Bind failed) >> at java.base/java.net.PlainSocketImpl.socketBind(Native Method) >> at >> java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:437) >> >> at java.base/java.net.ServerSocket.bind(ServerSocket.java:381) >> at java.base/java.net.ServerSocket.(ServerSocket.java:243) >> at java.base/java.net.ServerSocket.(ServerSocket.java:135) >> at >> java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) >> >> at >> java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) >> >> at >> java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:329) >> ... 11 more >> >> I have run the jprt testset core and results are fine. >> >> Regards, >> Shafi >> From daniel.fuchs at oracle.com Thu Apr 13 09:25:01 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Apr 2017 10:25:01 +0100 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> Message-ID: <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> On 13/04/2017 02:15, David Holmes wrote: > Overall the exception management in this code looks like it predate the > existence of an "exception cause" and should probably be updated to > utilize that more effectively. Hi David, I think the original idea was to display a localized message to the end user - and not frighten him with a big unlocalized stack trace. But I otherwise agree with your suggestion. best regards, -- daniel From ujwal.vangapally at oracle.com Fri Apr 14 06:25:48 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Fri, 14 Apr 2017 11:55:48 +0530 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out Message-ID: Please review this small change https://bugs.openjdk.java.net/browse/JDK-8130084 Webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ Thanks, Ujwal. From daniel.fuchs at oracle.com Fri Apr 14 10:36:02 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Apr 2017 11:36:02 +0100 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: References: Message-ID: Hi Ujwal, This looks good to me. It should make the test more reliable. best regards, -- daniel On 14/04/2017 07:25, Ujwal Vangapally wrote: > Please review this small change > > https://bugs.openjdk.java.net/browse/JDK-8130084 > > Webrev: > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ > > Thanks, > > Ujwal. > From ujwal.vangapally at oracle.com Fri Apr 14 10:58:08 2017 From: ujwal.vangapally at oracle.com (ujwal) Date: Fri, 14 Apr 2017 16:28:08 +0530 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: Message-ID: <681b4f8e-c5f7-4897-bb75-745947c517b0@email.android.com> An HTML attachment was scrubbed... URL: From tomas.hurka at googlemail.com Fri Apr 14 17:20:56 2017 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Fri, 14 Apr 2017 19:20:56 +0200 Subject: CFV: New Serviceability Group Lead: Serguei Spitsyn In-Reply-To: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> References: <06e7bcff-a316-99e6-901f-3e44c1af1b51@oracle.com> Message-ID: <67A587D8-CE04-4C27-8E8C-852B2B62632C@googlemail.com> Vote: yes > On 4 Apr 2017, at 15:46, Daniel D. Daugherty wrote: > > I hereby nominate Serguei Spitsyn to Serviceability Group Lead [1]. > > Serguei is a Reviewer in the jdk10 and jdk9 projects, a Committer in > the jdk8u project, a member of the OpenJDK Serviceability Group, and > has so far committed > 70 changesets spread across multiple repos > in JDK9 alone. > > Serguei is a longstanding member of the Hotspot Serviceability team, > beginning in 2003 as a member of the original Serviceability team. > Serguei's contributions to Hotspot are numerous over the years, > including implementing features like JVM/TI ForceEarlyReturn, and bug > fixes in JDI, JDWP, JVM/TI and java.util.logging API. He has also > implemented Solaris pstack utility and dtrace jstack action support: > i.e., libjvm_db.so and jhelper.d, and fixed a number of Hotspot > non-JVM/TI bugs (e.g., improved time stamps (thread CPU time) on > Linux and Solaris). One of Serguei's areas of expertise is class > redefinition for which he is a valuable reviewer. He is currently > working on Jigsaw native (JVM/TI) and java (java.lang.instrument) > agents. > > Votes are due by April 18, 2017 18:00 PDT. > > Only current Members of the Serviceability Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Simple Majority voting instructions, see [3]. > > Thanks, > Daniel Daugherty > > [1]: http://openjdk.java.net/bylaws#group-lead > [2]: http://openjdk.java.net/census#serviceability > [3]: http://openjdk.java.net/groups#lead-vote -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.github.io Software Developer Oracle, Praha Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Apr 14 22:54:26 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Apr 2017 15:54:26 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: Hi Katya, looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. Thanks, -- Igor > On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: > > Hi everyone, > > Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java > This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() > as part of JDK-8178347. > Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. > > bug: https://bugs.openjdk.java.net/browse/JDK-8178731 > webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ > > Tested by running jprt. > > thanks, > -katya > > p.s. > Igor Ignatyev volunteered to sponsor this change. From serguei.spitsyn at oracle.com Fri Apr 14 23:42:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 14 Apr 2017 16:42:45 -0700 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: Hi Katya, It looks good. Thanks, Serguei On 4/14/17 15:54, Igor Ignatyev wrote: > Hi Katya, > > looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. > > Thanks, > -- Igor > >> On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: >> >> Hi everyone, >> >> Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java >> This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() >> as part of JDK-8178347. >> Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8178731 >> webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ >> >> Tested by running jprt. >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. From dmitry.samersoff at oracle.com Sun Apr 16 10:36:33 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 16 Apr 2017 13:36:33 +0300 Subject: RFR(S) 8178731: compiler/ciReplay/SABase.java does not compile In-Reply-To: References: <4c83e586-1c10-1bae-eb18-6d6b1b7bd286@oracle.com> Message-ID: <6c2abd5f-6df5-e4ee-74a9-aafc0575eea0@oracle.com> Katya, Looks good to me. -Dmitry On 2017-04-15 01:54, Igor Ignatyev wrote: > Hi Katya, > > looks good to me. since it also changes svc tests, I cc'ed svc-dev alias. > > Thanks, > -- Igor > >> On Apr 14, 2017, at 3:52 PM, Ekaterina Pavlova wrote: >> >> Hi everyone, >> >> Please review this small change that fixes hotspot/test/compiler/ciReplay/SABase.java >> This file used ProcessHandle.getPid() which was recently renamed in ProcessHandle.pid() >> as part of JDK-8178347. >> Also fixed test/serviceability/sa/sadebugd/SADebugDTest.java which had the same issue. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8178731 >> webrev: http://cr.openjdk.java.net/~iignatyev/epavlova/8178731/webrev.00/ >> >> Tested by running jprt. >> >> thanks, >> -katya >> >> p.s. >> Igor Ignatyev volunteered to sponsor this change. > -- 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 jcbeyler at google.com Mon Apr 17 19:37:02 2017 From: jcbeyler at google.com (JC Beyler) Date: Mon, 17 Apr 2017 12:37:02 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi all, I worked on getting a few numbers for overhead and accuracy for my feature. I'm unsure if here is the right place to provide the full data, so I am just summarizing here for now. - Overhead of the feature Using the Dacapo benchmark (http://dacapobench.org/). My initial results are that sampling provides 2.4% with a 512k sampling, 512k being our default setting. - Note: this was without the tradesoap, tradebeans and tomcat benchmarks since they did not work with my JDK9 (issue between Dacapo and JDK9 it seems) - I want to rerun next week to ensure number stability - Accuracy of the feature I wrote a small microbenchmark that allocates from two different stacktraces at a given ratio. For example, 10% of stacktrace S1 and 90% from stacktrace S2. The microbenchmark was run 20 times, I averaged the results and looked for accuracy. It seems that statistically it is sound since if I allocated10% S1 and 90% S2, with a sampling rate of 512k, I obtained 9.61% S1 and 90.49% S2. Let me know if there are any questions on the numbers and if you'd like to see some more data. Note: this was done using our internal JDK8 implementation since the webrev provided by http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/index.html does not yet contain the whole implementation and therefore would have been misleading. Thanks, Jc On Tue, Apr 4, 2017 at 3:55 PM, JC Beyler wrote: > Hi all, > > To move the discussion forward, with Chuck Rasbold's help to make a > webrev, we pushed this: > http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/index.html > 415 lines changed: 399 ins; 13 del; 3 mod; 51122 unchg > > This is not a final change that does the whole proposition from the JBS > entry: https://bugs.openjdk.java.net/browse/JDK-8177374; what it does > show is parts of the implementation that is proposed and hopefully can > start the conversation going as I work through the details. > > For example, the changes to C2 are done here for the allocations: > http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/src/share/vm/ > opto/macro.cpp.patch > > Hopefully this all makes sense and thank you for all your future comments! > Jc > > > On Tue, Dec 13, 2016 at 1:11 PM, JC Beyler wrote: > >> Hello all, >> >> This is a follow-up from Jeremy's initial email from last year: >> http://mail.openjdk.java.net/pipermail/serviceability-dev/20 >> 15-June/017543.html >> >> I've gone ahead and started working on preparing this and Jeremy and I >> went down the route of actually writing it up in JEP form: >> https://bugs.openjdk.java.net/browse/JDK-8171119 >> >> I think original conversation that happened last year in that thread >> still holds true: >> >> - We have a patch at Google that we think others might be interested in >> - It provides a means to understand where the allocation hotspots are >> at a very low overhead >> - Since it is at a low overhead, we can leave it on by default >> >> So I come to the mailing list with Jeremy's initial question: >> "I thought I would ask if there is any interest / if I should write a >> JEP / if I should just forget it." >> >> A year ago, it seemed some thought it was a good idea, is this still true? >> >> Thanks, >> Jc >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Apr 18 04:20:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 14:20:33 +1000 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: References: Message-ID: Hi Ujwal, On 14/04/2017 4:25 PM, Ujwal Vangapally wrote: > Please review this small change > > https://bugs.openjdk.java.net/browse/JDK-8130084 > > Webrev: > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ I agree with Daniel this makes the test less susceptible to spurious timeouts and will instead only be timed-out by the test harness. One additional comment though is that it now seems to serve no point to create a separate thread to do the work. ?? Thanks, David > Thanks, > > Ujwal. > From daniel.fuchs at oracle.com Tue Apr 18 10:39:32 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 18 Apr 2017 11:39:32 +0100 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: References: Message-ID: <275f6926-fa48-97d5-1d79-8aa43bdb9321@oracle.com> On 18/04/2017 05:20, David Holmes wrote: > Hi Ujwal, > > On 14/04/2017 4:25 PM, Ujwal Vangapally wrote: >> Please review this small change >> >> https://bugs.openjdk.java.net/browse/JDK-8130084 >> >> Webrev: >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ > > I agree with Daniel this makes the test less susceptible to spurious > timeouts and will instead only be timed-out by the test harness. Hi David, > One additional comment though is that it now seems to serve no point to > create a separate thread to do the work. ?? AFAICS the test attempts to tease the JMX notification logic to produce a deadlock. I believe we would have to go back to the original bug description and make a careful analysis of the original issue to assert whether or not creating that thread was integral to the issue being tested (or if it was just a way to not wait infinitely). So all in all I think I'm more comfortable with not removing that thread and leaving the fix as it is ;-) best regards, -- daniel > > Thanks, > David > From david.holmes at oracle.com Tue Apr 18 12:09:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Apr 2017 22:09:03 +1000 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: <275f6926-fa48-97d5-1d79-8aa43bdb9321@oracle.com> References: <275f6926-fa48-97d5-1d79-8aa43bdb9321@oracle.com> Message-ID: <61faa5e4-4dfa-d731-2230-eb56a67b4074@oracle.com> Hi Daniel, On 18/04/2017 8:39 PM, Daniel Fuchs wrote: > On 18/04/2017 05:20, David Holmes wrote: >> Hi Ujwal, >> >> On 14/04/2017 4:25 PM, Ujwal Vangapally wrote: >>> Please review this small change >>> >>> https://bugs.openjdk.java.net/browse/JDK-8130084 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ >> >> I agree with Daniel this makes the test less susceptible to spurious >> timeouts and will instead only be timed-out by the test harness. > > Hi David, > >> One additional comment though is that it now seems to serve no point to >> create a separate thread to do the work. ?? > > AFAICS the test attempts to tease the JMX notification logic to > produce a deadlock. I believe we would have to go back to the original > bug description and make a careful analysis of the original issue > to assert whether or not creating that thread was integral to > the issue being tested (or if it was just a way to not wait > infinitely). You are absolutely right - it does need the second thread to ensure there is no deadlock. Thanks, David ----- > So all in all I think I'm more comfortable with not removing that > thread and leaving the fix as it is ;-) > > best regards, > > -- daniel > >> >> Thanks, >> David >> > From Alan.Bateman at oracle.com Wed Apr 19 13:01:23 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Apr 2017 14:01:23 +0100 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: On 19/04/2017 13:54, Magnus Ihse Bursie wrote: > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html > is no longer included in the generated documentation. The information > provided by that file should move to > src/jdk.jdi/share/classes/module-info.java instead. > > I also took the liberty of removing a bunch of other overview.html > files that are not included in the Javadoc anymore. They provided no > real informational value, and what text they contained is already > expressed similarly or better in the corresponding module-info.java > files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 The serviceability-dev mailing list is the best place to discuss the debugger API. However, what you have looks okay. I think I would use the opportunity to replace "The JDI" with just "JDI" in the second and third paragraphs. -Alan From robbin.ehn at oracle.com Wed Apr 19 14:37:59 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 19 Apr 2017 16:37:59 +0200 Subject: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only In-Reply-To: <41366a7c-f92d-b02f-01e3-85832c1086db@oracle.com> References: <62f06838-ca7b-4dbf-3a32-f82518d33b41@oracle.com> <320d4094-b65a-3f59-2324-b53d86161e9c@oracle.com> <41366a7c-f92d-b02f-01e3-85832c1086db@oracle.com> Message-ID: <6dd68930-84a3-4065-4bf6-b8d7e0a17f6a@oracle.com> Hi Dmitry, sorry for the delay. Yes thanks, everything seems to work. Code looks reasonable. /Robbin On 03/29/2017 05:10 PM, Dmitry Samersoff wrote: > Robbin, > >> One follow-up issue is that if you start suspended >> and than connect with >> an unallowed client the JVM starts and executes the program. > > Fixed. > > see http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.15 > > -Dmitry > > On 2017-03-16 15:59, Robbin Ehn wrote: >> Hi Dmitry, thanks for the update. >> >> One follow-up issue is that if you start suspended and than connect with >> an unallowed client the JVM starts and executes the program. >> Simple program prints "Hello". >> >> [rehn at rehn-ws vanilla-hs]$ java >> -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:9999,allow=1.2.3.0/32 >> -cp . H >> Listening for transport dt_socket at address: 9999 >> ERROR: Peer not allowed to connect >> Listening for transport dt_socket at address: 9999 >> Hello >> >> I think it would be good if the VM stayed suspended when an unallowed >> client connects. >> >> Thanks, Robbin >> >> On 03/13/2017 08:07 PM, Dmitry Samersoff wrote: >>> Robbin, >>> >>> Please, see: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.11 >>> >>>> 1: >>>> So connecting with an unallowed client terminates the VM. >>> >>> Fixed. >>> >>>> 2: >>>> Starting with an bad allow filter terminates the VM when connecting a >>>> client. >>> >>> Moved allowed parameter (and parser call) to StartListening. >>> >>> -Dmitry >>> >>> >>> On 2017-03-10 15:56, Robbin Ehn wrote: >>>> Hi Dmitry, >>>> >>>> I took a look at this, I have two practical issues: >>>> >>>> 1: >>>> [rehn at rehn-ws dev]$ java >>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.6.6.6 >>>> >>>> -cp runs ForEver >>>> Listening for transport dt_socket at address: 9999 >>>> ERROR: transport error 202: peer not allowed to connect: Success >>>> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >>>> error [transport.c:358] >>>> >>>> So connecting with an unallowed client terminates the VM. >>>> >>>> 2: >>>> [rehn at rehn-ws dev]$ java >>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:9999,allow=6.BAD.6.6 >>>> >>>> -cp runs ForEver >>>> Listening for transport dt_socket at address: 9999 >>>> ERROR: transport error 202: unable to parse list of allowed peers: >>>> Success >>>> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal >>>> error [transport.c:358] >>>> >>>> Starting with an bad allow filter terminates the VM when connecting a >>>> client. >>>> >>>> >>>> Connecting with an unallowed ip/port should not terminate the VM and we >>>> should verify allow filter directly at startup. >>>> >>>> Thanks >>>> >>>> /Robbin >>>> >>>> On 02/28/2017 10:41 AM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8061228/webrev.10/ >>>>> >>>>> These changes introduce new parameter[1] of the socket transport - >>>>> allow. Users can explicitly specify a list of hosts that allowed to >>>>> connect to jdwp server and it's the second part of JDWP hardening[2]. >>>>> >>>>> No restrictions are applied by default now but I'll file a separate CR >>>>> to restrict list of allowed peers to localhost by default. >>>>> >>>>> Also these changes implement versioning for jdwp transport and therefor >>>>> simplify feature development of jdwp. >>>>> >>>>> >>>>> 1. Example command line: >>>>> >>>>> -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, >>>>> address=*,allow="127.0.0.0/8;192.168.0.0/24" >>>>> >>>>> Possible values for allow parameter: >>>>> * - accept connections from everywhere. >>>>> N.N.N.N - accept connections from this IP address only >>>>> N.N.N.N/nn - accept connections from particular ip subnet >>>>> >>>>> >>>>> >>>>> 2. JDK-8052136 JDWP hardening >>>>> >>>>> -Dmitry >>>>> >>> >>> > > From daniel.daugherty at oracle.com Wed Apr 19 16:13:53 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 19 Apr 2017 10:13:53 -0600 Subject: Result: New Serviceability Group Lead: Serguei Spitsyn Message-ID: <8bf2ab7d-79a7-567a-65c1-8f5b1ed6aaa3@oracle.com> The vote for Serguei Spitsyn [1] is now closed. Yes: 5 No: 0 Abstain: 0 According to the Bylaws definition of Simple Majority[2], this is sufficient to approve the new Group Lead. The OpenJDK Lead will ask the Governing Board to ratify this nomination. Daniel Daugherty [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/021177.html [2] http://openjdk.java.net/bylaws#simple-majority Quoted here for convenience: > Simple Majority ? There are more Yes votes than No votes. From mandy.chung at oracle.com Wed Apr 19 16:40:32 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Apr 2017 09:40:32 -0700 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: <38E8D569-C58F-4573-A630-A175EEABE240@oracle.com> > On Apr 19, 2017, at 5:54 AM, Magnus Ihse Bursie wrote: > > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes/module-info.java instead. > > I also took the liberty of removing a bunch of other overview.html files that are not included in the Javadoc anymore. They provided no real informational value, and what text they contained is already expressed similarly or better in the corresponding module-info.java files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 Moving the content from jdi-overview.html to module-info.java is the right choice. Nit: if you don?t mind, can you replace ? with {@code ?} Otherwise, looks fine. The following sentence reads a little strange to me that contains a couple of ???. I just want to point it out and we should leave it as is. 36 * The JDI also provides explicit control over a virtual machine's execution. 37 * The ability to suspend and resume threads, and to set breakpoints, 38 * watchpoints, ... Notification of exceptions, class loading, thread 39 * creation... The ability to inspect a suspended thread's state, local 40 * variables, stack backtrace? Mandy From david.holmes at oracle.com Thu Apr 20 02:21:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 12:21:21 +1000 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> Message-ID: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: > With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html > is no longer included in the generated documentation. The information > provided by that file should move to > src/jdk.jdi/share/classes/module-info.java instead. Looks good, but highlighted an error with the existing text: /** * Defines the Java Debugger Interface. + *

+ * The Java™ Debug Interface (JDI) is a high level Java API providing The first line should read "Debug" not "Debugger". Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" should be replaced by "The JDI". Thanks, David > I also took the liberty of removing a bunch of other overview.html files > that are not included in the Javadoc anymore. They provided no real > informational value, and what text they contained is already expressed > similarly or better in the corresponding module-info.java files instead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 > > > /Magnus > From magnus.ihse.bursie at oracle.com Thu Apr 20 07:57:54 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Apr 2017 09:57:54 +0200 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> Message-ID: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> On 2017-04-20 04:21, David Holmes wrote: > On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: >> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html >> is no longer included in the generated documentation. The information >> provided by that file should move to >> src/jdk.jdi/share/classes/module-info.java instead. > > Looks good, but highlighted an error with the existing text: > > /** > * Defines the Java Debugger Interface. > + *

> + * The Java™ Debug Interface (JDI) is a high level Java API > providing > > The first line should read "Debug" not "Debugger". Good catch. I really didn't plan to make any editorial changes in this review, only to move the contents to a place were it was once again included. However, the text was apparently in need of some freshing up, so I tried to fix what was pointed out. > > Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" > should be replaced by "The JDI". I love it when I get conflicting reviews! ;-) I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds weird, and that's not how acronyms are typically referred to. So I've sided with Alan here. If you don't agree, I'll back out that change and you can fight it out by yourselves. :) And Mandy: I agree with the weird ellipses. I changed that to "etc.", which I think captures the intent that the list was not exhaustive. Here is an updated review. It fixes the "Debugger" in the title, "The JDI" -> "JDI" in two places, "..." -> "etc." and -> {@code}. http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ /Magnus > > Thanks, > David > >> I also took the liberty of removing a bunch of other overview.html files >> that are not included in the Javadoc anymore. They provided no real >> informational value, and what text they contained is already expressed >> similarly or better in the corresponding module-info.java files instead. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 >> >> >> >> /Magnus >> From david.holmes at oracle.com Thu Apr 20 08:25:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Apr 2017 18:25:53 +1000 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> Message-ID: On 20/04/2017 5:57 PM, Magnus Ihse Bursie wrote: > On 2017-04-20 04:21, David Holmes wrote: >> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote: >>> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html >>> is no longer included in the generated documentation. The information >>> provided by that file should move to >>> src/jdk.jdi/share/classes/module-info.java instead. >> >> Looks good, but highlighted an error with the existing text: >> >> /** >> * Defines the Java Debugger Interface. >> + *

>> + * The Java™ Debug Interface (JDI) is a high level Java API >> providing >> >> The first line should read "Debug" not "Debugger". > > Good catch. > > I really didn't plan to make any editorial changes in this review, only > to move the contents to a place were it was once again included. > However, the text was apparently in need of some freshing up, so I tried > to fix what was pointed out. > >> >> Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" >> should be replaced by "The JDI". > > I love it when I get conflicting reviews! ;-) > > I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds > weird, and that's not how acronyms are typically referred to. So I've > sided with Alan here. If you don't agree, I'll back out that change and > you can fight it out by yourselves. :) It depends on the exact nature of the acronym. If you wrote this out you would say "The Java Debug Interface .." hence you should say "The JDI ...". :) Cheers, David ----- > And Mandy: I agree with the weird ellipses. I changed that to "etc.", > which I think captures the intent that the list was not exhaustive. > > Here is an updated review. It fixes the "Debugger" in the title, "The > JDI" -> "JDI" in two places, "..." -> "etc." and -> {@code}. > > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ > > > /Magnus > >> >> Thanks, >> David >> >>> I also took the liberty of removing a bunch of other overview.html files >>> that are not included in the Javadoc anymore. They provided no real >>> informational value, and what text they contained is already expressed >>> similarly or better in the corresponding module-info.java files instead. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 >>> >>> >>> >>> /Magnus >>> > From mandy.chung at oracle.com Thu Apr 20 14:56:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 07:56:18 -0700 Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi module-info.java In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com> <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com> <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com> Message-ID: <55B9D093-687F-428E-8DD1-DFA9D1F2A8C2@oracle.com> > On Apr 20, 2017, at 12:57 AM, Magnus Ihse Bursie wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/ Looks good. Mandy From sharath.ballal at oracle.com Fri Apr 21 12:32:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 21 Apr 2017 05:32:14 -0700 (PDT) Subject: RFR: JDK-8030750 - SA: alternate hashing not implemented. Message-ID: <03cd0a72-d6e8-41a7-a3de-aeb302c9a321@default> Hi, Pls review the fix for implementing the alternate hashing in SA. Bug: https://bugs.openjdk.java.net/browse/JDK-8030750 Webrev: http://cr.openjdk.java.net/~sballal/8030750/webrev.00/ rbt results: http://jdash.se.oracle.com/rbt/rbt-sharath.ballal-hs-20170421-0746-38693 Thanks & Regards, Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Apr 21 21:34:23 2017 From: jcbeyler at google.com (JC Beyler) Date: Fri, 21 Apr 2017 14:34:23 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: References: Message-ID: Hi all, I've added size information to the allocation sampling system. This allows the callback to remember the size of each sampled allocation. http://cr.openjdk.java.net/~rasbold/8171119/webrev.01/ The new webrev.01 also adds the actual heap monitoring sampling system in files: http://cr.openjdk.java.net/~rasbold/8171119/webrev.01/src/share/vm/runtime/heapMonitoring.cpp.patch and http://cr.openjdk.java.net/~rasbold/8171119/webrev.01/src/share/vm/runtime/heapMonitoring.hpp.patch My next step is to add the GC part to the webrev, which will allow users to determine what objects are live and what are garbage. Thanks for your attention and let me know if there are any questions! Have a wonderful Friday! Jc On Mon, Apr 17, 2017 at 12:37 PM, JC Beyler wrote: > Hi all, > > I worked on getting a few numbers for overhead and accuracy for my > feature. I'm unsure if here is the right place to provide the full data, so > I am just summarizing here for now. > > - Overhead of the feature > > Using the Dacapo benchmark (http://dacapobench.org/). My initial results > are that sampling provides 2.4% with a 512k sampling, 512k being our > default setting. > > - Note: this was without the tradesoap, tradebeans and tomcat benchmarks > since they did not work with my JDK9 (issue between Dacapo and JDK9 it > seems) > - I want to rerun next week to ensure number stability > > - Accuracy of the feature > > I wrote a small microbenchmark that allocates from two different > stacktraces at a given ratio. For example, 10% of stacktrace S1 and 90% > from stacktrace S2. The microbenchmark was run 20 times, I averaged the > results and looked for accuracy. It seems that statistically it is sound > since if I allocated10% S1 and 90% S2, with a sampling rate of 512k, I > obtained 9.61% S1 and 90.49% S2. > > Let me know if there are any questions on the numbers and if you'd like to > see some more data. > > Note: this was done using our internal JDK8 implementation since the > webrev provided by http://cr.openjdk.java.net/ > ~rasbold/heapz/webrev.00/index.html does not yet contain the whole > implementation and therefore would have been misleading. > > Thanks, > Jc > > > On Tue, Apr 4, 2017 at 3:55 PM, JC Beyler wrote: > >> Hi all, >> >> To move the discussion forward, with Chuck Rasbold's help to make a >> webrev, we pushed this: >> http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/index.html >> 415 lines changed: 399 ins; 13 del; 3 mod; 51122 unchg >> >> This is not a final change that does the whole proposition from the JBS >> entry: https://bugs.openjdk.java.net/browse/JDK-8177374; what it does >> show is parts of the implementation that is proposed and hopefully can >> start the conversation going as I work through the details. >> >> For example, the changes to C2 are done here for the allocations: >> http://cr.openjdk.java.net/~rasbold/heapz/webrev.00/src/share/vm/opto/ >> macro.cpp.patch >> >> Hopefully this all makes sense and thank you for all your future comments! >> Jc >> >> >> On Tue, Dec 13, 2016 at 1:11 PM, JC Beyler wrote: >> >>> Hello all, >>> >>> This is a follow-up from Jeremy's initial email from last year: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/20 >>> 15-June/017543.html >>> >>> I've gone ahead and started working on preparing this and Jeremy and I >>> went down the route of actually writing it up in JEP form: >>> https://bugs.openjdk.java.net/browse/JDK-8171119 >>> >>> I think original conversation that happened last year in that thread >>> still holds true: >>> >>> - We have a patch at Google that we think others might be interested in >>> - It provides a means to understand where the allocation hotspots >>> are at a very low overhead >>> - Since it is at a low overhead, we can leave it on by default >>> >>> So I come to the mailing list with Jeremy's initial question: >>> "I thought I would ask if there is any interest / if I should write a >>> JEP / if I should just forget it." >>> >>> A year ago, it seemed some thought it was a good idea, is this still >>> true? >>> >>> Thanks, >>> Jc >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Sun Apr 23 10:20:57 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Sun, 23 Apr 2017 15:50:57 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent Message-ID: Hi All, Please review this enhancement to replace plain-text password for JMX agent with SHA-256 hash. Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ Overview of implementation: Currently, the JMX agent password file used to authenticate user, stores user name and password as clear text. Though system level restrictions are recommended for jmx password file, passwords are vulnerable since they are stored in clear. The current RFE proposes to store passwords as SHA256 hash instead of clear text. In current implementation, if password file is writable, and if passwords are in clear, they will be replaced by SHA256 hash upon agent boot-up or when login attempt is made. The file, src/jdk.management.agent/share/conf/jmxremote.password.template contains more details about the implementation. - Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Sun Apr 23 14:30:31 2017 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 23 Apr 2017 17:30:31 +0300 Subject: RFR: JDK-8030750 - SA: alternate hashing not implemented. In-Reply-To: <03cd0a72-d6e8-41a7-a3de-aeb302c9a321@default> References: <03cd0a72-d6e8-41a7-a3de-aeb302c9a321@default> Message-ID: <9a314bdd-4cdc-c287-dd17-94c3fd7dfc6d@oracle.com> Sharath, Looks good to me! -Dmitry On 2017-04-21 15:32, Sharath Ballal wrote: > Hi, > > > > Pls review the fix for implementing the alternate hashing in SA. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8030750 > > Webrev: http://cr.openjdk.java.net/~sballal/8030750/webrev.00/ > > > > rbt results: > http://jdash.se.oracle.com/rbt/rbt-sharath.ballal-hs-20170421-0746-38693 > > > > Thanks & Regards, > > Sharath Ballal > > > > > -- 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 sharath.ballal at oracle.com Sun Apr 23 14:32:30 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 23 Apr 2017 07:32:30 -0700 (PDT) Subject: RFR: JDK-8030750 - SA: alternate hashing not implemented. In-Reply-To: <9a314bdd-4cdc-c287-dd17-94c3fd7dfc6d@oracle.com> References: <03cd0a72-d6e8-41a7-a3de-aeb302c9a321@default> <9a314bdd-4cdc-c287-dd17-94c3fd7dfc6d@oracle.com> Message-ID: <1af1248e-9c77-4bd6-a6c0-0690d21c6ca8@default> Thanks for the review Dmitry. Thanks & Regards, Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Sunday, April 23, 2017 8:01 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8030750 - SA: alternate hashing not implemented. Sharath, Looks good to me! -Dmitry On 2017-04-21 15:32, Sharath Ballal wrote: > Hi, > > > > Pls review the fix for implementing the alternate hashing in SA. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8030750 > > Webrev: http://cr.openjdk.java.net/~sballal/8030750/webrev.00/ > > > > rbt results: > http://jdash.se.oracle.com/rbt/rbt-sharath.ballal-hs-20170421-0746-38693 > > > > Thanks & Regards, > > Sharath Ballal > > > > > -- 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 ecki at zusammenkunft.net Sun Apr 23 14:40:40 2017 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 23 Apr 2017 14:40:40 +0000 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: Message-ID: Hm, why introduce a new password hash format. Just use modular crypt() format (and iterations). This allows to use common tools (like htpasswd) to generate the hashes. It would use $5$ prefix for SHA256 but actually I would use $6$ for iterated SHA512 as it is the default on most recent Linux distributions. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: serviceability-dev on behalf of Harsha Wardhana B Sent: Sunday, April 23, 2017 12:20:57 PM To: serviceability-dev at openjdk.java.net Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent Hi All, Please review this enhancement to replace plain-text password for JMX agent with SHA-256 hash. Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ Overview of implementation: Currently, the JMX agent password file used to authenticate user, stores user name and password as clear text. Though system level restrictions are recommended for jmx password file, passwords are vulnerable since they are stored in clear. The current RFE proposes to store passwords as SHA256 hash instead of clear text. In current implementation, if password file is writable, and if passwords are in clear, they will be replaced by SHA256 hash upon agent boot-up or when login attempt is made. The file, src/jdk.management.agent/share/conf/jmxremote.password.template contains more details about the implementation. - Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Mon Apr 24 08:27:56 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Mon, 24 Apr 2017 13:57:56 +0530 Subject: RFR: JDK-8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out In-Reply-To: <61faa5e4-4dfa-d731-2230-eb56a67b4074@oracle.com> References: <275f6926-fa48-97d5-1d79-8aa43bdb9321@oracle.com> <61faa5e4-4dfa-d731-2230-eb56a67b4074@oracle.com> Message-ID: <72bf40e7-61d8-e541-da21-69036d1c94dc@oracle.com> Daniel, David Thanks for the review :-) -Ujwal On 4/18/2017 5:39 PM, David Holmes wrote: > Hi Daniel, > > On 18/04/2017 8:39 PM, Daniel Fuchs wrote: >> On 18/04/2017 05:20, David Holmes wrote: >>> Hi Ujwal, >>> >>> On 14/04/2017 4:25 PM, Ujwal Vangapally wrote: >>>> Please review this small change >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8130084 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8130084/webrev.00/ >>> >>> I agree with Daniel this makes the test less susceptible to spurious >>> timeouts and will instead only be timed-out by the test harness. >> >> Hi David, >> >>> One additional comment though is that it now seems to serve no point to >>> create a separate thread to do the work. ?? >> >> AFAICS the test attempts to tease the JMX notification logic to >> produce a deadlock. I believe we would have to go back to the original >> bug description and make a careful analysis of the original issue >> to assert whether or not creating that thread was integral to >> the issue being tested (or if it was just a way to not wait >> infinitely). > > You are absolutely right - it does need the second thread to ensure > there is no deadlock. > > Thanks, > David > ----- > >> So all in all I think I'm more comfortable with not removing that >> thread and leaving the fix as it is ;-) >> >> best regards, >> >> -- daniel >> >>> >>> Thanks, >>> David >>> >> From harsha.wardhana.b at oracle.com Mon Apr 24 16:03:25 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 24 Apr 2017 21:33:25 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: Message-ID: Hi Gruss, Crypt format has additional params (|param|name and its|value|: hash complexity parameters, like rounds/iterations count ) which are not applicable to current implementation. Also, hash algorithms shipped with JDK are applicable (MD5, SHA1, SHA256) and any other algorithms specified by crypt format will be ignored. Crypt format can be used, but it is over-engineered for current requirement/implementation. I am not opposed to using it and would welcome input from other reviewers. -Harsha On Sunday 23 April 2017 08:10 PM, Bernd Eckenfels wrote: > Hm, why introduce a new password hash format. Just use modular crypt() > format (and iterations). This allows to use common tools (like > htpasswd) to generate the hashes. It would use $5$ prefix for SHA256 > but actually I would use $6$ for iterated SHA512 as it is the default > on most recent Linux distributions. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *From:* serviceability-dev > on behalf of Harsha > Wardhana B > *Sent:* Sunday, April 23, 2017 12:20:57 PM > *To:* serviceability-dev at openjdk.java.net > *Subject:* RFE Review : JDK-5016517 - Replace plaintext passwords by > hashed passwords for out-of-the-box JMX Agent > > Hi All, > > Please review this enhancement to replace plain-text password for JMX > agent with SHA-256 hash. > > Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 > > > webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ > > Overview of implementation: > > Currently, the JMX agent password file used to authenticate user, > stores user name and password as clear text. Though system level > restrictions are recommended for jmx password file, passwords are > vulnerable since they are stored in clear. The current RFE proposes to > store passwords as SHA256 hash instead of clear text. > > In current implementation, if password file is writable, and if > passwords are in clear, they will be replaced by SHA256 hash upon > agent boot-up or when login attempt is made. > > The file, > src/jdk.management.agent/share/conf/jmxremote.password.template > contains more details about the implementation. > > - Harsha > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From poonam.bajaj at oracle.com Mon Apr 24 20:09:46 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Mon, 24 Apr 2017 13:09:46 -0700 (PDT) Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> Message-ID: <461535be-7e6a-442d-a30d-b25fda5a4c42@default> Hello Shafi, You could do something like this: + public static void error(AgentConfigurationError e) { + String keyText = getText(e.getError()); + String params = e.getParams(); + + System.err.print(getText("agent.err.error") + ": " + keyText); + + if (params != null && params.length != 0) { + StringBuffer message = new StringBuffer(params[0]); + for (int i = 1; i < params.length; i++) { + message.append(" " + params[i]); + } + System.err.println(": " + message); + } + e.printStackTrace(); + throw new RuntimeException(e); + } This error() variant first prints the 'error' and 'params' of the AgentConfigurationError and then prints the complete stack trace (including the cause). Daniel, Originally, if the stack trace was intentionally ignored to keep the error message short, then I think just printing the 'cause' instead of complete stack trace would also be sufficient in getting to the cause of the error here. Instead of e.printStackTrace(); we can just do: System.err.println("Caused by: " + e.getCause()); Thanks, Poonam > -----Original Message----- > From: Daniel Fuchs > Sent: Thursday, April 13, 2017 2:25 AM > To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net > Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > On 13/04/2017 02:15, David Holmes wrote: > > Overall the exception management in this code looks like it predate > > the existence of an "exception cause" and should probably be updated > > to utilize that more effectively. > > Hi David, > > I think the original idea was to display a localized message to the end > user - and not frighten him with a big unlocalized stack trace. > > But I otherwise agree with your suggestion. > > best regards, > > -- daniel From Roger.Riggs at Oracle.com Tue Apr 25 17:26:04 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Apr 2017 13:26:04 -0400 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: Message-ID: <6a193cdf-efea-e4e9-4faf-72d8960cd72b@Oracle.com> Hi Harsha, Thanks for this important improvement. Comments: * jmxremote.password.template: "Passwords will be hashed by server if they are in clear." Perhaps should be more explicit: "The jmxremote.passwords file will be re-written by the server to replace all plain text passwords with hashed passwords when the file is read by the server." line 35: "Base64 encoded hash" -> drop the "Base64" in this line isn't needed and make it seems like it should appear as 1 field instead of 2 or 3. 37+: The syntax of the file may be clearer if it includes the complete syntax in (line 39) not just the password/hash fragment. Line 41: "W = spaces"; above "tabs" are allowed as a delimiter; it would be good to be consistent and include the usualy white-space characters in the set, be as specific as possible. Is this the same set of whitespace used by Regex '\\s'. 45: "java platform"" -> "MD5, SDA-1, SHA-256 are supported algorithms." 49: be more specific about 'hashing is requested' how? Refer to the management.properties com.sun.management.jmxremote.password.hash value. 51: "replace hashed" -> "replace *the *hashed" 52: "with clear text or new" -> "with the clear text or the new" 52: "If new password" -> "If the new password" 53: "when new login" -> "when a new login" 60: "User generated" -> "A User generated" 67: Will the file be ignored if it has the wrong permissions. (With a logged message) * management.properties 306: "(Case for true/false ignored)" - what does this mean; I think it can be removed. 307: missing period at the end of the sentence. 309: "in password file" -> "in the password file" * FileLoginModule.java 102: can this match better the similar name in the management.properties if it has the same function: com.sun.management.jmxremote.password.hash 103: "replaces clear text passwords" -> "replaces each clear text password" 104: indent to match previous

enteries. * JMXPluggableAuthenticator.java 119: There is no need to copy the password to a new local 128: add a space after "," 256 private static final String HASH_PASSWORDS = 257 "jmx.remote.x.password.file.hash"; The name ".hash" part does not clearly communicate that passwords are to be hashed. "hashPasswords" might be more self explanatory. Also, can this be NOT duplicated here and in ConnectorBootStrap.java? * ConnectorBootStrap.java: 482: Add space after ","s; no spaces before. 770: use the same name for the option/property if possible to avoid confusion. 770: if the HASH_PASSWORDS static is appropriate use it instead of literal "true". * HashedPasswordManager 80-83: The fields can be final and use the constructor to initialize in all cases and make the class final to avoid unintentional subclassing. 113: canWriteToFile: It should be made clear in the template that *both* the Security policy and the file access value are used to check that the file can be updated. 200: loadPasswords() - should this confirm the access to the file is allowed and it has the correct file access before reading? Is the re-writing of the passwords intended to be done by a 'priveleged' system. Does this need doPrivileged? * HashedPasswordFileTest: 88: should use the TestLibrary Utils.getRandomInstance so it logs the seed and can be replayed if necessary. Thanks, Roger On 4/23/2017 6:20 AM, Harsha Wardhana B wrote: > > Hi All, > > Please review this enhancement to replace plain-text password for JMX > agent with SHA-256 hash. > > Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 > > > webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ > > Overview of implementation: > > Currently, the JMX agent password file used to authenticate user, > stores user name and password as clear text. Though system level > restrictions are recommended for jmx password file, passwords are > vulnerable since they are stored in clear. The current RFE proposes to > store passwords as SHA256 hash instead of clear text. > > In current implementation, if password file is writable, and if > passwords are in clear, they will be replaced by SHA256 hash upon > agent boot-up or when login attempt is made. > > The file, > src/jdk.management.agent/share/conf/jmxremote.password.template > contains more details about the implementation. > > - Harsha > > > > From shafi.s.ahmad at oracle.com Wed Apr 26 08:15:54 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 26 Apr 2017 01:15:54 -0700 (PDT) Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <461535be-7e6a-442d-a30d-b25fda5a4c42@default> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> Message-ID: Hi, Thank you Poonam, David and Daniel for the review and suggestion. Please find updated webrev - http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ Regards, Shafi > -----Original Message----- > From: Poonam Parhar > Sent: Tuesday, April 25, 2017 1:40 AM > To: Daniel Fuchs ; David Holmes > ; Shafi Ahmad ; > serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > Hello Shafi, > > You could do something like this: > > + public static void error(AgentConfigurationError e) { > + String keyText = getText(e.getError()); > + String params = e.getParams(); > + > + System.err.print(getText("agent.err.error") + ": " + keyText); > + > + if (params != null && params.length != 0) { > + StringBuffer message = new StringBuffer(params[0]); > + for (int i = 1; i < params.length; i++) { > + message.append(" " + params[i]); > + } > + System.err.println(": " + message); > + } > + e.printStackTrace(); > + throw new RuntimeException(e); > + } > > This error() variant first prints the 'error' and 'params' of the > AgentConfigurationError and then prints the complete stack trace (including > the cause). > > Daniel, > > Originally, if the stack trace was intentionally ignored to keep the error > message short, then I think just printing the 'cause' instead of complete stack > trace would also be sufficient in getting to the cause of the error here. > > Instead of > > e.printStackTrace(); > > we can just do: > > System.err.println("Caused by: " + e.getCause()); > > > Thanks, > Poonam > > > > -----Original Message----- > > From: Daniel Fuchs > > Sent: Thursday, April 13, 2017 2:25 AM > > To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net > > Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > > sun.management.Agent#startAgent() > > > > On 13/04/2017 02:15, David Holmes wrote: > > > Overall the exception management in this code looks like it predate > > > the existence of an "exception cause" and should probably be updated > > > to utilize that more effectively. > > > > Hi David, > > > > I think the original idea was to display a localized message to the > > end user - and not frighten him with a big unlocalized stack trace. > > > > But I otherwise agree with your suggestion. > > > > best regards, > > > > -- daniel From daniel.fuchs at oracle.com Wed Apr 26 09:29:55 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 26 Apr 2017 10:29:55 +0100 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> Message-ID: <4e847bf9-a5ca-7ea0-28c3-757f7954c49d@oracle.com> Hi Shafi, On 26/04/2017 09:15, Shafi Ahmad wrote: > Hi, > > Thank you Poonam, David and Daniel for the review and suggestion. > > Please find updated webrev - http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ Looks good to me. -- daniel > > Regards, > Shafi > >> -----Original Message----- >> From: Poonam Parhar >> Sent: Tuesday, April 25, 2017 1:40 AM >> To: Daniel Fuchs ; David Holmes >> ; Shafi Ahmad ; >> serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >> sun.management.Agent#startAgent() >> >> Hello Shafi, >> >> You could do something like this: >> >> + public static void error(AgentConfigurationError e) { >> + String keyText = getText(e.getError()); >> + String params = e.getParams(); >> + >> + System.err.print(getText("agent.err.error") + ": " + keyText); >> + >> + if (params != null && params.length != 0) { >> + StringBuffer message = new StringBuffer(params[0]); >> + for (int i = 1; i < params.length; i++) { >> + message.append(" " + params[i]); >> + } >> + System.err.println(": " + message); >> + } >> + e.printStackTrace(); >> + throw new RuntimeException(e); >> + } >> >> This error() variant first prints the 'error' and 'params' of the >> AgentConfigurationError and then prints the complete stack trace (including >> the cause). >> >> Daniel, >> >> Originally, if the stack trace was intentionally ignored to keep the error >> message short, then I think just printing the 'cause' instead of complete stack >> trace would also be sufficient in getting to the cause of the error here. >> >> Instead of >> >> e.printStackTrace(); >> >> we can just do: >> >> System.err.println("Caused by: " + e.getCause()); >> >> >> Thanks, >> Poonam >> >> >>> -----Original Message----- >>> From: Daniel Fuchs >>> Sent: Thursday, April 13, 2017 2:25 AM >>> To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net >>> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >>> sun.management.Agent#startAgent() >>> >>> On 13/04/2017 02:15, David Holmes wrote: >>>> Overall the exception management in this code looks like it predate >>>> the existence of an "exception cause" and should probably be updated >>>> to utilize that more effectively. >>> >>> Hi David, >>> >>> I think the original idea was to display a localized message to the >>> end user - and not frighten him with a big unlocalized stack trace. >>> >>> But I otherwise agree with your suggestion. >>> >>> best regards, >>> >>> -- daniel From poonam.bajaj at oracle.com Wed Apr 26 16:32:59 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Wed, 26 Apr 2017 09:32:59 -0700 (PDT) Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <4e847bf9-a5ca-7ea0-28c3-757f7954c49d@oracle.com> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> <4e847bf9-a5ca-7ea0-28c3-757f7954c49d@oracle.com> Message-ID: Looks good to me too. Thanks, Poonam > -----Original Message----- > From: Daniel Fuchs > Sent: Wednesday, April 26, 2017 2:30 AM > To: Shafi Ahmad; Poonam Parhar; David Holmes; serviceability- > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > Hi Shafi, > > On 26/04/2017 09:15, Shafi Ahmad wrote: > > Hi, > > > > Thank you Poonam, David and Daniel for the review and suggestion. > > > > Please find updated webrev - > > http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ > > Looks good to me. > > -- daniel > > > > > Regards, > > Shafi > > > >> -----Original Message----- > >> From: Poonam Parhar > >> Sent: Tuesday, April 25, 2017 1:40 AM > >> To: Daniel Fuchs ; David Holmes > >> ; Shafi Ahmad ; > >> serviceability-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > >> sun.management.Agent#startAgent() > >> > >> Hello Shafi, > >> > >> You could do something like this: > >> > >> + public static void error(AgentConfigurationError e) { > >> + String keyText = getText(e.getError()); > >> + String params = e.getParams(); > >> + > >> + System.err.print(getText("agent.err.error") + ": " + > >> + keyText); > >> + > >> + if (params != null && params.length != 0) { > >> + StringBuffer message = new StringBuffer(params[0]); > >> + for (int i = 1; i < params.length; i++) { > >> + message.append(" " + params[i]); > >> + } > >> + System.err.println(": " + message); > >> + } > >> + e.printStackTrace(); > >> + throw new RuntimeException(e); } > >> > >> This error() variant first prints the 'error' and 'params' of the > >> AgentConfigurationError and then prints the complete stack trace > >> (including the cause). > >> > >> Daniel, > >> > >> Originally, if the stack trace was intentionally ignored to keep the > >> error message short, then I think just printing the 'cause' instead > >> of complete stack trace would also be sufficient in getting to the > cause of the error here. > >> > >> Instead of > >> > >> e.printStackTrace(); > >> > >> we can just do: > >> > >> System.err.println("Caused by: " + e.getCause()); > >> > >> > >> Thanks, > >> Poonam > >> > >> > >>> -----Original Message----- > >>> From: Daniel Fuchs > >>> Sent: Thursday, April 13, 2017 2:25 AM > >>> To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net > >>> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > >>> sun.management.Agent#startAgent() > >>> > >>> On 13/04/2017 02:15, David Holmes wrote: > >>>> Overall the exception management in this code looks like it > predate > >>>> the existence of an "exception cause" and should probably be > >>>> updated to utilize that more effectively. > >>> > >>> Hi David, > >>> > >>> I think the original idea was to display a localized message to the > >>> end user - and not frighten him with a big unlocalized stack trace. > >>> > >>> But I otherwise agree with your suggestion. > >>> > >>> best regards, > >>> > >>> -- daniel > From david.holmes at oracle.com Wed Apr 26 21:04:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Apr 2017 07:04:47 +1000 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> Message-ID: <15e6e83d-dcbd-1dba-0ec3-b98da7f95d7a@oracle.com> Hi Shafi, On 26/04/2017 6:15 PM, Shafi Ahmad wrote: > Hi, > > Thank you Poonam, David and Daniel for the review and suggestion. > > Please find updated webrev - http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ That looks okay to me - thanks. But I'm wondering if we need the same change in startRemoteManagementAgent: 395 } catch (AgentConfigurationError err) { 396 error(err.getError(), err.getParams()); and if we do then I think the: 668 public static void error(String key, String[] params) { variant becomes dead code. Thanks, David > Regards, > Shafi > >> -----Original Message----- >> From: Poonam Parhar >> Sent: Tuesday, April 25, 2017 1:40 AM >> To: Daniel Fuchs ; David Holmes >> ; Shafi Ahmad ; >> serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >> sun.management.Agent#startAgent() >> >> Hello Shafi, >> >> You could do something like this: >> >> + public static void error(AgentConfigurationError e) { >> + String keyText = getText(e.getError()); >> + String params = e.getParams(); >> + >> + System.err.print(getText("agent.err.error") + ": " + keyText); >> + >> + if (params != null && params.length != 0) { >> + StringBuffer message = new StringBuffer(params[0]); >> + for (int i = 1; i < params.length; i++) { >> + message.append(" " + params[i]); >> + } >> + System.err.println(": " + message); >> + } >> + e.printStackTrace(); >> + throw new RuntimeException(e); >> + } >> >> This error() variant first prints the 'error' and 'params' of the >> AgentConfigurationError and then prints the complete stack trace (including >> the cause). >> >> Daniel, >> >> Originally, if the stack trace was intentionally ignored to keep the error >> message short, then I think just printing the 'cause' instead of complete stack >> trace would also be sufficient in getting to the cause of the error here. >> >> Instead of >> >> e.printStackTrace(); >> >> we can just do: >> >> System.err.println("Caused by: " + e.getCause()); >> >> >> Thanks, >> Poonam >> >> >>> -----Original Message----- >>> From: Daniel Fuchs >>> Sent: Thursday, April 13, 2017 2:25 AM >>> To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net >>> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >>> sun.management.Agent#startAgent() >>> >>> On 13/04/2017 02:15, David Holmes wrote: >>>> Overall the exception management in this code looks like it predate >>>> the existence of an "exception cause" and should probably be updated >>>> to utilize that more effectively. >>> >>> Hi David, >>> >>> I think the original idea was to display a localized message to the >>> end user - and not frighten him with a big unlocalized stack trace. >>> >>> But I otherwise agree with your suggestion. >>> >>> best regards, >>> >>> -- daniel From harsha.wardhana.b at oracle.com Thu Apr 27 06:36:24 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 27 Apr 2017 12:06:24 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: <6a193cdf-efea-e4e9-4faf-72d8960cd72b@Oracle.com> References: <6a193cdf-efea-e4e9-4faf-72d8960cd72b@Oracle.com> Message-ID: <5dded394-ea92-687f-cbb0-3347936c1eec@oracle.com> Hi Roger, Thanks for the detailed review. I will wait for more review comments before incorporating the ones below. -Harsha On Tuesday 25 April 2017 10:56 PM, Roger Riggs wrote: > Hi Harsha, > > Thanks for this important improvement. Comments: > > > * jmxremote.password.template: > "Passwords will be hashed by server if they are in clear." Perhaps > should be more explicit: > > "The jmxremote.passwords file will be re-written by the server to > replace all plain text passwords with hashed passwords when the file > is read by the server." > > line 35: "Base64 encoded hash" -> drop the "Base64" in this line > isn't needed and > make it seems like it should appear as 1 field instead of 2 or 3. > > 37+: The syntax of the file may be clearer if it includes the complete > syntax in (line 39) not > just the password/hash fragment. > > Line 41: "W = spaces"; above "tabs" are allowed as a delimiter; it > would be good to be consistent > and include the usualy white-space characters in the set, be as > specific as possible. > Is this the same set of whitespace used by Regex '\\s'. > > 45: "java platform"" -> "MD5, SDA-1, SHA-256 are supported > algorithms." > > 49: be more specific about 'hashing is requested' how? Refer to the > management.properties > com.sun.management.jmxremote.password.hash value. > > > > 51: "replace hashed" -> "replace *the *hashed" > 52: "with clear text or new" -> "with the clear text or the new" > 52: "If new password" -> "If the new password" > 53: "when new login" -> "when a new login" > > 60: "User generated" -> "A User generated" > > 67: Will the file be ignored if it has the wrong permissions. (With a > logged message) > > * management.properties > > 306: "(Case for true/false ignored)" - what does this mean; I think > it can be removed. > > 307: missing period at the end of the sentence. > 309: "in password file" -> "in the password file" > > > * FileLoginModule.java > > 102: can this match better the similar name in the > management.properties if it has the same function: > com.sun.management.jmxremote.password.hash > 103: "replaces clear text passwords" -> "replaces each clear text > password" > 104: indent to match previous
enteries. > > * JMXPluggableAuthenticator.java > > 119: There is no need to copy the password to a new local > > 128: add a space after "," > > 256 private static final String HASH_PASSWORDS = > 257 "jmx.remote.x.password.file.hash"; > > The name ".hash" part does not clearly communicate that passwords are > to be hashed. > "hashPasswords" might be more self explanatory. > Also, can this be NOT duplicated here and in ConnectorBootStrap.java? > > > * ConnectorBootStrap.java: > 482: Add space after ","s; no spaces before. > > 770: use the same name for the option/property if possible to avoid > confusion. > > 770: if the HASH_PASSWORDS static is appropriate use it instead of > literal "true". > > * HashedPasswordManager > > 80-83: The fields can be final and use the constructor to initialize > in all cases and make the class final > to avoid unintentional subclassing. > > > 113: canWriteToFile: It should be made clear in the template that > *both* the Security policy > and the file access value are used to check that the file can be > updated. > > 200: loadPasswords() - should this confirm the access to the file is > allowed and it has > the correct file access before reading? > > Is the re-writing of the passwords intended to be done by a > 'priveleged' system. > Does this need doPrivileged? > > * HashedPasswordFileTest: > > 88: should use the TestLibrary Utils.getRandomInstance so it logs the > seed and can be replayed if necessary. > > > Thanks, Roger > > > On 4/23/2017 6:20 AM, Harsha Wardhana B wrote: >> >> Hi All, >> >> Please review this enhancement to replace plain-text password for JMX >> agent with SHA-256 hash. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-5016517 >> >> >> webrev: http://cr.openjdk.java.net/~hb/5016517/webrev.00/ >> >> Overview of implementation: >> >> Currently, the JMX agent password file used to authenticate user, >> stores user name and password as clear text. Though system level >> restrictions are recommended for jmx password file, passwords are >> vulnerable since they are stored in clear. The current RFE proposes >> to store passwords as SHA256 hash instead of clear text. >> >> In current implementation, if password file is writable, and if >> passwords are in clear, they will be replaced by SHA256 hash upon >> agent boot-up or when login attempt is made. >> >> The file, >> src/jdk.management.agent/share/conf/jmxremote.password.template >> contains more details about the implementation. >> >> - Harsha >> >> >> >> > From shafi.s.ahmad at oracle.com Thu Apr 27 07:08:13 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Thu, 27 Apr 2017 00:08:13 -0700 (PDT) Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <15e6e83d-dcbd-1dba-0ec3-b98da7f95d7a@oracle.com> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> <15e6e83d-dcbd-1dba-0ec3-b98da7f95d7a@oracle.com> Message-ID: <3eeb789d-f4be-40cc-9ac1-ca8dad2be3e5@default> Hi David, Thank you for the review. I think suggested comment make sense to me so I have update the code as per your comment. Please find updated webrev - http://cr.openjdk.java.net/~shshahma/8177721/webrev.02/ Regards, Shafi > -----Original Message----- > From: David Holmes > Sent: Thursday, April 27, 2017 2:35 AM > To: Shafi Ahmad ; Poonam Parhar > ; Daniel Fuchs ; > serviceability-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > Hi Shafi, > > On 26/04/2017 6:15 PM, Shafi Ahmad wrote: > > Hi, > > > > Thank you Poonam, David and Daniel for the review and suggestion. > > > > Please find updated webrev - > > http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ > > That looks okay to me - thanks. > > But I'm wondering if we need the same change in > startRemoteManagementAgent: > > 395 } catch (AgentConfigurationError err) { > 396 error(err.getError(), err.getParams()); > > and if we do then I think the: > > 668 public static void error(String key, String[] params) { > > variant becomes dead code. > > Thanks, > David > > > Regards, > > Shafi > > > >> -----Original Message----- > >> From: Poonam Parhar > >> Sent: Tuesday, April 25, 2017 1:40 AM > >> To: Daniel Fuchs ; David Holmes > >> ; Shafi Ahmad ; > >> serviceability-dev at openjdk.java.net; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > >> sun.management.Agent#startAgent() > >> > >> Hello Shafi, > >> > >> You could do something like this: > >> > >> + public static void error(AgentConfigurationError e) { > >> + String keyText = getText(e.getError()); > >> + String params = e.getParams(); > >> + > >> + System.err.print(getText("agent.err.error") + ": " + > >> + keyText); > >> + > >> + if (params != null && params.length != 0) { > >> + StringBuffer message = new StringBuffer(params[0]); > >> + for (int i = 1; i < params.length; i++) { > >> + message.append(" " + params[i]); > >> + } > >> + System.err.println(": " + message); > >> + } > >> + e.printStackTrace(); > >> + throw new RuntimeException(e); } > >> > >> This error() variant first prints the 'error' and 'params' of the > >> AgentConfigurationError and then prints the complete stack trace > >> (including the cause). > >> > >> Daniel, > >> > >> Originally, if the stack trace was intentionally ignored to keep the > >> error message short, then I think just printing the 'cause' instead > >> of complete stack trace would also be sufficient in getting to the cause of > the error here. > >> > >> Instead of > >> > >> e.printStackTrace(); > >> > >> we can just do: > >> > >> System.err.println("Caused by: " + e.getCause()); > >> > >> > >> Thanks, > >> Poonam > >> > >> > >>> -----Original Message----- > >>> From: Daniel Fuchs > >>> Sent: Thursday, April 13, 2017 2:25 AM > >>> To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net > >>> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in > >>> sun.management.Agent#startAgent() > >>> > >>> On 13/04/2017 02:15, David Holmes wrote: > >>>> Overall the exception management in this code looks like it predate > >>>> the existence of an "exception cause" and should probably be > >>>> updated to utilize that more effectively. > >>> > >>> Hi David, > >>> > >>> I think the original idea was to display a localized message to the > >>> end user - and not frighten him with a big unlocalized stack trace. > >>> > >>> But I otherwise agree with your suggestion. > >>> > >>> best regards, > >>> > >>> -- daniel From david.holmes at oracle.com Thu Apr 27 07:10:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Apr 2017 17:10:15 +1000 Subject: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <3eeb789d-f4be-40cc-9ac1-ca8dad2be3e5@default> References: <380aa564-6a42-c68e-6bcb-b0b3de0f7d99@oracle.com> <491893ae-7abc-7645-8c30-510e1a3f6b46@oracle.com> <461535be-7e6a-442d-a30d-b25fda5a4c42@default> <15e6e83d-dcbd-1dba-0ec3-b98da7f95d7a@oracle.com> <3eeb789d-f4be-40cc-9ac1-ca8dad2be3e5@default> Message-ID: Looks good to me! Thanks Shafi. David On 27/04/2017 5:08 PM, Shafi Ahmad wrote: > Hi David, > > Thank you for the review. > > I think suggested comment make sense to me so I have update the code as per your comment. > > Please find updated webrev - http://cr.openjdk.java.net/~shshahma/8177721/webrev.02/ > > Regards, > Shafi > >> -----Original Message----- >> From: David Holmes >> Sent: Thursday, April 27, 2017 2:35 AM >> To: Shafi Ahmad ; Poonam Parhar >> ; Daniel Fuchs ; >> serviceability-dev at openjdk.java.net; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >> sun.management.Agent#startAgent() >> >> Hi Shafi, >> >> On 26/04/2017 6:15 PM, Shafi Ahmad wrote: >>> Hi, >>> >>> Thank you Poonam, David and Daniel for the review and suggestion. >>> >>> Please find updated webrev - >>> http://cr.openjdk.java.net/~shshahma/8177721/webrev.01/ >> >> That looks okay to me - thanks. >> >> But I'm wondering if we need the same change in >> startRemoteManagementAgent: >> >> 395 } catch (AgentConfigurationError err) { >> 396 error(err.getError(), err.getParams()); >> >> and if we do then I think the: >> >> 668 public static void error(String key, String[] params) { >> >> variant becomes dead code. >> >> Thanks, >> David >> >>> Regards, >>> Shafi >>> >>>> -----Original Message----- >>>> From: Poonam Parhar >>>> Sent: Tuesday, April 25, 2017 1:40 AM >>>> To: Daniel Fuchs ; David Holmes >>>> ; Shafi Ahmad ; >>>> serviceability-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: RE: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >>>> sun.management.Agent#startAgent() >>>> >>>> Hello Shafi, >>>> >>>> You could do something like this: >>>> >>>> + public static void error(AgentConfigurationError e) { >>>> + String keyText = getText(e.getError()); >>>> + String params = e.getParams(); >>>> + >>>> + System.err.print(getText("agent.err.error") + ": " + >>>> + keyText); >>>> + >>>> + if (params != null && params.length != 0) { >>>> + StringBuffer message = new StringBuffer(params[0]); >>>> + for (int i = 1; i < params.length; i++) { >>>> + message.append(" " + params[i]); >>>> + } >>>> + System.err.println(": " + message); >>>> + } >>>> + e.printStackTrace(); >>>> + throw new RuntimeException(e); } >>>> >>>> This error() variant first prints the 'error' and 'params' of the >>>> AgentConfigurationError and then prints the complete stack trace >>>> (including the cause). >>>> >>>> Daniel, >>>> >>>> Originally, if the stack trace was intentionally ignored to keep the >>>> error message short, then I think just printing the 'cause' instead >>>> of complete stack trace would also be sufficient in getting to the cause of >> the error here. >>>> >>>> Instead of >>>> >>>> e.printStackTrace(); >>>> >>>> we can just do: >>>> >>>> System.err.println("Caused by: " + e.getCause()); >>>> >>>> >>>> Thanks, >>>> Poonam >>>> >>>> >>>>> -----Original Message----- >>>>> From: Daniel Fuchs >>>>> Sent: Thursday, April 13, 2017 2:25 AM >>>>> To: David Holmes; Shafi Ahmad; serviceability-dev at openjdk.java.net >>>>> Subject: Re: [jdk10] RFR for 'JDK-8177721: Improve diagnostics in >>>>> sun.management.Agent#startAgent() >>>>> >>>>> On 13/04/2017 02:15, David Holmes wrote: >>>>>> Overall the exception management in this code looks like it predate >>>>>> the existence of an "exception cause" and should probably be >>>>>> updated to utilize that more effectively. >>>>> >>>>> Hi David, >>>>> >>>>> I think the original idea was to display a localized message to the >>>>> end user - and not frighten him with a big unlocalized stack trace. >>>>> >>>>> But I otherwise agree with your suggestion. >>>>> >>>>> best regards, >>>>> >>>>> -- daniel From serguei.spitsyn at oracle.com Fri Apr 28 05:14:06 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 27 Apr 2017 22:14:06 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase Message-ID: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> Please, review the jdk 10 fix for the test enhancement: https://bugs.openjdk.java.net/browse/JDK-8172970 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ Summary: The task was to provide a test coverage for the JVMTI functions allowed during the start phase. It includes both enabling and disabling the can_generate_early_vmstart capability. Testing the JVMTI functions allowed in any case has not been targeted by this fix. Testing: New test is passed. Thanks, Serguei From david.holmes at oracle.com Fri Apr 28 06:11:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Apr 2017 16:11:26 +1000 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> Message-ID: Hi Serguei, On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: > Please, review the jdk 10 fix for the test enhancement: > https://bugs.openjdk.java.net/browse/JDK-8172970 > > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ Sorry but I can't quite figure out exactly what this test is doing. What is the overall call structure here? I was expecting to see a difference between things that can be called at early-start and those that can not - or are these all expected to work okay in either case? A few comments: 44 #define TranslateError(err) "JVMTI error" I don't see the point of the above. --- 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { The thread local functions use "long" as the datatype but that will only be 32-bit on 64-bit Windows. I think you need to use intptr_t for complete portability. --- 277 printf(" Filed declaring"); typo: filed -> field --- All your little wrapper functions make the JVMTI call and then call check_jvmti_error - but all that does is record if it passed or failed. If it failed you still continue with the next operation even if it relies on the success of the first one eg: 378 set_thread_local(jvmti, thread, exp_val); 379 act_val = get_thread_local(jvmti, cur_thread); and the sequences in print_method_info: 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); 229 check_jvmti_error(jvmti, "IsMethodNative", err); 230 printf(" Method is native: %d\n", is_native); 231 232 if (is_native == JNI_FALSE) { 233 err = (*jvmti)->GetMaxLocals(jvmti, method, &locals_max); The call at #233 may not be valid because the method actually is native but the IsMethodNative call failed for some reason. Thanks, David ----- > > > Summary: > The task was to provide a test coverage for the JVMTI functions > allowed during the start phase. > It includes both enabling and disabling the can_generate_early_vmstart > capability. > Testing the JVMTI functions allowed in any case has not been targeted > by this fix. > > Testing: > New test is passed. > > > Thanks, > Serguei From serguei.spitsyn at oracle.com Fri Apr 28 07:47:54 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 00:47:54 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> Message-ID: Hi David, Thank you for looking at the test! On 4/27/17 23:11, David Holmes wrote: > Hi Serguei, > > On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the jdk 10 fix for the test enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8172970 >> >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >> > > Sorry but I can't quite figure out exactly what this test is doing. > What is the overall call structure here? This is to make sure the functions allowed in the start and live phases work Ok. As the list of functions is pretty big the test does sanity checks that the functions do not crash nor return errors. > I was expecting to see a difference between things that can be called > at early-start and those that can not - or are these all expected to > work okay in either case? All these functions are expected to work okay in both cases. Of course, the main concern is the early start. But we have never had such coverage in the past so that the normal start phase needs to be covered too. > > A few comments: > > 44 #define TranslateError(err) "JVMTI error" > > I don't see the point of the above. Good catch - removed. It is a left over from another test that I used as initial template. > --- > > 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { > > The thread local functions use "long" as the datatype but that will > only be 32-bit on 64-bit Windows. I think you need to use intptr_t for > complete portability. The type long has the same format as the type void* which has to be portable even on win-32. But maybe I'm missing something. Anyway, I've replaced it with the intptr_t. > > --- > > 277 printf(" Filed declaring"); > > typo: filed -> field Good catch - fixed. > > --- > > All your little wrapper functions make the JVMTI call and then call > check_jvmti_error - but all that does is record if it passed or > failed. If it failed you still continue with the next operation even > if it relies on the success of the first one eg: > > 378 set_thread_local(jvmti, thread, exp_val); > 379 act_val = get_thread_local(jvmti, cur_thread); > > and the sequences in print_method_info: > > 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); > 229 check_jvmti_error(jvmti, "IsMethodNative", err); > 230 printf(" Method is native: %d\n", is_native); > 231 > 232 if (is_native == JNI_FALSE) { > 233 err = (*jvmti)->GetMaxLocals(jvmti, method, &locals_max); > > The call at #233 may not be valid because the method actually is > native but the IsMethodNative call failed for some reason. > It is intentional. I have done it as a last cleanup. The point is to simplify code by skipping all the extra checks if it does not lead to any fatal errors. The most important in such a case is that the static variable result is set to FAILED. It will cause the test to fail. Then there is no point to analyze the printed results if a JVMTI error reported before. If you insist, I will add back all the extra check to make sure all printed output is valid. Thanks, Serguei > Thanks, > David > ----- > >> >> >> Summary: >> The task was to provide a test coverage for the JVMTI functions >> allowed during the start phase. >> It includes both enabling and disabling the can_generate_early_vmstart >> capability. >> Testing the JVMTI functions allowed in any case has not been targeted >> by this fix. >> >> Testing: >> New test is passed. >> >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Fri Apr 28 08:07:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 01:07:56 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> Message-ID: <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> The updated webrev is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ I've re-arranged a little bit code in the ClassPrepare callback and the function test_class_functions(). Thanks, Serguei On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for looking at the test! > > > On 4/27/17 23:11, David Holmes wrote: >> Hi Serguei, >> >> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 10 fix for the test enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>> >> >> Sorry but I can't quite figure out exactly what this test is doing. >> What is the overall call structure here? > > This is to make sure the functions allowed in the start and live > phases work Ok. > As the list of functions is pretty big the test does sanity checks > that the functions do not crash nor return errors. > > >> I was expecting to see a difference between things that can be called >> at early-start and those that can not - or are these all expected to >> work okay in either case? > > All these functions are expected to work okay in both cases. > Of course, the main concern is the early start. > But we have never had such coverage in the past so that the normal > start phase needs to be covered too. > > >> >> A few comments: >> >> 44 #define TranslateError(err) "JVMTI error" >> >> I don't see the point of the above. > > Good catch - removed. > It is a left over from another test that I used as initial template. > > >> --- >> >> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >> >> The thread local functions use "long" as the datatype but that will >> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >> for complete portability. > > The type long has the same format as the type void* which has to be > portable even on win-32. > But maybe I'm missing something. > Anyway, I've replaced it with the intptr_t. > > >> >> --- >> >> 277 printf(" Filed declaring"); >> >> typo: filed -> field > > > Good catch - fixed. > >> >> --- >> >> All your little wrapper functions make the JVMTI call and then call >> check_jvmti_error - but all that does is record if it passed or >> failed. If it failed you still continue with the next operation even >> if it relies on the success of the first one eg: >> >> 378 set_thread_local(jvmti, thread, exp_val); >> 379 act_val = get_thread_local(jvmti, cur_thread); >> >> and the sequences in print_method_info: >> >> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >> 230 printf(" Method is native: %d\n", is_native); >> 231 >> 232 if (is_native == JNI_FALSE) { >> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, &locals_max); >> >> The call at #233 may not be valid because the method actually is >> native but the IsMethodNative call failed for some reason. >> > > It is intentional. I have done it as a last cleanup. > The point is to simplify code by skipping all the extra checks if it > does not lead to any fatal errors. > The most important in such a case is that the static variable result > is set to FAILED. > It will cause the test to fail. > Then there is no point to analyze the printed results if a JVMTI error > reported before. > > If you insist, I will add back all the extra check to make sure all > printed output is valid. > > > Thanks, > Serguei > >> Thanks, >> David >> ----- >> >>> >>> >>> Summary: >>> The task was to provide a test coverage for the JVMTI functions >>> allowed during the start phase. >>> It includes both enabling and disabling the >>> can_generate_early_vmstart >>> capability. >>> Testing the JVMTI functions allowed in any case has not been targeted >>> by this fix. >>> >>> Testing: >>> New test is passed. >>> >>> >>> Thanks, >>> Serguei > From serguei.spitsyn at oracle.com Fri Apr 28 08:54:53 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 01:54:53 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> Message-ID: <8cbc7547-7e0f-e86e-baea-37a59788ce68@oracle.com> On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for looking at the test! > > > On 4/27/17 23:11, David Holmes wrote: >> Hi Serguei, >> >> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the jdk 10 fix for the test enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>> >> >> Sorry but I can't quite figure out exactly what this test is doing. >> What is the overall call structure here? > > This is to make sure the functions allowed in the start and live > phases work Ok. To be more clear: "during the start or live phase". Thanks, Serguei > As the list of functions is pretty big the test does sanity checks > that the functions do not crash nor return errors. > From david.holmes at oracle.com Fri Apr 28 11:42:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Apr 2017 21:42:18 +1000 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> Message-ID: Hi Serguei, On 28/04/2017 6:07 PM, serguei.spitsyn at oracle.com wrote: > The updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ Thanks for the updates (the issue with long is that on win64 it is only 32-bit while void* is 64-bit). I prefer to see fast-fail rather than potentially triggering cascading failures (check_jvmti_error could even call exit() I think). But let's see what others think - it's only a preference not a necessity. Thanks, David > > I've re-arranged a little bit code in the ClassPrepare callback and the > function test_class_functions(). > > Thanks, > Serguei > > > On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for looking at the test! >> >> >> On 4/27/17 23:11, David Holmes wrote: >>> Hi Serguei, >>> >>> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the jdk 10 fix for the test enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>>> >>> >>> Sorry but I can't quite figure out exactly what this test is doing. >>> What is the overall call structure here? >> >> This is to make sure the functions allowed in the start and live >> phases work Ok. >> As the list of functions is pretty big the test does sanity checks >> that the functions do not crash nor return errors. >> >> >>> I was expecting to see a difference between things that can be called >>> at early-start and those that can not - or are these all expected to >>> work okay in either case? >> >> All these functions are expected to work okay in both cases. >> Of course, the main concern is the early start. >> But we have never had such coverage in the past so that the normal >> start phase needs to be covered too. >> >> >>> >>> A few comments: >>> >>> 44 #define TranslateError(err) "JVMTI error" >>> >>> I don't see the point of the above. >> >> Good catch - removed. >> It is a left over from another test that I used as initial template. >> >> >>> --- >>> >>> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >>> >>> The thread local functions use "long" as the datatype but that will >>> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >>> for complete portability. >> >> The type long has the same format as the type void* which has to be >> portable even on win-32. >> But maybe I'm missing something. >> Anyway, I've replaced it with the intptr_t. >> >> >>> >>> --- >>> >>> 277 printf(" Filed declaring"); >>> >>> typo: filed -> field >> >> >> Good catch - fixed. >> >>> >>> --- >>> >>> All your little wrapper functions make the JVMTI call and then call >>> check_jvmti_error - but all that does is record if it passed or >>> failed. If it failed you still continue with the next operation even >>> if it relies on the success of the first one eg: >>> >>> 378 set_thread_local(jvmti, thread, exp_val); >>> 379 act_val = get_thread_local(jvmti, cur_thread); >>> >>> and the sequences in print_method_info: >>> >>> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >>> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >>> 230 printf(" Method is native: %d\n", is_native); >>> 231 >>> 232 if (is_native == JNI_FALSE) { >>> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, &locals_max); >>> >>> The call at #233 may not be valid because the method actually is >>> native but the IsMethodNative call failed for some reason. >>> >> >> It is intentional. I have done it as a last cleanup. >> The point is to simplify code by skipping all the extra checks if it >> does not lead to any fatal errors. >> The most important in such a case is that the static variable result >> is set to FAILED. >> It will cause the test to fail. >> Then there is no point to analyze the printed results if a JVMTI error >> reported before. >> >> If you insist, I will add back all the extra check to make sure all >> printed output is valid. >> >> >> Thanks, >> Serguei >> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> >>>> Summary: >>>> The task was to provide a test coverage for the JVMTI functions >>>> allowed during the start phase. >>>> It includes both enabling and disabling the >>>> can_generate_early_vmstart >>>> capability. >>>> Testing the JVMTI functions allowed in any case has not been targeted >>>> by this fix. >>>> >>>> Testing: >>>> New test is passed. >>>> >>>> >>>> Thanks, >>>> Serguei >> > From serguei.spitsyn at oracle.com Fri Apr 28 17:34:15 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 10:34:15 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> Message-ID: <1e443485-63d6-4473-8809-76f47a380436@oracle.com> Hi David, On 4/28/17 04:42, David Holmes wrote: > Hi Serguei, > > On 28/04/2017 6:07 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ >> > > Thanks for the updates (the issue with long is that on win64 it is > only 32-bit while void* is 64-bit). Ok, thanks. Than you are right, using long on win64 is not compatible. > > I prefer to see fast-fail rather than potentially triggering cascading > failures (check_jvmti_error could even call exit() I think). But let's > see what others think - it's only a preference not a necessity. Ok, I'll consider call exit() as it would keep it simple. Thanks, Serguei > > Thanks, > David > >> >> I've re-arranged a little bit code in the ClassPrepare callback and the >> function test_class_functions(). >> >> Thanks, >> Serguei >> >> >> On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for looking at the test! >>> >>> >>> On 4/27/17 23:11, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review the jdk 10 fix for the test enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>>>> >>>>> >>>> >>>> Sorry but I can't quite figure out exactly what this test is doing. >>>> What is the overall call structure here? >>> >>> This is to make sure the functions allowed in the start and live >>> phases work Ok. >>> As the list of functions is pretty big the test does sanity checks >>> that the functions do not crash nor return errors. >>> >>> >>>> I was expecting to see a difference between things that can be called >>>> at early-start and those that can not - or are these all expected to >>>> work okay in either case? >>> >>> All these functions are expected to work okay in both cases. >>> Of course, the main concern is the early start. >>> But we have never had such coverage in the past so that the normal >>> start phase needs to be covered too. >>> >>> >>>> >>>> A few comments: >>>> >>>> 44 #define TranslateError(err) "JVMTI error" >>>> >>>> I don't see the point of the above. >>> >>> Good catch - removed. >>> It is a left over from another test that I used as initial template. >>> >>> >>>> --- >>>> >>>> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >>>> >>>> The thread local functions use "long" as the datatype but that will >>>> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >>>> for complete portability. >>> >>> The type long has the same format as the type void* which has to be >>> portable even on win-32. >>> But maybe I'm missing something. >>> Anyway, I've replaced it with the intptr_t. >>> >>> >>>> >>>> --- >>>> >>>> 277 printf(" Filed declaring"); >>>> >>>> typo: filed -> field >>> >>> >>> Good catch - fixed. >>> >>>> >>>> --- >>>> >>>> All your little wrapper functions make the JVMTI call and then call >>>> check_jvmti_error - but all that does is record if it passed or >>>> failed. If it failed you still continue with the next operation even >>>> if it relies on the success of the first one eg: >>>> >>>> 378 set_thread_local(jvmti, thread, exp_val); >>>> 379 act_val = get_thread_local(jvmti, cur_thread); >>>> >>>> and the sequences in print_method_info: >>>> >>>> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >>>> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >>>> 230 printf(" Method is native: %d\n", is_native); >>>> 231 >>>> 232 if (is_native == JNI_FALSE) { >>>> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, &locals_max); >>>> >>>> The call at #233 may not be valid because the method actually is >>>> native but the IsMethodNative call failed for some reason. >>>> >>> >>> It is intentional. I have done it as a last cleanup. >>> The point is to simplify code by skipping all the extra checks if it >>> does not lead to any fatal errors. >>> The most important in such a case is that the static variable result >>> is set to FAILED. >>> It will cause the test to fail. >>> Then there is no point to analyze the printed results if a JVMTI error >>> reported before. >>> >>> If you insist, I will add back all the extra check to make sure all >>> printed output is valid. >>> >>> >>> Thanks, >>> Serguei >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> >>>>> Summary: >>>>> The task was to provide a test coverage for the JVMTI functions >>>>> allowed during the start phase. >>>>> It includes both enabling and disabling the >>>>> can_generate_early_vmstart >>>>> capability. >>>>> Testing the JVMTI functions allowed in any case has not been >>>>> targeted >>>>> by this fix. >>>>> >>>>> Testing: >>>>> New test is passed. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>> >> From alexandre.iline at oracle.com Fri Apr 28 21:41:48 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 28 Apr 2017 14:41:48 -0700 Subject: RFR 8179457: Remove demo/jvmti tests Message-ID: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> Hi, Could you please take a quick look on a source code change to remove demo/jvmti tests: http://cr.openjdk.java.net/~shurailine/8179457/webrev.00/ The tests seem to only be testing the jvmti demos and not providing any useful test coverage beyond that. The demos are now removed as part of JEP 298: Remove Demos and Samples. Thank you. Shura From igor.ignatyev at oracle.com Fri Apr 28 21:43:50 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Apr 2017 14:43:50 -0700 Subject: RFR 8179457: Remove demo/jvmti tests In-Reply-To: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> References: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> Message-ID: <3306E3E8-F566-4D6F-89EF-8918C4376BAA@oracle.com> Hi Shura, the fix looks good to me, thank you for taking care of it. -- Igor > On Apr 28, 2017, at 2:41 PM, Alexandre (Shura) Iline wrote: > > Hi, > > Could you please take a quick look on a source code change to remove demo/jvmti tests: > http://cr.openjdk.java.net/~shurailine/8179457/webrev.00/ > > The tests seem to only be testing the jvmti demos and not providing any useful test coverage beyond that. The demos are now removed as part of JEP 298: Remove Demos and Samples. > > Thank you. > > Shura > > From tj.fontaine at oracle.com Fri Apr 28 22:23:13 2017 From: tj.fontaine at oracle.com (TJ Fontaine) Date: Fri, 28 Apr 2017 15:23:13 -0700 Subject: [PATCH] attach in linux should be relative to /proc/pid/root and namespace aware Message-ID: I have attached a patch that allows jcmd to work against a java process running inside a Docker container. Apologies if this is not in the correct format. It was built against jdk8u. I couldn?t seem to find an existing JIRA for it. Diagnostic commands (i.e. jcmd, jstack, etc) fail to attach to a target JVM that is inside a container (e.g. Docker). A Linux container often isolates a process in a PID and Mount namespace that is separate from the "root container" (analogous to the hypervisor/dom0 in hardware virtualization environments, or the global zone on Solaris). A target JVM that is isolated in either a PID namespace, or a Mount namespace will fail the attach sequence. When the target JVM is in its own PID namespace the pid of the process is distinct from what the real pid of the process as it relates to the root container. For example, in the root container you can observe a JVM with a pid of 17734, however if that JVM is running inside a Docker container the pid inside its PID namespace is likely 1. So when the target JVM receives the SIGQUIT it looks in /proc/self/cwd/ for .attach_pid1 however the external attaching JVM has created the file /proc/17734/cwd/.attach_pid17734. Given this discrepancy the target JVM will output to stderr thread status, since /proc/self/cwd/.attach_pid1 doesn't exist and won't continue with the attach sequence. The solution is to parse /proc/pid/status for the field NSpid (available since Linux 4.1) which contains a list of pids, where the last entry is the "inner most" PID namespace value. (Namespaces can be stacked, unlike Solaris Zones which have a virtualization depth of 1) The rest of the Linux attach sequence assumes a shared mount namespace by waiting for /tmp/.java_pid17734 to appear. But if the attaching process is in a separate namespace because the target JVM is in a mount namepsace (or in a chroot as well) the unix domain socket for attaching won't appear. Instead the attach sequence should resolve file names relative to /proc/17734/root which has a materialized view of the rootfs for the target. Thanks! TJ -------------- next part -------------- A non-text attachment was scrubbed... Name: attach_namespace_aware.patch Type: application/octet-stream Size: 6614 bytes Desc: not available URL: From jonathan.gibbons at oracle.com Fri Apr 28 22:29:31 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 28 Apr 2017 15:29:31 -0700 Subject: RFR: 8179460: Fix unnecessary uses of {@docRoot} in serviceability APIs Message-ID: <5903C24B.2070205@oracle.com> Please review the following simple changes to update use of {@docRoot} in doc comments now that we have a single docs bundle. Most instances in this review can be replaced with direct references using @see or {@link}. One use of {@docRoot} remains, but modified, to refer to an explicit anchor in another file. JBS: https://bugs.openjdk.java.net/browse/JDK-8179460 Webrev: http://cr.openjdk.java.net/~jjg/8179460/webrev/ -- Jon From mandy.chung at oracle.com Fri Apr 28 22:36:01 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 28 Apr 2017 15:36:01 -0700 Subject: RFR: 8179460: Fix unnecessary uses of {@docRoot} in serviceability APIs In-Reply-To: <5903C24B.2070205@oracle.com> References: <5903C24B.2070205@oracle.com> Message-ID: <059FA6AB-A589-427E-B93F-311AF591AB8F@oracle.com> > On Apr 28, 2017, at 3:29 PM, Jonathan Gibbons wrote: > > Please review the following simple changes to update use of {@docRoot} in doc comments now that we have a single docs bundle. > > Most instances in this review can be replaced with direct references using @see or {@link}. One use of {@docRoot} remains, but modified, to refer to an explicit anchor in another file. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179460 > Webrev: http://cr.openjdk.java.net/~jjg/8179460/webrev/ +1 I?m happy that we finally no longer need to do these cross docs bundle references. Thanks to the unified docs bundle. Mandy From david.holmes at oracle.com Fri Apr 28 22:42:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 29 Apr 2017 08:42:36 +1000 Subject: [PATCH] attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: References: Message-ID: <36e2184f-6527-0aad-b156-b12719cfbd8a@oracle.com> Hi TJ, Thanks for the patch (I haven't looked at it yet). FYI at the moment, unless this is considered a high priority bug for JDK 9 it has to be targeted to JDK 10, and then possibly backported to 9 and 8u. Cheers, David On 29/04/2017 8:23 AM, TJ Fontaine wrote: > I have attached a patch that allows jcmd to work against a java process running > inside a Docker container. Apologies if this is not in the correct format. It was > built against jdk8u. I couldn?t seem to find an existing JIRA for it. > > Diagnostic commands (i.e. jcmd, jstack, etc) fail to attach to a target JVM > that is inside a container (e.g. Docker). > > A Linux container often isolates a process in a PID and Mount namespace that is > separate from the "root container" (analogous to the hypervisor/dom0 in > hardware virtualization environments, or the global zone on Solaris). A target > JVM that is isolated in either a PID namespace, or a Mount namespace will fail > the attach sequence. > > When the target JVM is in its own PID namespace the pid of the process is > distinct from what the real pid of the process as it relates to the root > container. For example, in the root container you can observe a JVM with a pid > of 17734, however if that JVM is running inside a Docker container the pid > inside its PID namespace is likely 1. So when the target JVM receives the > SIGQUIT it looks in /proc/self/cwd/ for .attach_pid1 however the external > attaching JVM has created the file /proc/17734/cwd/.attach_pid17734. Given this > discrepancy the target JVM will output to stderr thread status, since > /proc/self/cwd/.attach_pid1 doesn't exist and won't continue with the attach > sequence. > > The solution is to parse /proc/pid/status for the field NSpid (available since > Linux 4.1) which contains a list of pids, where the last entry is the "inner > most" PID namespace value. (Namespaces can be stacked, unlike Solaris Zones > which have a virtualization depth of 1) > > The rest of the Linux attach sequence assumes a shared mount namespace by > waiting for /tmp/.java_pid17734 to appear. But if the attaching process is in a > separate namespace because the target JVM is in a mount namepsace (or in a > chroot as well) the unix domain socket for attaching won't appear. > > Instead the attach sequence should resolve file names relative to > /proc/17734/root which has a materialized view of the rootfs for the target. > > Thanks! > > TJ > From tj.fontaine at oracle.com Fri Apr 28 22:47:30 2017 From: tj.fontaine at oracle.com (TJ Fontaine) Date: Fri, 28 Apr 2017 15:47:30 -0700 Subject: [PATCH] attach in linux should be relative to /proc/pid/root and namespace aware In-Reply-To: <36e2184f-6527-0aad-b156-b12719cfbd8a@oracle.com> References: <36e2184f-6527-0aad-b156-b12719cfbd8a@oracle.com> Message-ID: <7E81AA87-6B37-4023-8F74-C244CC906801@oracle.com> I had no doubt we?d end up on the conversation of 10 -> 9 -> 8u, I started with 8u merely because it was representative of today?s customer pain. I?ll be sure to work on retargeting it as well. Thanks! TJ On 4/28/17, 3:42 PM, "David Holmes" wrote: Hi TJ, Thanks for the patch (I haven't looked at it yet). FYI at the moment, unless this is considered a high priority bug for JDK 9 it has to be targeted to JDK 10, and then possibly backported to 9 and 8u. Cheers, David On 29/04/2017 8:23 AM, TJ Fontaine wrote: > I have attached a patch that allows jcmd to work against a java process running > inside a Docker container. Apologies if this is not in the correct format. It was > built against jdk8u. I couldn?t seem to find an existing JIRA for it. > > Diagnostic commands (i.e. jcmd, jstack, etc) fail to attach to a target JVM > that is inside a container (e.g. Docker). > > A Linux container often isolates a process in a PID and Mount namespace that is > separate from the "root container" (analogous to the hypervisor/dom0 in > hardware virtualization environments, or the global zone on Solaris). A target > JVM that is isolated in either a PID namespace, or a Mount namespace will fail > the attach sequence. > > When the target JVM is in its own PID namespace the pid of the process is > distinct from what the real pid of the process as it relates to the root > container. For example, in the root container you can observe a JVM with a pid > of 17734, however if that JVM is running inside a Docker container the pid > inside its PID namespace is likely 1. So when the target JVM receives the > SIGQUIT it looks in /proc/self/cwd/ for .attach_pid1 however the external > attaching JVM has created the file /proc/17734/cwd/.attach_pid17734. Given this > discrepancy the target JVM will output to stderr thread status, since > /proc/self/cwd/.attach_pid1 doesn't exist and won't continue with the attach > sequence. > > The solution is to parse /proc/pid/status for the field NSpid (available since > Linux 4.1) which contains a list of pids, where the last entry is the "inner > most" PID namespace value. (Namespaces can be stacked, unlike Solaris Zones > which have a virtualization depth of 1) > > The rest of the Linux attach sequence assumes a shared mount namespace by > waiting for /tmp/.java_pid17734 to appear. But if the attaching process is in a > separate namespace because the target JVM is in a mount namepsace (or in a > chroot as well) the unix domain socket for attaching won't appear. > > Instead the attach sequence should resolve file names relative to > /proc/17734/root which has a materialized view of the rootfs for the target. > > Thanks! > > TJ > From kumar.x.srinivasan at oracle.com Fri Apr 28 23:16:19 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 28 Apr 2017 16:16:19 -0700 Subject: RFR: 8179415: Update java.management and java.management.rmi to be HTML-5 friendly Message-ID: <5903CD43.3030402@oracle.com> Hello, Please review changes for java.management and java.management.rmi to be HTML5 ready, there are outliers like cellpadding, cellspacing that needs to be done separately, note this was *not* done mechanically by a script. http://cr.openjdk.java.net/~ksrini/8179415/ https://bugs.openjdk.java.net/browse/JDK-8179415 Thanks Kumar From mandy.chung at oracle.com Fri Apr 28 23:39:28 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 28 Apr 2017 16:39:28 -0700 Subject: RFR: 8179415: Update java.management and java.management.rmi to be HTML-5 friendly In-Reply-To: <5903CD43.3030402@oracle.com> References: <5903CD43.3030402@oracle.com> Message-ID: <6C740129-09DF-4E41-ABEB-57DD5F2D9C0F@oracle.com> > On Apr 28, 2017, at 4:16 PM, Kumar Srinivasan wrote: > > Hello, > > Please review changes for java.management and java.management.rmi to > be HTML5 ready, there are outliers like cellpadding, cellspacing that needs > to be done separately, note this was *not* done mechanically by a script. > > http://cr.openjdk.java.net/~ksrini/8179415/ > https://bugs.openjdk.java.net/browse/JDK-8179415 Looks fine to me. Mandy From serguei.spitsyn at oracle.com Sat Apr 29 00:13:56 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 17:13:56 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: <1e443485-63d6-4473-8809-76f47a380436@oracle.com> References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> <1e443485-63d6-4473-8809-76f47a380436@oracle.com> Message-ID: Hi David, On 4/28/17 10:34, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 4/28/17 04:42, David Holmes wrote: >> Hi Serguei, >> >> On 28/04/2017 6:07 PM, serguei.spitsyn at oracle.com wrote: >>> The updated webrev is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ >>> >> >> Thanks for the updates (the issue with long is that on win64 it is >> only 32-bit while void* is 64-bit). > > Ok, thanks. > Than you are right, using long on win64 is not compatible. > >> >> I prefer to see fast-fail rather than potentially triggering >> cascading failures (check_jvmti_error could even call exit() I >> think). But let's see what others think - it's only a preference not >> a necessity. > > Ok, I'll consider call exit() as it would keep it simple. > New webrev version is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.3/ Thanks, Serguei > Thanks, > Serguei > >> >> Thanks, >> David >> >>> >>> I've re-arranged a little bit code in the ClassPrepare callback and the >>> function test_class_functions(). >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for looking at the test! >>>> >>>> >>>> On 4/27/17 23:11, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review the jdk 10 fix for the test enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>>>>> >>>>>> >>>>> >>>>> Sorry but I can't quite figure out exactly what this test is doing. >>>>> What is the overall call structure here? >>>> >>>> This is to make sure the functions allowed in the start and live >>>> phases work Ok. >>>> As the list of functions is pretty big the test does sanity checks >>>> that the functions do not crash nor return errors. >>>> >>>> >>>>> I was expecting to see a difference between things that can be called >>>>> at early-start and those that can not - or are these all expected to >>>>> work okay in either case? >>>> >>>> All these functions are expected to work okay in both cases. >>>> Of course, the main concern is the early start. >>>> But we have never had such coverage in the past so that the normal >>>> start phase needs to be covered too. >>>> >>>> >>>>> >>>>> A few comments: >>>>> >>>>> 44 #define TranslateError(err) "JVMTI error" >>>>> >>>>> I don't see the point of the above. >>>> >>>> Good catch - removed. >>>> It is a left over from another test that I used as initial template. >>>> >>>> >>>>> --- >>>>> >>>>> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >>>>> >>>>> The thread local functions use "long" as the datatype but that will >>>>> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >>>>> for complete portability. >>>> >>>> The type long has the same format as the type void* which has to be >>>> portable even on win-32. >>>> But maybe I'm missing something. >>>> Anyway, I've replaced it with the intptr_t. >>>> >>>> >>>>> >>>>> --- >>>>> >>>>> 277 printf(" Filed declaring"); >>>>> >>>>> typo: filed -> field >>>> >>>> >>>> Good catch - fixed. >>>> >>>>> >>>>> --- >>>>> >>>>> All your little wrapper functions make the JVMTI call and then call >>>>> check_jvmti_error - but all that does is record if it passed or >>>>> failed. If it failed you still continue with the next operation even >>>>> if it relies on the success of the first one eg: >>>>> >>>>> 378 set_thread_local(jvmti, thread, exp_val); >>>>> 379 act_val = get_thread_local(jvmti, cur_thread); >>>>> >>>>> and the sequences in print_method_info: >>>>> >>>>> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >>>>> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >>>>> 230 printf(" Method is native: %d\n", is_native); >>>>> 231 >>>>> 232 if (is_native == JNI_FALSE) { >>>>> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, >>>>> &locals_max); >>>>> >>>>> The call at #233 may not be valid because the method actually is >>>>> native but the IsMethodNative call failed for some reason. >>>>> >>>> >>>> It is intentional. I have done it as a last cleanup. >>>> The point is to simplify code by skipping all the extra checks if it >>>> does not lead to any fatal errors. >>>> The most important in such a case is that the static variable result >>>> is set to FAILED. >>>> It will cause the test to fail. >>>> Then there is no point to analyze the printed results if a JVMTI error >>>> reported before. >>>> >>>> If you insist, I will add back all the extra check to make sure all >>>> printed output is valid. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> The task was to provide a test coverage for the JVMTI functions >>>>>> allowed during the start phase. >>>>>> It includes both enabling and disabling the >>>>>> can_generate_early_vmstart >>>>>> capability. >>>>>> Testing the JVMTI functions allowed in any case has not been >>>>>> targeted >>>>>> by this fix. >>>>>> >>>>>> Testing: >>>>>> New test is passed. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> > From serguei.spitsyn at oracle.com Sat Apr 29 00:17:06 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 17:17:06 -0700 Subject: RFR 8179457: Remove demo/jvmti tests In-Reply-To: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> References: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> Message-ID: Hi Shura, The tests removal looks good to me. Thanks, Serguei On 4/28/17 14:41, Alexandre (Shura) Iline wrote: > Hi, > > Could you please take a quick look on a source code change to remove demo/jvmti tests: > http://cr.openjdk.java.net/~shurailine/8179457/webrev.00/ > > The tests seem to only be testing the jvmti demos and not providing any useful test coverage beyond that. The demos are now removed as part of JEP 298: Remove Demos and Samples. > > Thank you. > > Shura > > From david.holmes at oracle.com Sat Apr 29 01:08:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 29 Apr 2017 11:08:46 +1000 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> <1e443485-63d6-4473-8809-76f47a380436@oracle.com> Message-ID: <6d196b42-cb4f-b599-c25f-1fc3f66bcc2f@oracle.com> That looks fine to me Serguei! Thanks, David On 29/04/2017 10:13 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 4/28/17 10:34, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 4/28/17 04:42, David Holmes wrote: >>> Hi Serguei, >>> >>> On 28/04/2017 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>> The updated webrev is: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ >>>> >>> >>> Thanks for the updates (the issue with long is that on win64 it is >>> only 32-bit while void* is 64-bit). >> >> Ok, thanks. >> Than you are right, using long on win64 is not compatible. >> >>> >>> I prefer to see fast-fail rather than potentially triggering >>> cascading failures (check_jvmti_error could even call exit() I >>> think). But let's see what others think - it's only a preference not >>> a necessity. >> >> Ok, I'll consider call exit() as it would keep it simple. >> > > New webrev version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.3/ > > > > Thanks, > Serguei > > >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>>> >>>> I've re-arranged a little bit code in the ClassPrepare callback and the >>>> function test_class_functions(). >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> Thank you for looking at the test! >>>>> >>>>> >>>>> On 4/27/17 23:11, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review the jdk 10 fix for the test enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>>>>>> >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>>>>>> >>>>>>> >>>>>> >>>>>> Sorry but I can't quite figure out exactly what this test is doing. >>>>>> What is the overall call structure here? >>>>> >>>>> This is to make sure the functions allowed in the start and live >>>>> phases work Ok. >>>>> As the list of functions is pretty big the test does sanity checks >>>>> that the functions do not crash nor return errors. >>>>> >>>>> >>>>>> I was expecting to see a difference between things that can be called >>>>>> at early-start and those that can not - or are these all expected to >>>>>> work okay in either case? >>>>> >>>>> All these functions are expected to work okay in both cases. >>>>> Of course, the main concern is the early start. >>>>> But we have never had such coverage in the past so that the normal >>>>> start phase needs to be covered too. >>>>> >>>>> >>>>>> >>>>>> A few comments: >>>>>> >>>>>> 44 #define TranslateError(err) "JVMTI error" >>>>>> >>>>>> I don't see the point of the above. >>>>> >>>>> Good catch - removed. >>>>> It is a left over from another test that I used as initial template. >>>>> >>>>> >>>>>> --- >>>>>> >>>>>> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >>>>>> >>>>>> The thread local functions use "long" as the datatype but that will >>>>>> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >>>>>> for complete portability. >>>>> >>>>> The type long has the same format as the type void* which has to be >>>>> portable even on win-32. >>>>> But maybe I'm missing something. >>>>> Anyway, I've replaced it with the intptr_t. >>>>> >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> 277 printf(" Filed declaring"); >>>>>> >>>>>> typo: filed -> field >>>>> >>>>> >>>>> Good catch - fixed. >>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> All your little wrapper functions make the JVMTI call and then call >>>>>> check_jvmti_error - but all that does is record if it passed or >>>>>> failed. If it failed you still continue with the next operation even >>>>>> if it relies on the success of the first one eg: >>>>>> >>>>>> 378 set_thread_local(jvmti, thread, exp_val); >>>>>> 379 act_val = get_thread_local(jvmti, cur_thread); >>>>>> >>>>>> and the sequences in print_method_info: >>>>>> >>>>>> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >>>>>> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >>>>>> 230 printf(" Method is native: %d\n", is_native); >>>>>> 231 >>>>>> 232 if (is_native == JNI_FALSE) { >>>>>> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, >>>>>> &locals_max); >>>>>> >>>>>> The call at #233 may not be valid because the method actually is >>>>>> native but the IsMethodNative call failed for some reason. >>>>>> >>>>> >>>>> It is intentional. I have done it as a last cleanup. >>>>> The point is to simplify code by skipping all the extra checks if it >>>>> does not lead to any fatal errors. >>>>> The most important in such a case is that the static variable result >>>>> is set to FAILED. >>>>> It will cause the test to fail. >>>>> Then there is no point to analyze the printed results if a JVMTI error >>>>> reported before. >>>>> >>>>> If you insist, I will add back all the extra check to make sure all >>>>> printed output is valid. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> The task was to provide a test coverage for the JVMTI functions >>>>>>> allowed during the start phase. >>>>>>> It includes both enabling and disabling the >>>>>>> can_generate_early_vmstart >>>>>>> capability. >>>>>>> Testing the JVMTI functions allowed in any case has not been >>>>>>> targeted >>>>>>> by this fix. >>>>>>> >>>>>>> Testing: >>>>>>> New test is passed. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>> >>>> >> > From serguei.spitsyn at oracle.com Sat Apr 29 04:33:04 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 28 Apr 2017 21:33:04 -0700 Subject: RFR(M): 8172970: TESTBUG: need test coverage for the JVMTI functions allowed in the start phase In-Reply-To: <6d196b42-cb4f-b599-c25f-1fc3f66bcc2f@oracle.com> References: <88938aee-0a83-99e9-1b95-6875173807a5@oracle.com> <5ea66d4b-f1bb-1729-ba51-5bdcd5b3c470@oracle.com> <1e443485-63d6-4473-8809-76f47a380436@oracle.com> <6d196b42-cb4f-b599-c25f-1fc3f66bcc2f@oracle.com> Message-ID: <3eb94f3b-142c-6cd6-3d15-a0ab840880dc@oracle.com> Thanks, David! Serguei On 4/28/17 18:08, David Holmes wrote: > That looks fine to me Serguei! > > Thanks, > David > > On 29/04/2017 10:13 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 4/28/17 10:34, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 4/28/17 04:42, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 28/04/2017 6:07 PM, serguei.spitsyn at oracle.com wrote: >>>>> The updated webrev is: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.2/ >>>>> >>>>> >>>> >>>> Thanks for the updates (the issue with long is that on win64 it is >>>> only 32-bit while void* is 64-bit). >>> >>> Ok, thanks. >>> Than you are right, using long on win64 is not compatible. >>> >>>> >>>> I prefer to see fast-fail rather than potentially triggering >>>> cascading failures (check_jvmti_error could even call exit() I >>>> think). But let's see what others think - it's only a preference not >>>> a necessity. >>> >>> Ok, I'll consider call exit() as it would keep it simple. >>> >> >> New webrev version is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.3/ >> >> >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> I've re-arranged a little bit code in the ClassPrepare callback >>>>> and the >>>>> function test_class_functions(). >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 4/28/17 00:47, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for looking at the test! >>>>>> >>>>>> >>>>>> On 4/27/17 23:11, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 28/04/2017 3:14 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the jdk 10 fix for the test enhancement: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172970 >>>>>>>> >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8172970-start-phase.1/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Sorry but I can't quite figure out exactly what this test is doing. >>>>>>> What is the overall call structure here? >>>>>> >>>>>> This is to make sure the functions allowed in the start and live >>>>>> phases work Ok. >>>>>> As the list of functions is pretty big the test does sanity checks >>>>>> that the functions do not crash nor return errors. >>>>>> >>>>>> >>>>>>> I was expecting to see a difference between things that can be >>>>>>> called >>>>>>> at early-start and those that can not - or are these all >>>>>>> expected to >>>>>>> work okay in either case? >>>>>> >>>>>> All these functions are expected to work okay in both cases. >>>>>> Of course, the main concern is the early start. >>>>>> But we have never had such coverage in the past so that the normal >>>>>> start phase needs to be covered too. >>>>>> >>>>>> >>>>>>> >>>>>>> A few comments: >>>>>>> >>>>>>> 44 #define TranslateError(err) "JVMTI error" >>>>>>> >>>>>>> I don't see the point of the above. >>>>>> >>>>>> Good catch - removed. >>>>>> It is a left over from another test that I used as initial template. >>>>>> >>>>>> >>>>>>> --- >>>>>>> >>>>>>> 99 static long get_thread_local(jvmtiEnv *jvmti, jthread thread) { >>>>>>> >>>>>>> The thread local functions use "long" as the datatype but that will >>>>>>> only be 32-bit on 64-bit Windows. I think you need to use intptr_t >>>>>>> for complete portability. >>>>>> >>>>>> The type long has the same format as the type void* which has to be >>>>>> portable even on win-32. >>>>>> But maybe I'm missing something. >>>>>> Anyway, I've replaced it with the intptr_t. >>>>>> >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> 277 printf(" Filed declaring"); >>>>>>> >>>>>>> typo: filed -> field >>>>>> >>>>>> >>>>>> Good catch - fixed. >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> All your little wrapper functions make the JVMTI call and then call >>>>>>> check_jvmti_error - but all that does is record if it passed or >>>>>>> failed. If it failed you still continue with the next operation >>>>>>> even >>>>>>> if it relies on the success of the first one eg: >>>>>>> >>>>>>> 378 set_thread_local(jvmti, thread, exp_val); >>>>>>> 379 act_val = get_thread_local(jvmti, cur_thread); >>>>>>> >>>>>>> and the sequences in print_method_info: >>>>>>> >>>>>>> 228 err = (*jvmti)->IsMethodNative(jvmti, method, &is_native); >>>>>>> 229 check_jvmti_error(jvmti, "IsMethodNative", err); >>>>>>> 230 printf(" Method is native: %d\n", is_native); >>>>>>> 231 >>>>>>> 232 if (is_native == JNI_FALSE) { >>>>>>> 233 err = (*jvmti)->GetMaxLocals(jvmti, method, >>>>>>> &locals_max); >>>>>>> >>>>>>> The call at #233 may not be valid because the method actually is >>>>>>> native but the IsMethodNative call failed for some reason. >>>>>>> >>>>>> >>>>>> It is intentional. I have done it as a last cleanup. >>>>>> The point is to simplify code by skipping all the extra checks if it >>>>>> does not lead to any fatal errors. >>>>>> The most important in such a case is that the static variable result >>>>>> is set to FAILED. >>>>>> It will cause the test to fail. >>>>>> Then there is no point to analyze the printed results if a JVMTI >>>>>> error >>>>>> reported before. >>>>>> >>>>>> If you insist, I will add back all the extra check to make sure all >>>>>> printed output is valid. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> The task was to provide a test coverage for the JVMTI functions >>>>>>>> allowed during the start phase. >>>>>>>> It includes both enabling and disabling the >>>>>>>> can_generate_early_vmstart >>>>>>>> capability. >>>>>>>> Testing the JVMTI functions allowed in any case has not been >>>>>>>> targeted >>>>>>>> by this fix. >>>>>>>> >>>>>>>> Testing: >>>>>>>> New test is passed. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>> >>>>> >>> >> From Alan.Bateman at oracle.com Sat Apr 29 07:18:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 29 Apr 2017 08:18:42 +0100 Subject: RFR 8179457: Remove demo/jvmti tests In-Reply-To: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> References: <22DDB73C-22AB-42F2-B399-5C8CA9D9140B@oracle.com> Message-ID: On 28/04/2017 22:41, Alexandre (Shura) Iline wrote: > Hi, > > Could you please take a quick look on a source code change to remove demo/jvmti tests: > http://cr.openjdk.java.net/~shurailine/8179457/webrev.00/ > > The tests seem to only be testing the jvmti demos and not providing any useful test coverage beyond that. The demos are now removed as part of JEP 298: Remove Demos and Samples. > Looks good.