From daniel.fuchs at oracle.com Mon Apr 1 09:51:56 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 1 Apr 2019 10:51:56 +0100 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: Hi Arthur, Not directly related to Alex's original question but... On 30/03/2019 00:03, Arthur Eubanks wrote: > We have some ipv6 patches as well in this area as well (as well as other > patches to support ipv6 only environments) that we're trying to > upstream. I don't understand the code myself, but it might be useful to > take a look: > http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html SocketTransportService.java: On my machine at least, InetAddress.getByName("localhost") and InetAddress.getLocalHost() are quite different: InetAddress.getByName("localhost") will return the loopback (127.0.0.1) InetAddress.getLocalHost() returns the local hostname (dhcp-XXX-XXX...) If I'm not mistaken your changes in HostPort would transform something that previously returned the loopback (no host specified) with something that returns the local host name ("*" specified). So I'm not sure these changes are quite right. Maybe Alex will be able to confirm. best regards, -- daniel From chris.hegarty at oracle.com Mon Apr 1 11:50:42 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 1 Apr 2019 12:50:42 +0100 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: Alex, On 29/03/2019 22:07, Alex Menkov wrote: > (added net-dev as suggested by Alan) > > Net gurus, please assist in reviewing socket-related code. > > New webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ Specifically on SocketTransportService.java. What Arthur has proposed is better ( changing to lastIndexOf alone is not sufficient ). Or is your assumption that the IPv6 literal is not enclosed in square brackets? If keeping Arthur's `static class HostPort` please make the fields final. >> Would it make sense to support the preference properties? >> java.net.preferIPv4Stack >> java.net.preferIPv6Addresses I'm not sure about this, especially given the property name prefixes. I need to think a little more on it. There is quite a bit of new native code, is it possible to rewrite any of this in Java, e.g. reading of the system properties ( if that is to remain )? -Chris. From chris.hegarty at oracle.com Mon Apr 1 12:02:31 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 1 Apr 2019 13:02:31 +0100 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: <919bbc04-d908-9198-0ec6-2ea04cad0fbc@oracle.com> On 01/04/2019 12:50, Chris Hegarty wrote: > ... > Specifically on SocketTransportService.java. What Arthur has > proposed is better ( changing to lastIndexOf alone is not > sufficient ). Or is your assumption that the IPv6 literal is > not enclosed in square brackets? More specifically, what syntax are you proposing to pass IPv6 addresses from the command line? -Chris From zanglin5 at jd.com Mon Apr 1 12:16:53 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Mon, 1 Apr 2019 12:16:53 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <29678a6a45ba490b8411315e0ad95837@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> Message-ID: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul ; serviceability- dev at openjdk.java.net; ?? Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul > ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev > on behalf of ?? > Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Mon Apr 1 12:22:40 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 01 Apr 2019 08:22:40 -0400 Subject: LingeredApp termination sequence In-Reply-To: <27b13316-90c8-80d1-d751-9db70249d166@samersoff.net> References: <5C9E5201.4090106@oracle.com> <27b13316-90c8-80d1-d751-9db70249d166@samersoff.net> Message-ID: <5CA20290.1080600@oracle.com> The problem I was trying to understand a little better ... I was observing an IOException, but it was not a NoSuchFileException. Changing to catch just IOException runs cleanly, but may obscure some other cause of the IOException. Testing a variant today that exits cleanly as long as the lock file was removed. diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java b/test/lib/jdk/test/lib/apps/LingeredApp.java --- a/test/lib/jdk/test/lib/apps/LingeredApp.java +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -492,18 +492,21 @@ } String theLockFileName = args[0]; + Path path = Paths.get(theLockFileName); try { - Path path = Paths.get(theLockFileName); - while (Files.exists(path)) { // Touch the lock to indicate our readiness setLastModified(theLockFileName, epoch()); Thread.sleep(spinDelay); } - } catch (NoSuchFileException ex) { + } catch (IOException ex) { // Lock deleted while we are setting last modified time. - // Ignore error and lets the app exits + // Ignore the error and let the app exit. + if (Files.exists(path)) { + // If the lock file was not removed, return an error. + System.exit(4); + } } catch (Exception ex) { System.err.println("LingeredApp ERROR: " + ex); // Leave exit_code = 1 to Java launcher During the latest set of test runs I saw a variety of RMI binding errors. These could be issues with the test infrastructure systems. Or could be collisions from the test harness. [Jstatd-Thread] Could not bind /JStatRemoteHost to RMI Registry [Jstatd-Thread] java.rmi.server.ExportException: Port already in use: 1099; nested exception is: [Jstatd-Thread] java.net.BindException: Address already in use: NET_Bind [Jstatd-Thread] at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) [Jstatd-Thread] Could not bind //:49153/JStatRemoteHost to RMI Registry [Jstatd-Thread] java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: [Jstatd-Thread] java.net.SocketTimeoutException: Read timed out [Jstatd-Thread] Could not bind //:33712/JStatRemoteHost to RMI Registry [Jstatd-Thread] java.rmi.server.ExportException: Port already in use: 33712; nested exception is: [Jstatd-Thread] java.net.BindException: Address already in use (Bind failed) [Jstatd-Thread] Could not bind //:58765/TestJstatdServer to RMI Registry [Jstatd-Thread] java.rmi.ConnectIOException: Exception creating connection to: 10.133.156.143; nested exception is: [Jstatd-Thread] java.net.NoRouteToHostException: Cannot assign requested address On 3/30/19, 9:46 AM, Dmitry Samersoff wrote: > Hello Gary, > > The LingeredApp was designed to provide precise control over the life > cycle of a subordinate process. > > This means that if the app exits unexpectedly, we should have detailed > information why it happens. > > IOException may occur when the app tries to touch lockfile (e.g. due to > a network filesystem error), so it might be better to catch IOException, > then check if it is an instance of NoSuchFileException or the lockfile > was deleted by driver. > > -Dmitry > > On 29.03.2019 20:12, Gary Adams wrote: >> While running some bulk testing on jdk/sun/tools I've >> come across some errors reported from the termination sequence >> for LingeredApp debuggee process. >> >> The main process creates a locking file, which the LingeredApp >> sits in a loop updating the file modification date. When the main >> test completes it stops the LingeredApp by removing the file. >> >> The clean exit results when LingeredApp gets a NoSuchFileException. >> I see a number of bugs filed that are getting a raw IOException >> on the LingeredApp termination. >> >> I'm going to attempt to get more specific information about the >> IOException. >> >> diff --git a/test/lib/jdk/test/lib/apps/LingeredApp.java >> b/test/lib/jdk/test/lib/apps/LingeredApp.java >> --- a/test/lib/jdk/test/lib/apps/LingeredApp.java >> +++ b/test/lib/jdk/test/lib/apps/LingeredApp.java >> @@ -504,6 +504,9 @@ >> } catch (NoSuchFileException ex) { >> // Lock deleted while we are setting last modified time. >> // Ignore error and lets the app exits >> + } catch (IOException ioe) { >> + ioe.printStackTrace(); >> + System.exit(3); >> } catch (Exception ex) { >> System.err.println("LingeredApp ERROR: " + ex); >> // Leave exit_code = 1 to Java launcher >> >> Since the error is being detected as the test is terminating, >> I think it would be possible to simply replace the NoSuchFileException, >> and consider an IOException as the trigger for the clean exit sequence. >> >> Anyone have experience with this corner of the swamp? >> From zgu at redhat.com Mon Apr 1 13:26:21 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 1 Apr 2019 09:26:21 -0400 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: References: Message-ID: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Hi, May I get review from serviceability? as it has minor changes in shared code (CollectedHeap.java and ObjectHeap.java) Thanks, -Zhengyu On 3/14/19 11:37 AM, Zhengyu Gu wrote: > Please review this patch that provides best-effort implementation of > live regions iteration for Shenandoah GC. > > There are minor changes in shared code, to adjust oop offset from base > of allocation cell. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html > > > Test: > ? hotspot_gc_shenandoah > ? hotspot_serviceability > ? vmTestbase/nsk/jdb > ? manual test: jhsdb hsdb > ? on Linux x64 > > ? Passed submit test. > > > Thanks, > > -Zhengyu From chris.hegarty at oracle.com Mon Apr 1 13:40:33 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 1 Apr 2019 14:40:33 +0100 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: On 01/04/2019 10:51, Daniel Fuchs wrote: > Hi Arthur, > > Not directly related to Alex's original question but... > > On 30/03/2019 00:03, Arthur Eubanks wrote: >> We have some ipv6 patches as well in this area as well (as well as >> other patches to support ipv6 only environments) that we're trying to >> upstream. I don't understand the code myself, but it might be useful >> to take a look: >> http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html > > SocketTransportService.java: > > On my machine at least, InetAddress.getByName("localhost") and > InetAddress.getLocalHost() are quite different: > > > InetAddress.getByName("localhost") will return the loopback (127.0.0.1) > InetAddress.getLocalHost() returns the local hostname (dhcp-XXX-XXX...) > > If I'm not mistaken your changes in HostPort would transform something > that previously returned the loopback (no host specified) with something > that returns the local host name ("*" specified). > > > So I'm not sure these changes are quite right. > Maybe Alex will be able to confirm. We need to consult the documentation for the command-line tools that exercise this code, or the higher-level API spec for the expected behavior of `*`, port-only specified, etc. -Chris. From alexey.menkov at oracle.com Mon Apr 1 17:36:25 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Apr 2019 10:36:25 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: Hi Daniel, Chris, Unfortunately docs are out-dated (I plan to update it in JDK13). In JDK9 https://bugs.openjdk.java.net/browse/JDK-8041435 changed the behavior - empty address (i.e. only port is specified) means "local connections only", "*" means "all available connections". Then in JDK10 new "allow" option was introduced: https://bugs.openjdk.java.net/browse/JDK-8061228 (it allows to specify list of addresses/subnets to accept connections from). --alex On 04/01/2019 06:40, Chris Hegarty wrote: > > On 01/04/2019 10:51, Daniel Fuchs wrote: >> Hi Arthur, >> >> Not directly related to Alex's original question but... >> >> On 30/03/2019 00:03, Arthur Eubanks wrote: >>> We have some ipv6 patches as well in this area as well (as well as >>> other patches to support ipv6 only environments) that we're trying to >>> upstream. I don't understand the code myself, but it might be useful >>> to take a look: >>> http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html >> >> SocketTransportService.java: >> >> On my machine at least, InetAddress.getByName("localhost") and >> InetAddress.getLocalHost() are quite different: >> >> >> InetAddress.getByName("localhost") will return the loopback (127.0.0.1) >> InetAddress.getLocalHost() returns the local hostname (dhcp-XXX-XXX...) >> >> If I'm not mistaken your changes in HostPort would transform something >> that previously returned the loopback (no host specified) with something >> that returns the local host name ("*" specified). >> >> >> So I'm not sure these changes are quite right. >> Maybe Alex will be able to confirm. > > We need to consult the documentation for the command-line tools that > exercise this code, or the higher-level API spec for the expected > behavior of `*`, port-only specified, etc. > > -Chris. From alexey.menkov at oracle.com Mon Apr 1 18:21:41 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Apr 2019 11:21:41 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> Hi Chris, On 04/01/2019 04:50, Chris Hegarty wrote: > Alex, > > On 29/03/2019 22:07, Alex Menkov wrote: >> (added net-dev as suggested by Alan) >> >> Net gurus, please assist in reviewing socket-related code. >> >> New webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ > > Specifically on SocketTransportService.java. What Arthur has > proposed is better ( changing to lastIndexOf alone is not > sufficient ). Or is your assumption that the IPv6 literal is > not enclosed in square brackets? I didn't know about enclosing IPv6 in square brackets, but looks like that's standard way to alleviate conflict between IPv6 address and colon as port separator. Will update the fix to handle them in both JDI connectors (SocketTransportService.java) and debugger agent (socketTransport.c) > > If keeping Arthur's `static class HostPort` please make the > fields final. > > >> Would it make sense to support the preference properties? > >>??? java.net.preferIPv4Stack > >>??? java.net.preferIPv6Addresses > > I'm not sure about this, especially given the property name > prefixes. I need to think a little more on it. In the initial version of the fix I didn't check the properties. The rationale here is backward compatibility - is address is empty, old debuggers tries to connect to IPv4 address only. But handling this properties we will better handle clients with properties set (as jdb or any other debugger which uses JDI connectors are affected by the properties). BTW fix provided by Arthur implements listening on localhost differently - it creates several sockets and binds them to both IPv4 and IPv6 addresses. But the problem here (and that's the reason I decide to not implement it this way) - how to handle the case when we successfully bind on one address (for example IPv4), but fail to bind on other (for example the port is busy for IPv6 stack). Arthur's version just fail in the case (i.e. the whole Java process terminates) and I don't think this is good behavior. > > There is quite a bit of new native code, is it possible to > rewrite any of this in Java, e.g. reading of the system > properties ( if that is to remain )? socketTransport.c is a debugger agent which is completely native. --alex > > -Chris. From alexey.menkov at oracle.com Mon Apr 1 18:27:04 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Apr 2019 11:27:04 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <919bbc04-d908-9198-0ec6-2ea04cad0fbc@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <919bbc04-d908-9198-0ec6-2ea04cad0fbc@oracle.com> Message-ID: <8318116e-7e45-d6a0-25ce-03bad40c5c27@oracle.com> On 04/01/2019 05:02, Chris Hegarty wrote: > > > On 01/04/2019 12:50, Chris Hegarty wrote: >> ... >> Specifically on SocketTransportService.java. What Arthur has >> proposed is better ( changing to lastIndexOf alone is not >> sufficient ). Or is your assumption that the IPv6 literal is >> not enclosed in square brackets? > > More specifically, what syntax are you proposing to pass IPv6 > addresses from the command line? > For JDI connectors (SocketTransportService.java) there are 2 separate connector arguments: "localAddress" and "port". For JDWP agent (socketTransport.c) arguments are provided as a single command line argument: java -agentlib:jdwp=transport=dt_socket,server=y,address=
: MyApp --alex > -Chris From alexey.menkov at oracle.com Mon Apr 1 21:13:39 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Apr 2019 14:13:39 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> Message-ID: <56dc7f42-a316-f660-4a88-3a2f799f4447@oracle.com> Hi Daniel, As far as I see you are right. Attach to address with empty hostname will try to connect to "external" address instead of loopback. --alex On 04/01/2019 02:51, Daniel Fuchs wrote: > Hi Arthur, > > Not directly related to Alex's original question but... > > On 30/03/2019 00:03, Arthur Eubanks wrote: >> We have some ipv6 patches as well in this area as well (as well as >> other patches to support ipv6 only environments) that we're trying to >> upstream. I don't understand the code myself, but it might be useful >> to take a look: >> http://cr.openjdk.java.net/~aeubanks/jdwpipv6/webrev.00/index.html > > SocketTransportService.java: > > On my machine at least, InetAddress.getByName("localhost") and > InetAddress.getLocalHost() are quite different: > > > InetAddress.getByName("localhost") will return the loopback (127.0.0.1) > InetAddress.getLocalHost() returns the local hostname (dhcp-XXX-XXX...) > > If I'm not mistaken your changes in HostPort would transform something > that previously returned the loopback (no host specified) with something > that returns the local host name ("*" specified). > > > So I'm not sure these changes are quite right. > Maybe Alex will be able to confirm. > > best regards, > > -- daniel From egor.ushakov at jetbrains.com Tue Apr 2 09:42:54 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Tue, 2 Apr 2019 12:42:54 +0300 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] Message-ID: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> Please review the fix this test started to fail after the fix of https://bugs.openjdk.java.net/browse/JDK-8146986 previously any call to ClassLoaderReference.visibleClasses as a side effect cached the results in VirtualMachineImpl.typesBySignature and made them available to any VirtualMachine.classesByName call. This is somewhat not consistent for unprepared classes, I reported that, check Bug 26148990 : JDI - VirtualMachine.allClasses does not return loaded but uninitialized class, but it seems that it allowed the ArrayTypeImpl.componentType to work even if the type was not prepared, check how ArrayTypeImpl#findComponentType uses vm.classesByName. It seems that ArrayTypeImpl#findComponentType should simply call findType for component signature. Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method works, not sure why it was dropped... bugid https://bugs.openjdk.java.net/browse/JDK-8221503 cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ Thanks! -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Tue Apr 2 11:48:22 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Apr 2019 13:48:22 +0200 Subject: [PING] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> Message-ID: <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Could I get a second review, please? Thanks, Severin On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > Sorry for the delay. The update looks good. > > Bob. > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > by adding an additional argument? > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > Thanks, > > Severin > > From gary.adams at oracle.com Tue Apr 2 11:50:33 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 02 Apr 2019 07:50:33 -0400 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 Message-ID: <5CA34C89.6040300@oracle.com> This proposed change allows a wider range of IOExceptions to be observed when a LingeredApp is being shutdown. It may not be just a NoSuchFileException. Botton line - if the lock file doesn't exist at the time the IOException is observed then the main application is terminating the test sequence and LingeredApp should end normally. Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 From chris.plummer at oracle.com Tue Apr 2 17:58:07 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Apr 2019 10:58:07 -0700 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <5CA34C89.6040300@oracle.com> References: <5CA34C89.6040300@oracle.com> Message-ID: <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> Hi Gary, I see various System.exit() calls with varying exit status. Is there some place that documents them? What is 4? Any reason not to print the exception before doing the System.exit(4)? thanks, Chris On 4/2/19 4:50 AM, Gary Adams wrote: > This proposed change allows a wider range of IOExceptions to be observed > when a LingeredApp is being shutdown. It may not be just a > NoSuchFileException. > Botton line - if the lock file doesn't exist at the time the IOException > is observed then the main application is terminating the test sequence > and LingeredApp should end normally. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 From gary.adams at oracle.com Tue Apr 2 18:11:05 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 02 Apr 2019 14:11:05 -0400 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> References: <5CA34C89.6040300@oracle.com> <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> Message-ID: <5CA3A5B9.2090609@oracle.com> The test exits with 3 for the general Exception. I added 4 just to distinguish the return. I see 7 used earlier when the lockfile is not initialized. I could add a message, if you think it is useful. The exit code is printed in stopApp(). line 377. On 4/2/19, 1:58 PM, Chris Plummer wrote: > Hi Gary, > > I see various System.exit() calls with varying exit status. Is there > some place that documents them? What is 4? > > Any reason not to print the exception before doing the System.exit(4)? > > thanks, > > Chris > > On 4/2/19 4:50 AM, Gary Adams wrote: >> This proposed change allows a wider range of IOExceptions to be observed >> when a LingeredApp is being shutdown. It may not be just a >> NoSuchFileException. >> Botton line - if the lock file doesn't exist at the time the IOException >> is observed then the main application is terminating the test sequence >> and LingeredApp should end normally. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 > > > From chris.plummer at oracle.com Tue Apr 2 18:16:09 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Apr 2019 11:16:09 -0700 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> References: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Message-ID: Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor nit. Please fix the indent of line 258 in ObjectHeap.java: ?257???????? while (handle.lessThan(top)) { ?258???????? Oop obj = null; ?259?????????? // Raw pointer walk ?260?????????? handle = handle.addOffsetToAsOopHandle(heap.oopOffset()); thanks, Chris On 4/1/19 6:26 AM, Zhengyu Gu wrote: > Hi, > > May I get review from serviceability? as it has minor changes in > shared code (CollectedHeap.java and ObjectHeap.java) > > > Thanks, > > -Zhengyu > > > On 3/14/19 11:37 AM, Zhengyu Gu wrote: >> Please review this patch that provides best-effort implementation of >> live regions iteration for Shenandoah GC. >> >> There are minor changes in shared code, to adjust oop offset from >> base of allocation cell. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html >> >> >> Test: >> ?? hotspot_gc_shenandoah >> ?? hotspot_serviceability >> ?? vmTestbase/nsk/jdb >> ?? manual test: jhsdb hsdb >> ?? on Linux x64 >> >> ?? Passed submit test. >> >> >> Thanks, >> >> -Zhengyu From zgu at redhat.com Tue Apr 2 18:19:15 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 2 Apr 2019 14:19:15 -0400 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: References: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Message-ID: Thanks, Chris. On 4/2/19 2:16 PM, Chris Plummer wrote: > Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor > nit. Please fix the indent of line 258 in ObjectHeap.java: > > ?257???????? while (handle.lessThan(top)) { > ?258???????? Oop obj = null; > ?259?????????? // Raw pointer walk > ?260?????????? handle = handle.addOffsetToAsOopHandle(heap.oopOffset()); I will fix it before push. -Zhengyu > > thanks, > > Chris > > On 4/1/19 6:26 AM, Zhengyu Gu wrote: >> Hi, >> >> May I get review from serviceability? as it has minor changes in >> shared code (CollectedHeap.java and ObjectHeap.java) >> >> >> Thanks, >> >> -Zhengyu >> >> >> On 3/14/19 11:37 AM, Zhengyu Gu wrote: >>> Please review this patch that provides best-effort implementation of >>> live regions iteration for Shenandoah GC. >>> >>> There are minor changes in shared code, to adjust oop offset from >>> base of allocation cell. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html >>> >>> >>> Test: >>> ?? hotspot_gc_shenandoah >>> ?? hotspot_serviceability >>> ?? vmTestbase/nsk/jdb >>> ?? manual test: jhsdb hsdb >>> ?? on Linux x64 >>> >>> ?? Passed submit test. >>> >>> >>> Thanks, >>> >>> -Zhengyu > > > From chris.plummer at oracle.com Tue Apr 2 18:18:36 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Apr 2019 11:18:36 -0700 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <5CA3A5B9.2090609@oracle.com> References: <5CA34C89.6040300@oracle.com> <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> <5CA3A5B9.2090609@oracle.com> Message-ID: <2eedd2f9-871d-475b-e0ff-d1b79a490dc6@oracle.com> On 4/2/19 11:11 AM, Gary Adams wrote: > The test exits with 3 for the general Exception. > I added 4 just to distinguish the return. > I see 7 used earlier when the lockfile is not initialized. > > I could add a message, if you think it is useful. Yes, I think it would be. > > The exit code is printed in stopApp(). line 377. Ok. I was just wondering if specific error codes were being checked for. It looks like that's not the case. thanks, Chris > > On 4/2/19, 1:58 PM, Chris Plummer wrote: >> Hi Gary, >> >> I see various System.exit() calls with varying exit status. Is there >> some place that documents them? What is 4? >> >> Any reason not to print the exception before doing the System.exit(4)? >> >> thanks, >> >> Chris >> >> On 4/2/19 4:50 AM, Gary Adams wrote: >>> This proposed change allows a wider range of IOExceptions to be >>> observed >>> when a LingeredApp is being shutdown. It may not be just a >>> NoSuchFileException. >>> Botton line - if the lock file doesn't exist at the time the >>> IOException >>> is observed then the main application is terminating the test sequence >>> and LingeredApp should end normally. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 >> >> >> > From alexey.menkov at oracle.com Tue Apr 2 23:14:31 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 2 Apr 2019 16:14:31 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/ - added support for addresses enclosed in square brackets; - updated SocketTransportService.java to handle empty hostname the same way as JDWP agent (listen/attach to loopback address); Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). --alex On 04/01/2019 11:21, Alex Menkov wrote: > Hi Chris, > > On 04/01/2019 04:50, Chris Hegarty wrote: >> Alex, >> >> On 29/03/2019 22:07, Alex Menkov wrote: >>> (added net-dev as suggested by Alan) >>> >>> Net gurus, please assist in reviewing socket-related code. >>> >>> New webrev: >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >> >> Specifically on SocketTransportService.java. What Arthur has >> proposed is better ( changing to lastIndexOf alone is not >> sufficient ). Or is your assumption that the IPv6 literal is >> not enclosed in square brackets? > > I didn't know about enclosing IPv6 in square brackets, but looks like > that's standard way to alleviate conflict between IPv6 address and colon > as port separator. > Will update the fix to handle them in both JDI connectors > (SocketTransportService.java) and debugger agent (socketTransport.c) > >> >> If keeping Arthur's `static class HostPort` please make the >> fields final. >> >> ?>> Would it make sense to support the preference properties? >> ?>>??? java.net.preferIPv4Stack >> ?>>??? java.net.preferIPv6Addresses >> >> I'm not sure about this, especially given the property name >> prefixes. I need to think a little more on it. > > In the initial version of the fix I didn't check the properties. > The rationale here is backward compatibility - is address is empty, old > debuggers tries to connect to IPv4 address only. > But handling this properties we will better handle clients with > properties set (as jdb or any other debugger which uses JDI connectors > are affected by the properties). > > BTW fix provided by Arthur implements listening on localhost differently > - it creates several sockets and binds them to both IPv4 and IPv6 > addresses. But the problem here (and that's the reason I decide to not > implement it this way) - how to handle the case when we successfully > bind on one address (for example IPv4), but fail to bind on other (for > example the port is busy for IPv6 stack). Arthur's version just fail in > the case (i.e. the whole Java process terminates) and I don't think this > is good behavior. > > >> >> There is quite a bit of new native code, is it possible to >> rewrite any of this in Java, e.g. reading of the system >> properties ( if that is to remain )? > > socketTransport.c is a debugger agent which is completely native. > > --alex > >> >> -Chris. From daniil.x.titov at oracle.com Wed Apr 3 19:02:01 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 03 Apr 2019 12:02:01 -0700 Subject: RFR: 8221730: jcmd process name matching broken Message-ID: Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. Reference: [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil From daniil.x.titov at oracle.com Wed Apr 3 20:22:16 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 03 Apr 2019 13:22:16 -0700 Subject: RFR: 8221730: jcmd process name matching broken Message-ID: Resending the RFR for 8221730, since the formatting in the original email wad corrupted. Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. On other platforms the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes JDK-8205654 , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the main class argument against the main class regardless what options were used to launch the application. This created discrepancies between old an! d new behavior on Linux platform as well as between behavior on Linux and other platforms. The fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 Thanks! --Daniil From daniil.x.titov at oracle.com Wed Apr 3 20:37:41 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 03 Apr 2019 13:37:41 -0700 Subject: RFR: 8221730: jcmd process name matching broken Message-ID: <182901E9-4DA0-4454-97FB-10978581598A@oracle.com> Resending RFR 8221730 again as it seems as there is a limit to the line length after which the mailer breaks the string and adds '!'. I apologize for confusion it created. Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. The fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. Reference: [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil From jcbeyler at google.com Wed Apr 3 20:41:12 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 3 Apr 2019 13:41:12 -0700 Subject: RFR: 8221730: jcmd process name matching broken In-Reply-To: References: Message-ID: Hi Daniil, Looks good to me. Two commas missing in the comments it seems: + * was started with -m or --module option the method returns -> + * was started with -m or --module option, the method returns and + // To be consistent with the behavior on other platforms, if -jar, -m or --module -> + // To be consistent with the behavior on other platforms, if -jar, -m, or --module Evidently no need to send anything for me (and you can ignore the fixes too :-)), Jc On Wed, Apr 3, 2019 at 1:25 PM Daniil Titov wrote: > Resending the RFR for 8221730, since the formatting in the original email > wad corrupted. > > Please review the change that makes jcmd process name matching on Linux > platform consistent with pre-existing behavior. On other platforms the > jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. > MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from > sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part > before the first space as a main class when matching the process name. > However, if the application is started with -jar option this part contains > the path to the jar file. If -m or --module option is used this part > contains the module name and the main class (if the main class was > specified in the command line) in the format /. > After changes JDK-8205654 , on Linux platform the proc filesystem is used > to find a Java process, however, it always matches the main class argument > against the main class regardless what options were used to launch the > application. This created discrepancies between old an! > d new behavior on Linux platform as well as between behavior on Linux and > other platforms. The fix changes sun.tool.ProcessHelper (that was > introduced in [3]) to correct these discrepancies. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks! > --Daniil > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Apr 3 20:57:53 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 3 Apr 2019 13:57:53 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> Message-ID: Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? wrote: > Dear All? > Here I updated the latest changeset which did the following refine: > * fixed the compatibility issues so that old version of jmap can > work normally with latest changeset. > * revised the code for parsing the jmap histo arguments. > * revised the logic for incremental dumping of jmap histo. > The main change of this webrev is making all arguments passed to > virtual machine as one line. So there is no need to care about the max > argument count limitation. And hence resolved the compatibility issues as > discussed in > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html > > May I ask your help to review? > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ > > > BRs, > Lin > > ? 2019?2?26????10:50??? ??? > > Dear All, > I have revised the webrev at > http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. > May I ask your help for reviewing? Thanks > > > BRs, > Lin > > -----Original Message----- > From: ?? > Sent: Friday, January 25, 2019 9:01 AM > To: Hohensee, Paul ; serviceability- > dev at openjdk.java.net > Subject: Re: [RFR]8215623: Add incremental dump for jmap histo > > Dear All, > May I get more review about this webrev? > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 > > > Thanks! > Lin > ________________________________________ > From: ?? > Sent: Wednesday, January 9, 2019 9:46:55 AM > To: Hohensee, Paul; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo > > Hi Paul and All, > Thanks a lot for your review and comments, I have updated the webrev to > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 > Would you like to help review it. Thanks. > > BRs > Lin > > From: ?? > Sent: Monday, January 7, 2019 7:14 PM > To: Hohensee, Paul ; serviceability- > dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo > > And another way is to add a argument ?IncrementalFile=?,which > specifies the location for saving the intermediate data file. And if it is > not > specified, incremental data will dump to ?out?. > > What do you think? > > Thanks, > Lin > From: ?? > Sent: Monday, January 7, 2019 7:02 PM > To: Hohensee, Paul > >; serviceability- > dev at openjdk.java.net > Subject: ??: [RFR]8215623: Add incremental dump for jmap histo > > > Dear Paul, > > Thanks for your review, I agree your suggestion to make incremental > general. and > > I think the incremental file is better to be different with the > file or the > "out", because > > in future the parallel histo will have each thread individually dump their > data, > and I want > > it to be lock-free, so each thread need to dump to their own file. The > final > data > > will be sum up and dump to the file that "filename=" specified. > Moreover, the incremental > > file contains intermediate data, if it is dumped to "", it more or > less > "pollute" the final file (final file that contains lots intermediate data). > > so the logic is that incremental data will be dumped to a file named > "Histo_Dump_Temp.dump", > > if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be > generated under the same folder, > > if "filename" not specified, it will dump to current dir. And if > "chunkcount" is 0 > or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. > > ________________________________ > ???: Hohensee, Paul > > > ????: 2019?1?1? 4:56 > ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> > ??: Re: [RFR]8215623: Add incremental dump for jmap histo > > > As for 8215622, update the copyright dates to 2019 please, since this won?t > get pushed until then. > > > > You might generalize the implementation so that all inspections are done > incrementally, and parameterize RecordInstanceClosure with the incremental > threshold. ?incremental? could become ?chunkcount=?, where > defaults to infinity (max value of size_t). > > > > I?d not use a default file name when ?chunkcount? is specified, I?d just > write to > whatever the output stream is. ?chunkcount? is then independent of ?file?. > > > > I?d add another histo argument for the maximum file size, call it > ?maxfilesize?, > and parameterize RecordInstanceClosure with it. Default would be infinity > (max value of size_t). > > > > If you want to make it easy to use your 8k and 5mb chunkcount and > maxfilesize combination, you could redefine your original ?incremental? > argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. > > > > INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become > DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and > should be defined as ?const int? within RecordInstanceClosure. > > > > Thanks, > > > > Paul > > > > From: serviceability-dev bounces at openjdk.java.net bounces at openjdk.java.net>> on behalf of ?? > > > Date: Thursday, December 20, 2018 at 11:13 PM > To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" dev at openjdk.java.net> > Subject: [RFR]8215623: Add incremental dump for jmap histo > > > > Hi All, > > May I ask your help to review this patch for enhance jmap ?histo. > > It adds the ?incremental? arguments that allow jmap ?histo to incrementally > save the intermediate data into a temp file. > > The intermediate data is dumped incrementally and write to a rolling file, > which limit the size of the temp file to be small. > > This is useful for user to get intermediate results when jmap/jvm process > is > killed accidentally. Especially when the heap is large. > > > > This patch is also part of the enhancement described in > https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 > > > > Thanks. > > > > BRs, > > Lin > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Apr 4 00:23:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Apr 2019 10:23:28 +1000 Subject: RFR: 8221730: jcmd process name matching broken In-Reply-To: References: Message-ID: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Hi Daniil, This seems reasonable, but can we add a suitable regression test please to verify behaviour before JDK-8205654 and with this fix. Thanks, David On 4/04/2019 5:02 am, Daniil Titov wrote: > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > Reference: > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > Thanks! > --Daniil > > From gary.adams at oracle.com Thu Apr 4 12:02:23 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Apr 2019 08:02:23 -0400 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <2eedd2f9-871d-475b-e0ff-d1b79a490dc6@oracle.com> References: <5CA34C89.6040300@oracle.com> <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> <5CA3A5B9.2090609@oracle.com> <2eedd2f9-871d-475b-e0ff-d1b79a490dc6@oracle.com> Message-ID: <5CA5F24F.5080301@oracle.com> I need a second reviewer for this minor update. On 4/2/19, 2:18 PM, Chris Plummer wrote: > On 4/2/19 11:11 AM, Gary Adams wrote: >> The test exits with 3 for the general Exception. >> I added 4 just to distinguish the return. >> I see 7 used earlier when the lockfile is not initialized. >> >> I could add a message, if you think it is useful. > Yes, I think it would be. >> >> The exit code is printed in stopApp(). line 377. > Ok. I was just wondering if specific error codes were being checked > for. It looks like that's not the case. > > thanks, > > Chris >> >> On 4/2/19, 1:58 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> I see various System.exit() calls with varying exit status. Is there >>> some place that documents them? What is 4? >>> >>> Any reason not to print the exception before doing the System.exit(4)? >>> >>> thanks, >>> >>> Chris >>> >>> On 4/2/19 4:50 AM, Gary Adams wrote: >>>> This proposed change allows a wider range of IOExceptions to be >>>> observed >>>> when a LingeredApp is being shutdown. It may not be just a >>>> NoSuchFileException. >>>> Botton line - if the lock file doesn't exist at the time the >>>> IOException >>>> is observed then the main application is terminating the test sequence >>>> and LingeredApp should end normally. >>>> >>>> Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 >>> >>> >>> >> > > From jcbeyler at google.com Thu Apr 4 14:13:53 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 4 Apr 2019 07:13:53 -0700 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <5CA5F24F.5080301@oracle.com> References: <5CA34C89.6040300@oracle.com> <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> <5CA3A5B9.2090609@oracle.com> <2eedd2f9-871d-475b-e0ff-d1b79a490dc6@oracle.com> <5CA5F24F.5080301@oracle.com> Message-ID: Hi Gary, Looks good to me. I agree that an error message would be beneficial too :) Thanks! Jc On Thu, Apr 4, 2019 at 5:04 AM Gary Adams wrote: > I need a second reviewer for this minor update. > > On 4/2/19, 2:18 PM, Chris Plummer wrote: > > On 4/2/19 11:11 AM, Gary Adams wrote: > >> The test exits with 3 for the general Exception. > >> I added 4 just to distinguish the return. > >> I see 7 used earlier when the lockfile is not initialized. > >> > >> I could add a message, if you think it is useful. > > Yes, I think it would be. > >> > >> The exit code is printed in stopApp(). line 377. > > Ok. I was just wondering if specific error codes were being checked > > for. It looks like that's not the case. > > > > thanks, > > > > Chris > >> > >> On 4/2/19, 1:58 PM, Chris Plummer wrote: > >>> Hi Gary, > >>> > >>> I see various System.exit() calls with varying exit status. Is there > >>> some place that documents them? What is 4? > >>> > >>> Any reason not to print the exception before doing the System.exit(4)? > >>> > >>> thanks, > >>> > >>> Chris > >>> > >>> On 4/2/19 4:50 AM, Gary Adams wrote: > >>>> This proposed change allows a wider range of IOExceptions to be > >>>> observed > >>>> when a LingeredApp is being shutdown. It may not be just a > >>>> NoSuchFileException. > >>>> Botton line - if the lock file doesn't exist at the time the > >>>> IOException > >>>> is observed then the main application is terminating the test sequence > >>>> and LingeredApp should end normally. > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ > >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 > >>> > >>> > >>> > >> > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Apr 4 18:40:31 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Apr 2019 14:40:31 -0400 Subject: RFR (T) 8221992: Fix old method replacement in ResolvedMethodTable Message-ID: Summary: Use method get_new_method() which is used in other call sites. See bug for more details.? Ran hs-tier1-3 and redefinition tests locally, including the one added for this code: test/jdk/java/lang/instrument/RedefineAddDeleteMethod/MethodHandleDeletedMethod.java open webrev at http://cr.openjdk.java.net/~coleenp/2019/8221992.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8221992 Thanks, Coleen From serguei.spitsyn at oracle.com Thu Apr 4 21:04:03 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Apr 2019 14:04:03 -0700 Subject: RFR (T) 8221992: Fix old method replacement in ResolvedMethodTable In-Reply-To: References: Message-ID: Hi Coleen, It looks good to me. Thanks, Serguei On 4/4/19 11:40, coleen.phillimore at oracle.com wrote: > Summary: Use method get_new_method() which is used in other call sites. > > See bug for more details.? Ran hs-tier1-3 and redefinition tests > locally, including the one added for this code: > test/jdk/java/lang/instrument/RedefineAddDeleteMethod/MethodHandleDeletedMethod.java > > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8221992.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8221992 > > Thanks, > Coleen > > From coleen.phillimore at oracle.com Thu Apr 4 21:34:32 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 4 Apr 2019 17:34:32 -0400 Subject: RFR (T) 8221992: Fix old method replacement in ResolvedMethodTable In-Reply-To: References: Message-ID: <7a4ad12c-3bc2-36c5-fe47-4585aa7cd40d@oracle.com> Thank you Serguei! Coleen On 4/4/19 5:04 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > It looks good to me. > > Thanks, > Serguei > > > On 4/4/19 11:40, coleen.phillimore at oracle.com wrote: >> Summary: Use method get_new_method() which is used in other call sites. >> >> See bug for more details.? Ran hs-tier1-3 and redefinition tests >> locally, including the one added for this code: >> test/jdk/java/lang/instrument/RedefineAddDeleteMethod/MethodHandleDeletedMethod.java >> >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8221992.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8221992 >> >> Thanks, >> Coleen >> >> > From daniil.x.titov at oracle.com Thu Apr 4 22:17:56 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Apr 2019 15:17:56 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Message-ID: Hi David and JC, Thank you for reviewing this change. Please review a new version of the fix that adds additional tests as David suggested. The tests are added to test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and test the cases when Java process is started with -jar or -m (--module) options. Since unnamed packages are not allowed in the modules, file test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java was moved to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 Thanks! --Daniil ?On 4/3/19, 5:23 PM, "David Holmes" wrote: Hi Daniil, This seems reasonable, but can we add a suitable regression test please to verify behaviour before JDK-8205654 and with this fix. Thanks, David On 4/04/2019 5:02 am, Daniil Titov wrote: > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > Reference: > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > Thanks! > --Daniil > > From david.holmes at oracle.com Fri Apr 5 00:45:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 10:45:24 +1000 Subject: 8221730: jcmd process name matching broken In-Reply-To: References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Message-ID: Hi Daniil, On 5/04/2019 8:17 am, Daniil Titov wrote: > Hi David and JC, > > Thank you for reviewing this change. Please review a new version of > the fix that adds additional tests as David suggested. The tests are > added to > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > test the cases when Java process is started with -jar or -m (--module) > options. Looks good - thanks for doing that. > Since unnamed packages are not allowed in the modules, file > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > was moved to > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. Did you use "hg rename" for that? The webrev doesn't show that you did. Thanks, David > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks! > --Daniil > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > Hi Daniil, > > This seems reasonable, but can we add a suitable regression test please > to verify behaviour before JDK-8205654 and with this fix. > > Thanks, > David > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > Reference: > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > Thanks! > > --Daniil > > > > > > > From daniil.x.titov at oracle.com Fri Apr 5 02:01:32 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Apr 2019 19:01:32 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Message-ID: Hi David, I didn't use "hg rename". Now I recreated the patch using "hg rename" for moving test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. I also used the latest version of webrev.ksh (25.17) to re-create a webrev (I uploaded it as webrev.03). However, I still don't see that renaming is somehow reflected in the webrev. Not sure what might be wrong here. The hg version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 Thanks! Best regards, Daniil ?On 4/4/19, 5:45 PM, "David Holmes" wrote: Hi Daniil, On 5/04/2019 8:17 am, Daniil Titov wrote: > Hi David and JC, > > Thank you for reviewing this change. Please review a new version of > the fix that adds additional tests as David suggested. The tests are > added to > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > test the cases when Java process is started with -jar or -m (--module) > options. Looks good - thanks for doing that. > Since unnamed packages are not allowed in the modules, file > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > was moved to > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. Did you use "hg rename" for that? The webrev doesn't show that you did. Thanks, David > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks! > --Daniil > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > Hi Daniil, > > This seems reasonable, but can we add a suitable regression test please > to verify behaviour before JDK-8205654 and with this fix. > > Thanks, > David > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > Reference: > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > Thanks! > > --Daniil > > > > > > > From david.holmes at oracle.com Fri Apr 5 02:15:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 12:15:02 +1000 Subject: 8221730: jcmd process name matching broken In-Reply-To: References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Message-ID: <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> Hi Daniil, On 5/04/2019 12:01 pm, Daniil Titov wrote: > Hi David, > > I didn't use "hg rename". Now I recreated the patch using "hg rename" for moving test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. I also used the latest version of webrev.ksh (25.17) to re-create a webrev (I uploaded it as webrev.03). However, I still don't see that renaming is somehow reflected in the webrev. Not sure what might be wrong here. The hg version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. Strange. Here's an example of where the rename shows up in the webrev: http://cr.openjdk.java.net/~dholmes/8213233/webrev/ Anyway as long as it was done with hg rename that is fine. Thanks, David ---- > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks! > > Best regards, > Daniil > > ?On 4/4/19, 5:45 PM, "David Holmes" wrote: > > Hi Daniil, > > On 5/04/2019 8:17 am, Daniil Titov wrote: > > Hi David and JC, > > > > Thank you for reviewing this change. Please review a new version of > > the fix that adds additional tests as David suggested. The tests are > > added to > > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > > test the cases when Java process is started with -jar or -m (--module) > > options. > > Looks good - thanks for doing that. > > > Since unnamed packages are not allowed in the modules, file > > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > > was moved to > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > > Did you use "hg rename" for that? The webrev doesn't show that you did. > > Thanks, > David > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > Thanks! > > --Daniil > > > > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > This seems reasonable, but can we add a suitable regression test please > > to verify behaviour before JDK-8205654 and with this fix. > > > > Thanks, > > David > > > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > > > > Reference: > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > From daniil.x.titov at oracle.com Fri Apr 5 04:00:32 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Apr 2019 21:00:32 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> Message-ID: <04A95D2C-AE57-430C-AA6B-A9C9A69B63F3@oracle.com> Hi David, I figured out what went wrong. I used webrev.ksh with the list of files to diff. Using "webrev.ksh -m -N" solved the problem. The new webrev is uploaded as webrev.04. Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.04 Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 Thanks, Daniil ?On 4/4/19, 7:15 PM, "David Holmes" wrote: Hi Daniil, On 5/04/2019 12:01 pm, Daniil Titov wrote: > Hi David, > > I didn't use "hg rename". Now I recreated the patch using "hg rename" for moving test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. I also used the latest version of webrev.ksh (25.17) to re-create a webrev (I uploaded it as webrev.03). However, I still don't see that renaming is somehow reflected in the webrev. Not sure what might be wrong here. The hg version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. Strange. Here's an example of where the rename shows up in the webrev: http://cr.openjdk.java.net/~dholmes/8213233/webrev/ Anyway as long as it was done with hg rename that is fine. Thanks, David ---- > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks! > > Best regards, > Daniil > > ?On 4/4/19, 5:45 PM, "David Holmes" wrote: > > Hi Daniil, > > On 5/04/2019 8:17 am, Daniil Titov wrote: > > Hi David and JC, > > > > Thank you for reviewing this change. Please review a new version of > > the fix that adds additional tests as David suggested. The tests are > > added to > > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > > test the cases when Java process is started with -jar or -m (--module) > > options. > > Looks good - thanks for doing that. > > > Since unnamed packages are not allowed in the modules, file > > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > > was moved to > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > > Did you use "hg rename" for that? The webrev doesn't show that you did. > > Thanks, > David > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > Thanks! > > --Daniil > > > > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > This seems reasonable, but can we add a suitable regression test please > > to verify behaviour before JDK-8205654 and with this fix. > > > > Thanks, > > David > > > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > > > > Reference: > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > From david.holmes at oracle.com Fri Apr 5 04:05:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 14:05:19 +1000 Subject: 8221730: jcmd process name matching broken In-Reply-To: <04A95D2C-AE57-430C-AA6B-A9C9A69B63F3@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> <04A95D2C-AE57-430C-AA6B-A9C9A69B63F3@oracle.com> Message-ID: <0e8aad45-f505-e62f-f80e-0d94fb41979a@oracle.com> Great! Thanks, David On 5/04/2019 2:00 pm, Daniil Titov wrote: > Hi David, > > I figured out what went wrong. I used webrev.ksh with the list of files to diff. Using "webrev.ksh -m -N" solved the problem. The new webrev is uploaded as webrev.04. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.04 > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks, > Daniil > > ?On 4/4/19, 7:15 PM, "David Holmes" wrote: > > Hi Daniil, > > On 5/04/2019 12:01 pm, Daniil Titov wrote: > > Hi David, > > > > I didn't use "hg rename". Now I recreated the patch using "hg rename" for moving test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. I also used the latest version of webrev.ksh (25.17) to re-create a webrev (I uploaded it as webrev.03). However, I still don't see that renaming is somehow reflected in the webrev. Not sure what might be wrong here. The hg version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. > > Strange. Here's an example of where the rename shows up in the webrev: > > http://cr.openjdk.java.net/~dholmes/8213233/webrev/ > > Anyway as long as it was done with hg rename that is fine. > > Thanks, > David > ---- > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > Thanks! > > > > Best regards, > > Daniil > > > > ?On 4/4/19, 5:45 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 5/04/2019 8:17 am, Daniil Titov wrote: > > > Hi David and JC, > > > > > > Thank you for reviewing this change. Please review a new version of > > > the fix that adds additional tests as David suggested. The tests are > > > added to > > > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > > > test the cases when Java process is started with -jar or -m (--module) > > > options. > > > > Looks good - thanks for doing that. > > > > > Since unnamed packages are not allowed in the modules, file > > > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > > > was moved to > > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > > > > Did you use "hg rename" for that? The webrev doesn't show that you did. > > > > Thanks, > > David > > > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > > > Thanks! > > > --Daniil > > > > > > > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > > > > > Hi Daniil, > > > > > > This seems reasonable, but can we add a suitable regression test please > > > to verify behaviour before JDK-8205654 and with this fix. > > > > > > Thanks, > > > David > > > > > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > > > > > > > Reference: > > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > From david.holmes at oracle.com Fri Apr 5 04:58:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Apr 2019 14:58:56 +1000 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> Message-ID: <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> Hi Egor, This doesn't seem right to me sorry ... On 2/04/2019 7:42 pm, Egor Ushakov wrote: > Please review the fix > > this test started to fail after the fix of > https://bugs.openjdk.java.net/browse/JDK-8146986 > previously any call to ClassLoaderReference.visibleClasses as a side > effect cached the results in VirtualMachineImpl.typesBySignature > and made them available to any VirtualMachine.classesByName call. > This is somewhat not consistent for unprepared classes, I reported that, > check > Bug 26148990 : JDI - VirtualMachine.allClasses does not return loaded > but uninitialized class, That issue is now a duplicate of this core-libs issue: https://bugs.openjdk.java.net/browse/JDK-8212117 which is in the process of being fixed. Once it is fixed then this workaround would no longer be needed. That said I'm not at all clear how the proposed workaround actually works-around the underlying issue. > but it seems that it allowed the ArrayTypeImpl.componentType to work > even if the type was not prepared, > check how ArrayTypeImpl#findComponentType uses vm.classesByName. > It seems that ArrayTypeImpl#findComponentType should simply call > findType for component signature. > Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method works, > not sure why it was dropped... The package-private: Type type() throws ClassNotLoadedException { return findType(elementSignature()); } seems to have always existed but never been used as the implementation for the public componentType() method (previously elementType()). In fact the two methods appear to have different requirements with regards to what they should be returning. AFAICS: - ArrayTypeImpl.type() returns the actual array type - ArrayTypeImpl.componentType() returns the actual ultimate component type i.e if I understand correctly, given double[][][] then - ArrayTypeImpl.type() == double[][] - ArrayTypeImpl.componentType() == double so implementing them both the same way can't possibly be correct! > bugid https://bugs.openjdk.java.net/browse/JDK-8221503 > cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ > > Thanks! > You'd also need to update the ProblemList so the test gets re-enabled. diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -161,8 +161,6 @@ vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all - vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 generic-all It also appears to me that the exception message of the ClassNotLoadedException will be different now. Have you re-run all the JDI tests? Thanks, David ----- > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > From egor.ushakov at jetbrains.com Fri Apr 5 10:30:21 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Fri, 5 Apr 2019 13:30:21 +0300 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> Message-ID: Hi David, thanks for your comments! I'm not sure how findComponentType worked in the current state: Type findComponentType(String signature) throws ClassNotLoadedException { 93 byte tag = (byte)signature.charAt(0); 94 if (PacketStream.isObjectTag(tag)) { 95 // It's a reference type 96 JNITypeParser parser = new JNITypeParser(componentSignature()); 97 List list = vm.classesByName(parser.typeName()); 98 Iterator iter = list.iterator(); 99 while (iter.hasNext()) { 100 ReferenceType type = iter.next(); 101 ClassLoaderReference cl = type.classLoader(); 102 if ((cl == null)? 103 (classLoader() == null) : 104 (cl.equals(classLoader()))) { 105 return type; 106 } 107 } 108 // Component class has not yet been loaded 109 throw new ClassNotLoadedException(componentTypeName()); 110 } else { 111 // It's a primitive type 112 return vm.primitiveTypeMirror(tag); 113 } 114 } the method receives signature string but uses it only for object checking, then inside it does the search by componentSignature() instead... Most probably the method is always called passing componentSignature() string as a parameter anyway. Regarding the fix: the only thing I'm trying to change here is where the requested type name is looked at - loader.visibleClasses (this is where findType ends up) instead of vm.classesByName. This is how it works in all other implementors of com.sun.tools.jdi.ValueContainer.findType. ArrayTypeImpl.type() is unused, so I'm not sure how it was supposed to be used and where. I've run all jdi tests and see no regression, probably ClassNotLoadedException is never thrown in this case. Removed the test from the ProblemList in the new cr: http://cr.openjdk.java.net/~eushakov/8221503/webrev.01/ On 05-Apr-19 07:58, David Holmes wrote: > Hi Egor, > > This doesn't seem right to me sorry ... > > On 2/04/2019 7:42 pm, Egor Ushakov wrote: >> Please review the fix >> >> this test started to fail after the fix of >> https://bugs.openjdk.java.net/browse/JDK-8146986 >> previously any call to ClassLoaderReference.visibleClasses as a side >> effect cached the results in VirtualMachineImpl.typesBySignature >> and made them available to any VirtualMachine.classesByName call. >> This is somewhat not consistent for unprepared classes, I reported >> that, check >> Bug 26148990 : JDI - VirtualMachine.allClasses does not return loaded >> but uninitialized class, > > That issue is now a duplicate of this core-libs issue: > > https://bugs.openjdk.java.net/browse/JDK-8212117 > > which is in the process of being fixed. Once it is fixed then this > workaround would no longer be needed. > > That said I'm not at all clear how the proposed workaround actually > works-around the underlying issue. > >> but it seems that it allowed the ArrayTypeImpl.componentType to work >> even if the type was not prepared, >> check how ArrayTypeImpl#findComponentType uses vm.classesByName. >> It seems that ArrayTypeImpl#findComponentType should simply call >> findType for component signature. >> Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method >> works, not sure why it was dropped... > > The package-private: > > Type type() throws ClassNotLoadedException { > ??? return findType(elementSignature()); > } > > seems to have always existed but never been used as the implementation > for the public componentType() method (previously elementType()). In > fact the two methods appear to have different requirements with > regards to what they should be returning. AFAICS: > > - ArrayTypeImpl.type() returns the actual array type > - ArrayTypeImpl.componentType() returns the actual ultimate component > type > > i.e if I understand correctly, given double[][][] then > - ArrayTypeImpl.type() == double[][] > - ArrayTypeImpl.componentType() == double > > so implementing them both the same way can't possibly be correct! > >> bugid https://bugs.openjdk.java.net/browse/JDK-8221503 >> cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ >> >> Thanks! >> > > You'd also need to update the ProblemList so the test gets re-enabled. > > diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -161,8 +161,6 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > - > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 > generic-all > > It also appears to me that the exception message of the > ClassNotLoadedException will be different now. Have you re-run all the > JDI tests? > > Thanks, > David > ----- > >> >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop >> -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Fri Apr 5 15:11:16 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 5 Apr 2019 17:11:16 +0200 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms Message-ID: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8221917 Fix: http://cr.openjdk.java.net/~shade/8221917/webrev.01/ The failure is caused by MDO change in 11 that broke SA a little. I am planning to backport it all the way down to 11u. See bug for details. Testing: - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability - jdk-submit (running) Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jcbeyler at google.com Fri Apr 5 16:40:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 5 Apr 2019 09:40:13 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: <0e8aad45-f505-e62f-f80e-0d94fb41979a@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> <04A95D2C-AE57-430C-AA6B-A9C9A69B63F3@oracle.com> <0e8aad45-f505-e62f-f80e-0d94fb41979a@oracle.com> Message-ID: Hi Daniil, Looks good to me too :) Jc On Thu, Apr 4, 2019 at 9:05 PM David Holmes wrote: > Great! > > Thanks, > David > > On 5/04/2019 2:00 pm, Daniil Titov wrote: > > Hi David, > > > > I figured out what went wrong. I used webrev.ksh with the list of > files to diff. Using "webrev.ksh -m -N" solved the problem. The new > webrev is uploaded as webrev.04. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.04 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > Thanks, > > Daniil > > > > ?On 4/4/19, 7:15 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 5/04/2019 12:01 pm, Daniil Titov wrote: > > > Hi David, > > > > > > I didn't use "hg rename". Now I recreated the patch using "hg > rename" for moving > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > I also used the latest version of webrev.ksh (25.17) to re-create a webrev > (I uploaded it as webrev.03). However, I still don't see that renaming is > somehow reflected in the webrev. Not sure what might be wrong here. The hg > version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. > > > > Strange. Here's an example of where the rename shows up in the > webrev: > > > > http://cr.openjdk.java.net/~dholmes/8213233/webrev/ > > > > Anyway as long as it was done with hg rename that is fine. > > > > Thanks, > > David > > ---- > > > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > ?On 4/4/19, 5:45 PM, "David Holmes" > wrote: > > > > > > Hi Daniil, > > > > > > On 5/04/2019 8:17 am, Daniil Titov wrote: > > > > Hi David and JC, > > > > > > > > Thank you for reviewing this change. Please review a new > version of > > > > the fix that adds additional tests as David suggested. The > tests are > > > > added to > > > > > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > > > > test the cases when Java process is started with -jar or > -m (--module) > > > > options. > > > > > > Looks good - thanks for doing that. > > > > > > > Since unnamed packages are not allowed in the modules, file > > > > > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > > > > was moved to > > > > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > > > > > > Did you use "hg rename" for that? The webrev doesn't show > that you did. > > > > > > Thanks, > > > David > > > > > > > > > > > Webrev: > http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > > > > > ?On 4/3/19, 5:23 PM, "David Holmes" < > david.holmes at oracle.com> wrote: > > > > > > > > Hi Daniil, > > > > > > > > This seems reasonable, but can we add a suitable > regression test please > > > > to verify behaviour before JDK-8205654 and with this > fix. > > > > > > > > Thanks, > > > > David > > > > > > > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > > > > Please review the change that makes jcmd process > name matching on Linux platform consistent with pre-existing behavior. > > > > > > > > > > On other platforms (and on Linux platform before > changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see > sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that > is called from sun.tools.common. ProcessArgumentMatcher at line 96) and > treats the part before the first space as a main class when matching the > process name. However, if the application is started with -jar option this > part contains the path to the jar file. If -m or --module option is used > this part contains the module name and the main class (if the main class > was specified in the command line) in the format /. > After changes [3] , on Linux platform the proc filesystem is used to find a > Java process, however, it always matches the process name against the main > class regardless what options were used to launch the application. This > created discrepancies between old and new behavior on Linux platform as > well as between behavior on Linux and other platforms. Th! > > > > > e fix changes sun.tool.ProcessHelper (that was > introduced in [3]) to correct these discrepancies. > > > > > > > > > > > > > > > Reference: > > > > > [1] Webrev: > http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > > > > [2] Bug: > https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > > [3] > https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > > > > > > > > > > Thanks! > > > > > --Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 5 17:31:01 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 5 Apr 2019 10:31:01 -0700 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Message-ID: Hi Aleksey, I looked at the changes to this file that were done in JDK-8204240 (which introduced the issue), and your fix seems correct. Thumbs up! thanks, Chris On 4/5/19 8:11 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221917 > > Fix: > http://cr.openjdk.java.net/~shade/8221917/webrev.01/ > > The failure is caused by MDO change in 11 that broke SA a little. I am planning to backport it all > the way down to 11u. See bug for details. > > Testing: > - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 > - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability > - jdk-submit (running) > > Thanks, > -Aleksey > > From daniil.x.titov at oracle.com Fri Apr 5 17:47:15 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 05 Apr 2019 10:47:15 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> <0c93ee7a-36c8-5e58-69af-56792ef60f9f@oracle.com> <04A95D2C-AE57-430C-AA6B-A9C9A69B63F3@oracle.com> <0e8aad45-f505-e62f-f80e-0d94fb41979a@oracle.com> Message-ID: <05F72D21-0F88-4DD5-8FAF-FB3023FFE6AD@oracle.com> Thank you, JC and David, for reviewing this change! Best regards, -Daniil From: Jean Christophe Beyler Date: Friday, April 5, 2019 at 9:40 AM To: David Holmes Cc: Daniil Titov , OpenJDK Serviceability , Thomas St?fe Subject: Re: 8221730: jcmd process name matching broken Hi Daniil, Looks good to me too :) Jc On Thu, Apr 4, 2019 at 9:05 PM David Holmes wrote: Great! Thanks, David On 5/04/2019 2:00 pm, Daniil Titov wrote: > Hi David, > > I figured out what went wrong. I used webrev.ksh with the list of files to diff. Using "webrev.ksh -m -N" solved the problem. The new webrev is uploaded as webrev.04. > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.04 > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > Thanks, > Daniil > > ?On 4/4/19, 7:15 PM, "David Holmes" wrote: > > Hi Daniil, > > On 5/04/2019 12:01 pm, Daniil Titov wrote: > > Hi David, > > > > I didn't use "hg rename". Now I recreated the patch using "hg rename" for moving test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java to test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. I also used the latest version of webrev.ksh (25.17) to re-create a webrev (I uploaded it as webrev.03). However, I still don't see that renaming is somehow reflected in the webrev. Not sure what might be wrong here. The hg version is 4.5.3, the OS is Ubuntu 18.04.2 LTS. > > Strange. Here's an example of where the rename shows up in the webrev: > > http://cr.openjdk.java.net/~dholmes/8213233/webrev/ > > Anyway as long as it was done with hg rename that is fine. > > Thanks, > David > ---- > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > Thanks! > > > > Best regards, > > Daniil > > > > ?On 4/4/19, 5:45 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 5/04/2019 8:17 am, Daniil Titov wrote: > > > Hi David and JC, > > > > > > Thank you for reviewing this change. Please review a new version of > > > the fix that adds additional tests as David suggested. The tests are > > > added to > > > test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java and > > > test the cases when Java process is started with -jar or -m (--module) > > > options. > > > > Looks good - thanks for doing that. > > > > > Since unnamed packages are not allowed in the modules, file > > > test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java > > > was moved to > > > test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java. > > > > Did you use "hg rename" for that? The webrev doesn't show that you did. > > > > Thanks, > > David > > > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > > > Thanks! > > > --Daniil > > > > > > > > > ?On 4/3/19, 5:23 PM, "David Holmes" wrote: > > > > > > Hi Daniil, > > > > > > This seems reasonable, but can we add a suitable regression test please > > > to verify behaviour before JDK-8205654 and with this fix. > > > > > > Thanks, > > > David > > > > > > On 4/04/2019 5:02 am, Daniil Titov wrote: > > > > Please review the change that makes jcmd process name matching on Linux platform consistent with pre-existing behavior. > > > > > > > > On other platforms (and on Linux platform before changes [3]) the jcmd uses system property "sun.rt.javaCommand" (see sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) that is called from sun.tools.common. ProcessArgumentMatcher at line 96) and treats the part before the first space as a main class when matching the process name. However, if the application is started with -jar option this part contains the path to the jar file. If -m or --module option is used this part contains the module name and the main class (if the main class was specified in the command line) in the format /. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, it always matches the process name against the main class regardless what options were used to launch the application. This created discrepancies between old and new behavior on Linux platform as well as between behavior on Linux and other platforms. Th! > > > > e fix changes sun.tool.ProcessHelper (that was introduced in [3]) to correct these discrepancies. > > > > > > > > > > > > Reference: > > > > [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 > > > > [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 > > > > [3] https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Apr 6 04:18:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 Apr 2019 14:18:31 +1000 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> Message-ID: <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> +1 Please update copyright year. Thanks, David On 6/04/2019 3:31 am, Chris Plummer wrote: > Hi Aleksey, > > I looked at the changes to this file that were done in JDK-8204240 > (which introduced the issue), and your fix seems correct. Thumbs up! > > thanks, > > Chris > > On 4/5/19 8:11 AM, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8221917 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8221917/webrev.01/ >> >> The failure is caused by MDO change in 11 that broke SA a little. I am >> planning to backport it all >> the way down to 11u. See bug for details. >> >> Testing: >> ?? - Linux x86_32 fastdebug: TestPrintMdo, entire serviceability, tier1 >> ?? - Linux x86_64 fastdebug: TestPrintMdo, entire serviceability >> ?? - jdk-submit (running) >> >> Thanks, >> -Aleksey >> >> > From chris.plummer at oracle.com Sat Apr 6 06:18:17 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 5 Apr 2019 23:18:17 -0700 Subject: RFR: 8221730: jcmd process name matching broken In-Reply-To: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> Message-ID: <70395dbc-3f6c-d54c-fede-cf9ff908eb02@oracle.com> [I just realized I had typed this up a day or two ago and never sent it] +1, except there is a typo on the following line: ? 54????? * was started with -m or --module option the method returns thanks, Chris On 4/3/19 5:23 PM, David Holmes wrote: > Hi Daniil, > > This seems reasonable, but can we add a suitable regression test > please to verify behaviour before JDK-8205654 and with this fix. > > Thanks, > David > > On 4/04/2019 5:02 am, Daniil Titov wrote: >> Please review the change that makes jcmd process name matching on >> Linux platform consistent with pre-existing behavior. >> >> On other platforms (and on Linux platform before changes [3]) the >> jcmd uses system property "sun.rt.javaCommand"? (see >> sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) >> that is called from sun.tools.common. ProcessArgumentMatcher at line >> 96) and treats the part before the first space as a main class when >> matching the process name. However, if the application? is started >> with -jar option this part contains the path to the jar file. If? -m >> or --module option is used this part contains the module name and the >> main class (if the main class was specified in the command line) in >> the format /.? After changes [3] , on Linux >> platform the proc filesystem is used to find a Java process, however, >> it always matches the process name against the main class regardless >> what options were used to launch the application. This created >> discrepancies between old and new behavior on Linux platform as well >> as between behavior on Linux and other platforms. Th! >> ? e fix changes sun.tool.ProcessHelper (that was introduced in [3]) >> to correct these discrepancies. >> >> >> Reference: >> [1]? Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 >> [3] https://bugs.openjdk.java.net/browse/JDK-8205654 >> >> >> Thanks! >> --Daniil >> >> From shade at redhat.com Sat Apr 6 09:08:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 6 Apr 2019 11:08:33 +0200 Subject: RFR (XS) 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms In-Reply-To: <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> References: <5285d9b1-cebe-1411-7cd6-42b43e004193@redhat.com> <51234bae-cbdb-e7e0-5486-04d88ad545bb@oracle.com> Message-ID: On 4/6/19 6:18 AM, David Holmes wrote: > Please update copyright year. Thanks. I updated the copyright locally. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From david.holmes at oracle.com Mon Apr 8 01:49:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Apr 2019 11:49:28 +1000 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ I'm really just sponsoring this fix as the problem was diagnozed by Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the contributors and I'm already one Reviewer. There's a missing loadstore barrier between extracting the ParkEvent from an ObjectWaiter node, and setting the node's TState to allow the the entering thread to proceed. It seems our recent update to gcc 8.2 resulted in the compiler reordering those two actions, meaning that the Objectwaiter pointer could now be pointing into a stack location with random contents. That might manifest as a SEGV or we may treat random memory as a pthread_mutex_t and get an EINVAL (or potentially other errors) on pthread_mutex_lock. Testing: mach5 tiers 1-3 (sanity - the added barrier can't break anything) Thanks, David From stefan.karlsson at oracle.com Mon Apr 8 05:07:42 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 8 Apr 2019 07:07:42 +0200 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: References: Message-ID: <25f9d30f-9878-bbdd-5fc2-2d6bebb71775@oracle.com> Looks good! StefanK On 2019-04-08 03:49, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 > webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ > > I'm really just sponsoring this fix as the problem was diagnozed by > Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the > contributors and I'm already one Reviewer. > > There's a missing loadstore barrier between extracting the ParkEvent > from an ObjectWaiter node, and setting the node's TState to allow the > the entering thread to proceed. It seems our recent update to gcc 8.2 > resulted in the compiler reordering those two actions, meaning that > the Objectwaiter pointer could now be pointing into a stack location > with random contents. That might manifest as a SEGV or we may treat > random memory as a pthread_mutex_t and get an EINVAL (or potentially > other errors) on pthread_mutex_lock. > > Testing: mach5 tiers 1-3 (sanity - the added barrier can't break > anything) > > Thanks, > David From david.holmes at oracle.com Mon Apr 8 05:27:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Apr 2019 15:27:16 +1000 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: <25f9d30f-9878-bbdd-5fc2-2d6bebb71775@oracle.com> References: <25f9d30f-9878-bbdd-5fc2-2d6bebb71775@oracle.com> Message-ID: <0835af6d-e4e5-a92c-430e-0ae68fdb851d@oracle.com> On 8/04/2019 3:07 pm, Stefan Karlsson wrote: > Looks good! Thanks - do you want to be co-contributor or a reviewer? :) David > StefanK > > On 2019-04-08 03:49, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 >> webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ >> >> I'm really just sponsoring this fix as the problem was diagnozed by >> Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the >> contributors and I'm already one Reviewer. >> >> There's a missing loadstore barrier between extracting the ParkEvent >> from an ObjectWaiter node, and setting the node's TState to allow the >> the entering thread to proceed. It seems our recent update to gcc 8.2 >> resulted in the compiler reordering those two actions, meaning that >> the Objectwaiter pointer could now be pointing into a stack location >> with random contents. That might manifest as a SEGV or we may treat >> random memory as a pthread_mutex_t and get an EINVAL (or potentially >> other errors) on pthread_mutex_lock. >> >> Testing: mach5 tiers 1-3 (sanity - the added barrier can't break >> anything) >> >> Thanks, >> David > From robbin.ehn at oracle.com Mon Apr 8 07:13:31 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 8 Apr 2019 09:13:31 +0200 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: <0835af6d-e4e5-a92c-430e-0ae68fdb851d@oracle.com> References: <25f9d30f-9878-bbdd-5fc2-2d6bebb71775@oracle.com> <0835af6d-e4e5-a92c-430e-0ae68fdb851d@oracle.com> Message-ID: On 4/8/19 7:27 AM, David Holmes wrote: > On 8/04/2019 3:07 pm, Stefan Karlsson wrote: >> Looks good! +1 Thanks, Robbin (I can be reviewer) > > Thanks - do you want to be co-contributor or a reviewer?? :) > > David > >> StefanK >> >> On 2019-04-08 03:49, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 >>> webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ >>> >>> I'm really just sponsoring this fix as the problem was diagnozed by Robbin >>> Ehn and Stefan Karlsson - thanks guys! :) So they are the contributors and >>> I'm already one Reviewer. >>> >>> There's a missing loadstore barrier between extracting the ParkEvent from an >>> ObjectWaiter node, and setting the node's TState to allow the the entering >>> thread to proceed. It seems our recent update to gcc 8.2 resulted in the >>> compiler reordering those two actions, meaning that the Objectwaiter pointer >>> could now be pointing into a stack location with random contents. That might >>> manifest as a SEGV or we may treat random memory as a pthread_mutex_t and get >>> an EINVAL (or potentially other errors) on pthread_mutex_lock. >>> >>> Testing: mach5 tiers 1-3 (sanity - the added barrier can't break anything) >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Mon Apr 8 07:48:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Apr 2019 17:48:38 +1000 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: References: <25f9d30f-9878-bbdd-5fc2-2d6bebb71775@oracle.com> <0835af6d-e4e5-a92c-430e-0ae68fdb851d@oracle.com> Message-ID: <6189f901-1ffd-6b73-9369-0f8bb1fc3575@oracle.com> Thanks Robbin. I guess between the three of us we have this covered one way or another. :) David On 8/04/2019 5:13 pm, Robbin Ehn wrote: > On 4/8/19 7:27 AM, David Holmes wrote: >> On 8/04/2019 3:07 pm, Stefan Karlsson wrote: >>> Looks good! > > +1 > > Thanks, Robbin (I can be reviewer) > >> >> Thanks - do you want to be co-contributor or a reviewer?? :) >> >> David >> >>> StefanK >>> >>> On 2019-04-08 03:49, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ >>>> >>>> I'm really just sponsoring this fix as the problem was diagnozed by >>>> Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the >>>> contributors and I'm already one Reviewer. >>>> >>>> There's a missing loadstore barrier between extracting the ParkEvent >>>> from an ObjectWaiter node, and setting the node's TState to allow >>>> the the entering thread to proceed. It seems our recent update to >>>> gcc 8.2 resulted in the compiler reordering those two actions, >>>> meaning that the Objectwaiter pointer could now be pointing into a >>>> stack location with random contents. That might manifest as a SEGV >>>> or we may treat random memory as a pthread_mutex_t and get an EINVAL >>>> (or potentially other errors) on pthread_mutex_lock. >>>> >>>> Testing: mach5 tiers 1-3 (sanity - the added barrier can't break >>>> anything) >>>> >>>> Thanks, >>>> David >>> From daniil.x.titov at oracle.com Mon Apr 8 14:04:16 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Apr 2019 07:04:16 -0700 Subject: 8221730: jcmd process name matching broken In-Reply-To: <70395dbc-3f6c-d54c-fede-cf9ff908eb02@oracle.com> References: <404689e9-5bc3-6a08-1cc6-afdafe3c8120@oracle.com> <70395dbc-3f6c-d54c-fede-cf9ff908eb02@oracle.com> Message-ID: <750353AE-E39E-49EA-B3B9-6A2422C06A89@oracle.com> Thank you, Chris, I will fix this typo before pushing the change in the repository. Best regards, Daniil ?On 4/5/19, 11:18 PM, "Chris Plummer" wrote: [I just realized I had typed this up a day or two ago and never sent it] +1, except there is a typo on the following line: 54 * was started with -m or --module option the method returns thanks, Chris On 4/3/19 5:23 PM, David Holmes wrote: > Hi Daniil, > > This seems reasonable, but can we add a suitable regression test > please to verify behaviour before JDK-8205654 and with this fix. > > Thanks, > David > > On 4/04/2019 5:02 am, Daniil Titov wrote: >> Please review the change that makes jcmd process name matching on >> Linux platform consistent with pre-existing behavior. >> >> On other platforms (and on Linux platform before changes [3]) the >> jcmd uses system property "sun.rt.javaCommand" (see >> sun.jvmstat.monitor. MonitoredVmUtil.mainClass(MonitoredVm, boolean) >> that is called from sun.tools.common. ProcessArgumentMatcher at line >> 96) and treats the part before the first space as a main class when >> matching the process name. However, if the application is started >> with -jar option this part contains the path to the jar file. If -m >> or --module option is used this part contains the module name and the >> main class (if the main class was specified in the command line) in >> the format /. After changes [3] , on Linux >> platform the proc filesystem is used to find a Java process, however, >> it always matches the process name against the main class regardless >> what options were used to launch the application. This created >> discrepancies between old and new behavior on Linux platform as well >> as between behavior on Linux and other platforms. Th! >> e fix changes sun.tool.ProcessHelper (that was introduced in [3]) >> to correct these discrepancies. >> >> >> Reference: >> [1] Webrev: http://cr.openjdk.java.net/~dtitov/8221730/webrev.01 >> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8221730 >> [3] https://bugs.openjdk.java.net/browse/JDK-8205654 >> >> >> Thanks! >> --Daniil >> >> From daniel.daugherty at oracle.com Mon Apr 8 14:09:50 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 8 Apr 2019 10:09:50 -0400 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: References: Message-ID: <3b27692a-6fc6-e001-eedf-97b579daf7ef@oracle.com> On 4/7/19 9:49 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 > webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ src/hotspot/share/prims/jvmtiRawMonitor.cpp ??? No comments. Thumbs up! Dan > > I'm really just sponsoring this fix as the problem was diagnozed by > Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the > contributors and I'm already one Reviewer. > > There's a missing loadstore barrier between extracting the ParkEvent > from an ObjectWaiter node, and setting the node's TState to allow the > the entering thread to proceed. It seems our recent update to gcc 8.2 > resulted in the compiler reordering those two actions, meaning that > the Objectwaiter pointer could now be pointing into a stack location > with random contents. That might manifest as a SEGV or we may treat > random memory as a pthread_mutex_t and get an EINVAL (or potentially > other errors) on pthread_mutex_lock. > > Testing: mach5 tiers 1-3 (sanity - the added barrier can't break > anything) > > Thanks, > David From serguei.spitsyn at oracle.com Mon Apr 8 19:28:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Apr 2019 12:28:31 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv Message-ID: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Apr 8 21:35:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 07:35:48 +1000 Subject: RFR (XXXS): 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event In-Reply-To: <3b27692a-6fc6-e001-eedf-97b579daf7ef@oracle.com> References: <3b27692a-6fc6-e001-eedf-97b579daf7ef@oracle.com> Message-ID: <9c044731-e1bf-6a0c-d6c0-2800af383629@oracle.com> Thanks Dan! David On 9/04/2019 12:09 am, Daniel D. Daugherty wrote: > On 4/7/19 9:49 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221584 >> webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/ > > src/hotspot/share/prims/jvmtiRawMonitor.cpp > ??? No comments. > > Thumbs up! > > Dan > >> >> I'm really just sponsoring this fix as the problem was diagnozed by >> Robbin Ehn and Stefan Karlsson - thanks guys! :) So they are the >> contributors and I'm already one Reviewer. >> >> There's a missing loadstore barrier between extracting the ParkEvent >> from an ObjectWaiter node, and setting the node's TState to allow the >> the entering thread to proceed. It seems our recent update to gcc 8.2 >> resulted in the compiler reordering those two actions, meaning that >> the Objectwaiter pointer could now be pointing into a stack location >> with random contents. That might manifest as a SEGV or we may treat >> random memory as a pthread_mutex_t and get an EINVAL (or potentially >> other errors) on pthread_mutex_lock. >> >> Testing: mach5 tiers 1-3 (sanity - the added barrier can't break >> anything) >> >> Thanks, >> David > From david.holmes at oracle.com Tue Apr 9 05:15:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 15:15:50 +1000 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> Message-ID: Hi Egor, I want to re-emphasise that once JDK-8212117 is fixed then this bug should also be fixed. On 5/04/2019 8:30 pm, Egor Ushakov wrote: > Hi David, thanks for your comments! > > I'm not sure how findComponentType worked in the current state: > > Type findComponentType(String signature) throws ClassNotLoadedException { > 93 byte tag = (byte)signature.charAt(0); > 94 if (PacketStream.isObjectTag(tag)) { > 95 // It's a reference type > 96 JNITypeParser parser = new JNITypeParser(componentSignature()); > 97 List list = vm.classesByName(parser.typeName()); > 98 Iterator iter = list.iterator(); > 99 while (iter.hasNext()) { > 100 ReferenceType type = iter.next(); > 101 ClassLoaderReference cl = type.classLoader(); > 102 if ((cl == null)? > 103 (classLoader() == null) : > 104 (cl.equals(classLoader()))) { > 105 return type; > 106 } > 107 } > 108 // Component class has not yet been loaded > 109 throw new ClassNotLoadedException(componentTypeName()); > 110 } else { > 111 // It's a primitive type > 112 return vm.primitiveTypeMirror(tag); > 113 } > 114 } > > > the method receives signature string but uses it only for object > checking, then inside it does the search by componentSignature() instead... > Most probably the method is always called passing componentSignature() > string as a parameter anyway. > > Regarding the fix: > the only thing I'm trying to change here is where the requested type > name is looked at - loader.visibleClasses (this is where findType ends > up) instead of vm.classesByName. > This is how it works in all other implementors of > com.sun.tools.jdi.ValueContainer.findType. Yes but I'm trying to determine why the difference exists - if we already had loader.findType then why go to the bother of writing findComponentType that way instead of just using findType? My concern is that (ignoring the bug with not-initialized classes) the set of classes returned by loader.visibleClasses may be different to that which can be found via vm.classesByName. I'm not convinced we have adequate test coverage in this area. > ArrayTypeImpl.type() is unused, so I'm not sure how it was supposed to > be used and where. Tracking the relationships between classes/interfaces here is quite tricky and it had appeared to me that ArrayTypeImpl.type() could end up getting used. But I've re-scanned the code and that seems not to be the case. For good measure I changed it to always throw an exception and re-ran all the JDI tests (though as I said coverage seems limited) with no problems. If this is truly unused then we should delete it to avoid future confusion - a separate RFE would be fine for that. Thanks, David > I've run all jdi tests and see no regression, probably > ClassNotLoadedException is never thrown in this case. > > Removed the test from the ProblemList in the new cr: > http://cr.openjdk.java.net/~eushakov/8221503/webrev.01/ > > On 05-Apr-19 07:58, David Holmes wrote: >> Hi Egor, >> >> This doesn't seem right to me sorry ... >> >> On 2/04/2019 7:42 pm, Egor Ushakov wrote: >>> Please review the fix >>> >>> this test started to fail after the fix of >>> https://bugs.openjdk.java.net/browse/JDK-8146986 >>> previously any call to ClassLoaderReference.visibleClasses as a side >>> effect cached the results in VirtualMachineImpl.typesBySignature >>> and made them available to any VirtualMachine.classesByName call. >>> This is somewhat not consistent for unprepared classes, I reported >>> that, check >>> Bug 26148990 : JDI - VirtualMachine.allClasses does not return loaded >>> but uninitialized class, >> >> That issue is now a duplicate of this core-libs issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8212117 >> >> which is in the process of being fixed. Once it is fixed then this >> workaround would no longer be needed. >> >> That said I'm not at all clear how the proposed workaround actually >> works-around the underlying issue. >> >>> but it seems that it allowed the ArrayTypeImpl.componentType to work >>> even if the type was not prepared, >>> check how ArrayTypeImpl#findComponentType uses vm.classesByName. >>> It seems that ArrayTypeImpl#findComponentType should simply call >>> findType for component signature. >>> Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method >>> works, not sure why it was dropped... >> >> The package-private: >> >> Type type() throws ClassNotLoadedException { >> ??? return findType(elementSignature()); >> } >> >> seems to have always existed but never been used as the implementation >> for the public componentType() method (previously elementType()). In >> fact the two methods appear to have different requirements with >> regards to what they should be returning. AFAICS: >> >> - ArrayTypeImpl.type() returns the actual array type >> - ArrayTypeImpl.componentType() returns the actual ultimate component >> type >> >> i.e if I understand correctly, given double[][][] then >> - ArrayTypeImpl.type() == double[][] >> - ArrayTypeImpl.componentType() == double >> >> so implementing them both the same way can't possibly be correct! >> >>> bugid https://bugs.openjdk.java.net/browse/JDK-8221503 >>> cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ >>> >>> Thanks! >>> >> >> You'd also need to update the ProblemList so the test gets re-enabled. >> >> diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -161,8 +161,6 @@ >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> >> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >> - >> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 >> generic-all >> >> It also appears to me that the exception message of the >> ClassNotLoadedException will be different now. Have you re-run all the >> JDI tests? >> >> Thanks, >> David >> ----- >> >>> >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop >>> > > -- > Egor Ushakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > From sgehwolf at redhat.com Tue Apr 9 09:33:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Apr 2019 11:33:31 +0200 Subject: [PING?] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Hi, Could I get another reviewer for this, please? Bob Vandette already reviewed it. Thank you! Cheers, Severin On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: > Could I get a second review, please? > > Thanks, > Severin > > On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > > Sorry for the delay. The update looks good. > > > > Bob. > > > > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > > by adding an additional argument? > > > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > > > Thanks, > > > Severin > > > From egor.ushakov at jetbrains.com Tue Apr 9 09:36:17 2019 From: egor.ushakov at jetbrains.com (Egor Ushakov) Date: Tue, 9 Apr 2019 12:36:17 +0300 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> Message-ID: <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> Hi David, you're right! The fix for JDK-8212117 should help here as well. After that fix we may want to revisit ValueContainer.findType implementors, currently they all (except for ArrayTypeImpl) delegates to ReferenceTypeImpl.findType (which ends up in classloader.visibleClasses). Someone should clarify the difference between classLoader.visibleClasses and allClasses filtered by the classLoader instance then. In my opinion fixing JDK-8212117 is risky and requires heavy testing, do you think it may be fixed any time soon? Thanks, Egor On 09-Apr-19 08:15, David Holmes wrote: > Hi Egor, > > I want to re-emphasise that once JDK-8212117 is fixed then this bug > should also be fixed. > > On 5/04/2019 8:30 pm, Egor Ushakov wrote: >> Hi David, thanks for your comments! >> >> I'm not sure how findComponentType worked in the current state: >> >> Type findComponentType(String signature) throws >> ClassNotLoadedException { >> 93 byte tag = (byte)signature.charAt(0); >> 94 if (PacketStream.isObjectTag(tag)) { >> 95 // It's a reference type >> 96 JNITypeParser parser = new JNITypeParser(componentSignature()); >> 97 List list = vm.classesByName(parser.typeName()); >> 98 Iterator iter = list.iterator(); >> 99 while (iter.hasNext()) { >> 100 ReferenceType type = iter.next(); >> 101 ClassLoaderReference cl = type.classLoader(); >> 102 if ((cl == null)? >> 103 (classLoader() == null) : >> 104 (cl.equals(classLoader()))) { >> 105 return type; >> 106 } >> 107 } >> 108 // Component class has not yet been loaded >> 109 throw new ClassNotLoadedException(componentTypeName()); >> 110 } else { >> 111 // It's a primitive type >> 112 return vm.primitiveTypeMirror(tag); >> 113 } >> ? 114???? } >> >> >> the method receives signature string but uses it only for object >> checking, then inside it does the search by componentSignature() >> instead... >> Most probably the method is always called passing >> componentSignature() string as a parameter anyway. >> >> Regarding the fix: >> the only thing I'm trying to change here is where the requested type >> name is looked at - loader.visibleClasses (this is where findType >> ends up) instead of vm.classesByName. >> This is how it works in all other implementors of >> com.sun.tools.jdi.ValueContainer.findType. > > Yes but I'm trying to determine why the difference exists - if we > already had loader.findType then why go to the bother of writing > findComponentType that way instead of just using findType? My concern > is that (ignoring the bug with not-initialized classes) the set of > classes returned by loader.visibleClasses may be different to that > which can be found via vm.classesByName. > > I'm not convinced we have adequate test coverage in this area. > >> ArrayTypeImpl.type() is unused, so I'm not sure how it was supposed >> to be used and where. > > Tracking the relationships between classes/interfaces here is quite > tricky and it had appeared to me that ArrayTypeImpl.type() could end > up getting used. But I've re-scanned the code and that seems not to be > the case. For good measure I changed it to always throw an exception > and re-ran all the JDI tests (though as I said coverage seems limited) > with no problems. > > If this is truly unused then we should delete it to avoid future > confusion - a separate RFE would be fine for that. > > Thanks, > David > >> I've run all jdi tests and see no regression, probably >> ClassNotLoadedException is never thrown in this case. >> >> Removed the test from the ProblemList in the new cr: >> http://cr.openjdk.java.net/~eushakov/8221503/webrev.01/ >> >> On 05-Apr-19 07:58, David Holmes wrote: >>> Hi Egor, >>> >>> This doesn't seem right to me sorry ... >>> >>> On 2/04/2019 7:42 pm, Egor Ushakov wrote: >>>> Please review the fix >>>> >>>> this test started to fail after the fix of >>>> https://bugs.openjdk.java.net/browse/JDK-8146986 >>>> previously any call to ClassLoaderReference.visibleClasses as a >>>> side effect cached the results in VirtualMachineImpl.typesBySignature >>>> and made them available to any VirtualMachine.classesByName call. >>>> This is somewhat not consistent for unprepared classes, I reported >>>> that, check >>>> Bug 26148990 : JDI - VirtualMachine.allClasses does not return >>>> loaded but uninitialized class, >>> >>> That issue is now a duplicate of this core-libs issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212117 >>> >>> which is in the process of being fixed. Once it is fixed then this >>> workaround would no longer be needed. >>> >>> That said I'm not at all clear how the proposed workaround actually >>> works-around the underlying issue. >>> >>>> but it seems that it allowed the ArrayTypeImpl.componentType to >>>> work even if the type was not prepared, >>>> check how ArrayTypeImpl#findComponentType uses vm.classesByName. >>>> It seems that ArrayTypeImpl#findComponentType should simply call >>>> findType for component signature. >>>> Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method >>>> works, not sure why it was dropped... >>> >>> The package-private: >>> >>> Type type() throws ClassNotLoadedException { >>> ??? return findType(elementSignature()); >>> } >>> >>> seems to have always existed but never been used as the >>> implementation for the public componentType() method (previously >>> elementType()). In fact the two methods appear to have different >>> requirements with regards to what they should be returning. AFAICS: >>> >>> - ArrayTypeImpl.type() returns the actual array type >>> - ArrayTypeImpl.componentType() returns the actual ultimate >>> component type >>> >>> i.e if I understand correctly, given double[][][] then >>> - ArrayTypeImpl.type() == double[][] >>> - ArrayTypeImpl.componentType() == double >>> >>> so implementing them both the same way can't possibly be correct! >>> >>>> bugid https://bugs.openjdk.java.net/browse/JDK-8221503 >>>> cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ >>>> >>>> Thanks! >>>> >>> >>> You'd also need to update the ProblemList so the test gets re-enabled. >>> >>> diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt >>> --- a/test/hotspot/jtreg/ProblemList.txt >>> +++ b/test/hotspot/jtreg/ProblemList.txt >>> @@ -161,8 +161,6 @@ >>> >>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>> 8065773 generic-all >>> >>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>> 8065773 generic-all >>> >>> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >>> - >>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>> generic-all >>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>> generic-all >>> ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 >>> generic-all >>> >>> It also appears to me that the exception message of the >>> ClassNotLoadedException will be different now. Have you re-run all >>> the JDI tests? >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> -- >>>> Egor Ushakov >>>> Software Developer >>>> JetBrains >>>> http://www.jetbrains.com >>>> The Drive to Develop >>>> >> >> -- >> Egor Ushakov >> Software Developer >> JetBrains >> http://www.jetbrains.com >> The Drive to Develop >> -- Egor Ushakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop From david.holmes at oracle.com Tue Apr 9 12:53:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Apr 2019 22:53:34 +1000 Subject: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][] In-Reply-To: <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> References: <578bcaf2-a2e4-8c34-a47a-3cbc7ad27374@jetbrains.com> <13d1f11a-6d91-8ac0-298e-278271eec1a6@oracle.com> <01902cdd-a0e8-4a6a-dc50-175cc00a2e3a@jetbrains.com> Message-ID: <057e627a-f488-0a30-d9e1-147627237383@oracle.com> On 9/04/2019 7:36 pm, Egor Ushakov wrote: > Hi David, > > you're right! The fix for JDK-8212117 should help here as well. > After that fix we may want to revisit ValueContainer.findType > implementors, currently they all (except for ArrayTypeImpl) > delegates to ReferenceTypeImpl.findType (which ends up in > classloader.visibleClasses). ArrayTypeImpl inherits findType from ReferenceTypeImpl. The issue is only the non-public findComponentType method. > Someone should clarify the difference between classLoader.visibleClasses > and allClasses filtered by the classLoader instance then. That would be good, I just don't know if there is anyone who would know (as opposed to trying to figure it out). > In my opinion fixing JDK-8212117 is risky and requires heavy testing, do > you think it may be fixed any time soon? Yes it's under way but the person doing it is away this week. Thanks, David > Thanks, > Egor > > On 09-Apr-19 08:15, David Holmes wrote: >> Hi Egor, >> >> I want to re-emphasise that once JDK-8212117 is fixed then this bug >> should also be fixed. >> >> On 5/04/2019 8:30 pm, Egor Ushakov wrote: >>> Hi David, thanks for your comments! >>> >>> I'm not sure how findComponentType worked in the current state: >>> >>> Type findComponentType(String signature) throws >>> ClassNotLoadedException { >>> 93 byte tag = (byte)signature.charAt(0); >>> 94 if (PacketStream.isObjectTag(tag)) { >>> 95 // It's a reference type >>> 96 JNITypeParser parser = new JNITypeParser(componentSignature()); >>> 97 List list = vm.classesByName(parser.typeName()); >>> 98 Iterator iter = list.iterator(); >>> 99 while (iter.hasNext()) { >>> 100 ReferenceType type = iter.next(); >>> 101 ClassLoaderReference cl = type.classLoader(); >>> 102 if ((cl == null)? >>> 103 (classLoader() == null) : >>> 104 (cl.equals(classLoader()))) { >>> 105 return type; >>> 106 } >>> 107 } >>> 108 // Component class has not yet been loaded >>> 109 throw new ClassNotLoadedException(componentTypeName()); >>> 110 } else { >>> 111 // It's a primitive type >>> 112 return vm.primitiveTypeMirror(tag); >>> 113 } >>> ? 114???? } >>> >>> >>> the method receives signature string but uses it only for object >>> checking, then inside it does the search by componentSignature() >>> instead... >>> Most probably the method is always called passing >>> componentSignature() string as a parameter anyway. >>> >>> Regarding the fix: >>> the only thing I'm trying to change here is where the requested type >>> name is looked at - loader.visibleClasses (this is where findType >>> ends up) instead of vm.classesByName. >>> This is how it works in all other implementors of >>> com.sun.tools.jdi.ValueContainer.findType. >> >> Yes but I'm trying to determine why the difference exists - if we >> already had loader.findType then why go to the bother of writing >> findComponentType that way instead of just using findType? My concern >> is that (ignoring the bug with not-initialized classes) the set of >> classes returned by loader.visibleClasses may be different to that >> which can be found via vm.classesByName. >> >> I'm not convinced we have adequate test coverage in this area. >> >>> ArrayTypeImpl.type() is unused, so I'm not sure how it was supposed >>> to be used and where. >> >> Tracking the relationships between classes/interfaces here is quite >> tricky and it had appeared to me that ArrayTypeImpl.type() could end >> up getting used. But I've re-scanned the code and that seems not to be >> the case. For good measure I changed it to always throw an exception >> and re-ran all the JDI tests (though as I said coverage seems limited) >> with no problems. >> >> If this is truly unused then we should delete it to avoid future >> confusion - a separate RFE would be fine for that. >> >> Thanks, >> David >> >>> I've run all jdi tests and see no regression, probably >>> ClassNotLoadedException is never thrown in this case. >>> >>> Removed the test from the ProblemList in the new cr: >>> http://cr.openjdk.java.net/~eushakov/8221503/webrev.01/ >>> >>> On 05-Apr-19 07:58, David Holmes wrote: >>>> Hi Egor, >>>> >>>> This doesn't seem right to me sorry ... >>>> >>>> On 2/04/2019 7:42 pm, Egor Ushakov wrote: >>>>> Please review the fix >>>>> >>>>> this test started to fail after the fix of >>>>> https://bugs.openjdk.java.net/browse/JDK-8146986 >>>>> previously any call to ClassLoaderReference.visibleClasses as a >>>>> side effect cached the results in VirtualMachineImpl.typesBySignature >>>>> and made them available to any VirtualMachine.classesByName call. >>>>> This is somewhat not consistent for unprepared classes, I reported >>>>> that, check >>>>> Bug 26148990 : JDI - VirtualMachine.allClasses does not return >>>>> loaded but uninitialized class, >>>> >>>> That issue is now a duplicate of this core-libs issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212117 >>>> >>>> which is in the process of being fixed. Once it is fixed then this >>>> workaround would no longer be needed. >>>> >>>> That said I'm not at all clear how the proposed workaround actually >>>> works-around the underlying issue. >>>> >>>>> but it seems that it allowed the ArrayTypeImpl.componentType to >>>>> work even if the type was not prepared, >>>>> check how ArrayTypeImpl#findComponentType uses vm.classesByName. >>>>> It seems that ArrayTypeImpl#findComponentType should simply call >>>>> findType for component signature. >>>>> Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method >>>>> works, not sure why it was dropped... >>>> >>>> The package-private: >>>> >>>> Type type() throws ClassNotLoadedException { >>>> ??? return findType(elementSignature()); >>>> } >>>> >>>> seems to have always existed but never been used as the >>>> implementation for the public componentType() method (previously >>>> elementType()). In fact the two methods appear to have different >>>> requirements with regards to what they should be returning. AFAICS: >>>> >>>> - ArrayTypeImpl.type() returns the actual array type >>>> - ArrayTypeImpl.componentType() returns the actual ultimate >>>> component type >>>> >>>> i.e if I understand correctly, given double[][][] then >>>> - ArrayTypeImpl.type() == double[][] >>>> - ArrayTypeImpl.componentType() == double >>>> >>>> so implementing them both the same way can't possibly be correct! >>>> >>>>> bugid https://bugs.openjdk.java.net/browse/JDK-8221503 >>>>> cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/ >>>>> >>>>> Thanks! >>>>> >>>> >>>> You'd also need to update the ProblemList so the test gets re-enabled. >>>> >>>> diff -r 532e88de77eb test/hotspot/jtreg/ProblemList.txt >>>> --- a/test/hotspot/jtreg/ProblemList.txt >>>> +++ b/test/hotspot/jtreg/ProblemList.txt >>>> @@ -161,8 +161,6 @@ >>>> >>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>> 8065773 generic-all >>>> >>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>> 8065773 generic-all >>>> >>>> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >>>> - >>>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>>> generic-all >>>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>>> generic-all >>>> ?vmTestbase/metaspace/gc/firstGC_99m/TestDescription.java 8208250 >>>> generic-all >>>> >>>> It also appears to me that the exception message of the >>>> ClassNotLoadedException will be different now. Have you re-run all >>>> the JDI tests? >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> -- >>>>> Egor Ushakov >>>>> Software Developer >>>>> JetBrains >>>>> http://www.jetbrains.com >>>>> The Drive to Develop >>>>> >>> >>> -- >>> Egor Ushakov >>> Software Developer >>> JetBrains >>> http://www.jetbrains.com >>> The Drive to Develop >>> > From jcbeyler at google.com Tue Apr 9 16:29:41 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 9 Apr 2019 09:29:41 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> Message-ID: Hi Serguei, I saw a nit here: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html arei -> are - I'm not sure you needed two files for the agents, you could have re-used some of the code and just called twice GetEnv but that is a detail. - I thought JNIEnv was not supposed to be really kept because it should not be used by another thread, is there not a risk that you are doing that? It doesn't look like it but I've been surprised in the past - Isn't there a chance that your second agent gets a normal JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and increments its counter? - I guess we'd see if it becomes flaky at some point? :) Thanks! Jc On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8222072 > > Webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ > > > Summary: > The JVMTI GenerateEvents() must send CompiledMethodLoad events only to > the agent which called it. > However, it sends events to all agents (jvmti environements) which > violates the JVMTI spec. > The webrev above fixes this issue and adds new jtreg test: > test/hotspot/jtreg/serviceability/jvmti/GenerateEvents > > > Testing: > Mach5 submission for: > - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti > - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents > > Thanks, > Serguei > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 9 20:58:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 13:58:18 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> Message-ID: <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> Hi Jc, Thank you a lot for looking at this! On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: > Hi Serguei, > > I saw a nit here: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html > > > arei -> are Nice catch, fixed. > - I'm not sure you needed two files for the agents, you could have > re-used some of the code and just called twice GetEnv but that is a > detail. Right. I initially wanted to use this way but then decided to use two real agent libraries. Wanted to exercise this path. > - I thought JNIEnv was not supposed to be really kept because it > should not be used by another thread, is there not a risk that you are > doing that? It doesn't look like it but I've been surprised in the past You are right. Tried to fix it in new webrev version below. > - Isn't there a chance that your second agent gets a normal > JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and > increments its counter? > ? ?- I guess we'd see if it becomes flaky at some point? :) Yes, it is expected. But they should be posted on threads other than Main thread. The callback should ignore them. The updated fix version is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ Thanks! Serguei > > Thanks! > Jc > > > On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com > > wrote: > > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8222072 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ > > > > Summary: > ? The JVMTI GenerateEvents() must send CompiledMethodLoad events > only to the agent which called it. > ? However, it sends events to all agents (jvmti environements) > which violates the JVMTI spec. > ? The webrev above fixes this issue and adds new jtreg test: > ??? test/hotspot/jtreg/serviceability/jvmti/GenerateEvents > > > Testing: > ? Mach5 submission for: > ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti > - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents > > Thanks, > Serguei > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 9 21:21:14 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 9 Apr 2019 14:21:14 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> Message-ID: Hi Serguei, Looks good to me now :) Jc On Tue, Apr 9, 2019 at 1:58 PM wrote: > Hi Jc, > > Thank you a lot for looking at this! > > On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: > > Hi Serguei, > > I saw a nit here: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html > > arei -> are > > > Nice catch, fixed. > > - I'm not sure you needed two files for the agents, you could have re-used > some of the code and just called twice GetEnv but that is a detail. > > > Right. > I initially wanted to use this way but then decided to use two real agent > libraries. > Wanted to exercise this path. > > - I thought JNIEnv was not supposed to be really kept because it should > not be used by another thread, is there not a risk that you are doing that? > It doesn't look like it but I've been surprised in the past > > > You are right. > Tried to fix it in new webrev version below. > > > - Isn't there a chance that your second agent gets a normal JVMTI_EVENT_COMPILED_METHOD_LOAD > before the GenerateEvents call and increments its counter? > - I guess we'd see if it becomes flaky at some point? :) > > Yes, it is expected. > But they should be posted on threads other than Main thread. > The callback should ignore them. > > > The updated fix version is: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ > > > Thanks! > Serguei > > > Thanks! > Jc > > > On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> Please, review a fix for: >> https://bugs.openjdk.java.net/browse/JDK-8222072 >> >> Webrev: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >> >> >> Summary: >> The JVMTI GenerateEvents() must send CompiledMethodLoad events only to >> the agent which called it. >> However, it sends events to all agents (jvmti environements) which >> violates the JVMTI spec. >> The webrev above fixes this issue and adds new jtreg test: >> test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> >> Testing: >> Mach5 submission for: >> - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >> - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> Thanks, >> Serguei >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 9 22:04:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 15:04:52 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> Message-ID: <8c738ee7-e62b-a850-7806-6cb870c5f7a8@oracle.com> Thank you, Jc! Serguei On 4/9/19 2:21 PM, Jean Christophe Beyler wrote: > Hi?Serguei, > > Looks good to me now :) > Jc > > On Tue, Apr 9, 2019 at 1:58 PM > wrote: > > Hi Jc, > > Thank you a lot for looking at this! > > On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: >> Hi Serguei, >> >> I saw a nit here: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html >> >> >> arei -> are > > Nice catch, fixed. > >> - I'm not sure you needed two files for the agents, you could >> have re-used some of the code and just called twice GetEnv but >> that is a detail. > > Right. > I initially wanted to use this way but then decided to use two > real agent libraries. > Wanted to exercise this path. > >> - I thought JNIEnv was not supposed to be really kept because it >> should not be used by another thread, is there not a risk that >> you are doing that? It doesn't look like it but I've been >> surprised in the past > > You are right. > Tried to fix it in new webrev version below. > > >> - Isn't there a chance that your second agent gets a normal >> JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call >> and increments its counter? >> ? ?- I guess we'd see if it becomes flaky at some point? :) > Yes, it is expected. > But they should be posted on threads other than Main thread. > The callback should ignore them. > > > The updated fix version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ > > > > Thanks! > Serguei > >> >> Thanks! >> Jc >> >> >> On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> Please, review a fix for: >> https://bugs.openjdk.java.net/browse/JDK-8222072 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >> >> >> >> Summary: >> ? The JVMTI GenerateEvents() must send CompiledMethodLoad >> events only to the agent which called it. >> ? However, it sends events to all agents (jvmti >> environements) which violates the JVMTI spec. >> ? The webrev above fixes this issue and adds new jtreg test: >> test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> >> Testing: >> ? Mach5 submission for: >> ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >> - new test: >> test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> Thanks, >> Serguei >> >> >> >> -- >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 9 22:19:47 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 15:19:47 -0700 Subject: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 In-Reply-To: <5CA5F24F.5080301@oracle.com> References: <5CA34C89.6040300@oracle.com> <18021204-820b-f7ca-74dd-49319d1f16c8@oracle.com> <5CA3A5B9.2090609@oracle.com> <2eedd2f9-871d-475b-e0ff-d1b79a490dc6@oracle.com> <5CA5F24F.5080301@oracle.com> Message-ID: <46aec1c2-1cbd-0966-84f0-4a4c0fd8f2af@oracle.com> Hi Gary, It looks Okay in general. On minor suggestion. Could you, introduce symbolic constants and use them for exit codes? They will be self-describing that way. Thanks, Serguei On 4/4/19 5:02 AM, Gary Adams wrote: > I need a second reviewer for this minor update. > > On 4/2/19, 2:18 PM, Chris Plummer wrote: >> On 4/2/19 11:11 AM, Gary Adams wrote: >>> The test exits with 3 for the general Exception. >>> I added 4 just to distinguish the return. >>> I see 7 used earlier when the lockfile is not initialized. >>> >>> I could add a message, if you think it is useful. >> Yes, I think it would be. >>> >>> The exit code is printed in stopApp(). line 377. >> Ok. I was just wondering if specific error codes were being checked >> for. It looks like that's not the case. >> >> thanks, >> >> Chris >>> >>> On 4/2/19, 1:58 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> I see various System.exit() calls with varying exit status. Is >>>> there some place that documents them? What is 4? >>>> >>>> Any reason not to print the exception before doing the System.exit(4)? >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/2/19 4:50 AM, Gary Adams wrote: >>>>> This proposed change allows a wider range of IOExceptions to be >>>>> observed >>>>> when a LingeredApp is being shutdown. It may not be just a >>>>> NoSuchFileException. >>>>> Botton line - if the lock file doesn't exist at the time the >>>>> IOException >>>>> is observed then the main application is terminating the test >>>>> sequence >>>>> and LingeredApp should end normally. >>>>> >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/ >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8203364 >>>> >>>> >>>> >>> >> >> > From daniil.x.titov at oracle.com Tue Apr 9 23:37:17 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 09 Apr 2019 16:37:17 -0700 Subject: RFR: 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails Message-ID: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> Please review the change that fixes intermittent failure of the test when running with Graal on. The problem here is the similar to the one fixed in JDK-8218401, the callbacks this test enables keep processing events and perform JVMTI calls after VM is terminated. The fix ensures that the test does a quick return from the callbacks after VMDeath event is received. Webrev: http://cr.openjdk.java.net/~dtitov/8222224/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222224 Thanks! --Daniil From alexey.menkov at oracle.com Tue Apr 9 23:57:03 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 9 Apr 2019 16:57:03 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> Message-ID: <177d6126-1270-d1fd-a0a6-a6123daa25c4@oracle.com> Hi Serguei, Maybe resolve code duplication in post_compiled_method_load(nmethod *nm) and post_compiled_method_load(JvmtiEnv* env, nmethod *nm)? Looks like the only difference is logging, but I don't think it's important as old post_compiled_method_load(JvmtiEnv* env, const jmethodID method, const jint length, ...) was not used. --alex On 04/09/2019 13:58, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > Thank you a lot for looking at this! > > On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: >> Hi Serguei, >> >> I saw a nit here: >> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html >> >> >> arei -> are > > Nice catch, fixed. > >> - I'm not sure you needed two files for the agents, you could have >> re-used some of the code and just called twice GetEnv but that is a >> detail. > > Right. > I initially wanted to use this way but then decided to use two real > agent libraries. > Wanted to exercise this path. > >> - I thought JNIEnv was not supposed to be really kept because it >> should not be used by another thread, is there not a risk that you are >> doing that? It doesn't look like it but I've been surprised in the past > > You are right. > Tried to fix it in new webrev version below. > > >> - Isn't there a chance that your second agent gets a normal >> JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and >> increments its counter? >> ? ?- I guess we'd see if it becomes flaky at some point? :) > Yes, it is expected. > But they should be posted on threads other than Main thread. > The callback should ignore them. > > > The updated fix version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ > > > Thanks! > Serguei > >> >> Thanks! >> Jc >> >> >> On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> Please, review a fix for: >> https://bugs.openjdk.java.net/browse/JDK-8222072 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >> >> >> >> Summary: >> ? The JVMTI GenerateEvents() must send CompiledMethodLoad events >> only to the agent which called it. >> ? However, it sends events to all agents (jvmti environements) >> which violates the JVMTI spec. >> ? The webrev above fixes this issue and adds new jtreg test: >> ??? test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> >> Testing: >> ? Mach5 submission for: >> ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >> - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >> >> Thanks, >> Serguei >> >> >> >> -- >> >> Thanks, >> Jc > From serguei.spitsyn at oracle.com Wed Apr 10 00:39:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 17:39:22 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: <177d6126-1270-d1fd-a0a6-a6123daa25c4@oracle.com> References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> <177d6126-1270-d1fd-a0a6-a6123daa25c4@oracle.com> Message-ID: <3e86a28e-5770-f3de-ebcd-66f01fe7de35@oracle.com> Hi Alex, Thank you for review! On 4/9/19 4:57 PM, Alex Menkov wrote: > Hi Serguei, > > Maybe resolve code duplication in post_compiled_method_load(nmethod > *nm) and post_compiled_method_load(JvmtiEnv* env, nmethod *nm)? > > Looks like the only difference is logging, but I don't think it's > important as old post_compiled_method_load(JvmtiEnv* env, const > jmethodID method, const jint length, ...) was not used. Another difference is that in case of GenerateEvents the phase is guaranteed to be LIVE. So, there is no need for the PRINORDIAL phase check. Also, I'm not sure yet how important the difference in logging is. Let me think a little bit more on this. Thanks, Serguei > --alex > > On 04/09/2019 13:58, serguei.spitsyn at oracle.com wrote: >> Hi Jc, >> >> Thank you a lot for looking at this! >> >> On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: >>> Hi Serguei, >>> >>> I saw a nit here: >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html >>> >>> >>> >>> arei -> are >> >> Nice catch, fixed. >> >>> - I'm not sure you needed two files for the agents, you could have >>> re-used some of the code and just called twice GetEnv but that is a >>> detail. >> >> Right. >> I initially wanted to use this way but then decided to use two real >> agent libraries. >> Wanted to exercise this path. >> >>> - I thought JNIEnv was not supposed to be really kept because it >>> should not be used by another thread, is there not a risk that you >>> are doing that? It doesn't look like it but I've been surprised in >>> the past >> >> You are right. >> Tried to fix it in new webrev version below. >> >> >>> - Isn't there a chance that your second agent gets a normal >>> JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and >>> increments its counter? >>> ? ?- I guess we'd see if it becomes flaky at some point? :) >> Yes, it is expected. >> But they should be posted on threads other than Main thread. >> The callback should ignore them. >> >> >> The updated fix version is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ >> >> >> >> Thanks! >> Serguei >> >>> >>> Thanks! >>> Jc >>> >>> >>> On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com >>> >> > wrote: >>> >>> ??? Please, review a fix for: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8222072 >>> >>> ??? Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >>> >>> >>> >>> ??? Summary: >>> ??? ? The JVMTI GenerateEvents() must send CompiledMethodLoad events >>> ??? only to the agent which called it. >>> ??? ? However, it sends events to all agents (jvmti environements) >>> ??? which violates the JVMTI spec. >>> ??? ? The webrev above fixes this issue and adds new jtreg test: >>> ??? ??? test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>> >>> >>> ??? Testing: >>> ??? ? Mach5 submission for: >>> ??? ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>> ??? - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>> >>> ??? Thanks, >>> ??? Serguei >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> From serguei.spitsyn at oracle.com Wed Apr 10 02:00:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 19:00:41 -0700 Subject: RFR: 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails In-Reply-To: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> References: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> Message-ID: <564d8a98-cf4b-476e-4196-bbf4fcacf565@oracle.com> Hi Daniil, It looks good. Thanks, Serguei On 4/9/19 4:37 PM, Daniil Titov wrote: > Please review the change that fixes intermittent failure of the test when running with Graal on. > > The problem here is the similar to the one fixed in JDK-8218401, the callbacks this test enables keep processing events and perform JVMTI calls after VM is terminated. The fix ensures that the test does a quick return from the callbacks after VMDeath event is received. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222224/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222224 > > Thanks! > --Daniil > > From serguei.spitsyn at oracle.com Wed Apr 10 01:56:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Apr 2019 18:56:58 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: <3e86a28e-5770-f3de-ebcd-66f01fe7de35@oracle.com> References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> <177d6126-1270-d1fd-a0a6-a6123daa25c4@oracle.com> <3e86a28e-5770-f3de-ebcd-66f01fe7de35@oracle.com> Message-ID: Hi Alex, New webrev version with refactoring: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.3/ I will also re-submit mach5 jobs for jvmti tests and new test. Thanks, Serguei On 4/9/19 5:39 PM, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you for review! > > On 4/9/19 4:57 PM, Alex Menkov wrote: >> Hi Serguei, >> >> Maybe resolve code duplication in post_compiled_method_load(nmethod >> *nm) and post_compiled_method_load(JvmtiEnv* env, nmethod *nm)? >> >> Looks like the only difference is logging, but I don't think it's >> important as old post_compiled_method_load(JvmtiEnv* env, const >> jmethodID method, const jint length, ...) was not used. > > Another difference is that in case of GenerateEvents the phase is > guaranteed to be LIVE. > So, there is no need for the PRINORDIAL phase check. > > Also, I'm not sure yet how important the difference in logging is. > Let me think a little bit more on this. > > Thanks, > Serguei > >> --alex >> >> On 04/09/2019 13:58, serguei.spitsyn at oracle.com wrote: >>> Hi Jc, >>> >>> Thank you a lot for looking at this! >>> >>> On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: >>>> Hi Serguei, >>>> >>>> I saw a nit here: >>>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html >>>> >>>> >>>> >>>> arei -> are >>> >>> Nice catch, fixed. >>> >>>> - I'm not sure you needed two files for the agents, you could have >>>> re-used some of the code and just called twice GetEnv but that is a >>>> detail. >>> >>> Right. >>> I initially wanted to use this way but then decided to use two real >>> agent libraries. >>> Wanted to exercise this path. >>> >>>> - I thought JNIEnv was not supposed to be really kept because it >>>> should not be used by another thread, is there not a risk that you >>>> are doing that? It doesn't look like it but I've been surprised in >>>> the past >>> >>> You are right. >>> Tried to fix it in new webrev version below. >>> >>> >>>> - Isn't there a chance that your second agent gets a normal >>>> JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and >>>> increments its counter? >>>> ? ?- I guess we'd see if it becomes flaky at some point? :) >>> Yes, it is expected. >>> But they should be posted on threads other than Main thread. >>> The callback should ignore them. >>> >>> >>> The updated fix version is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ >>> >>> >>> >>> Thanks! >>> Serguei >>> >>>> >>>> Thanks! >>>> Jc >>>> >>>> >>>> On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com >>>> >>> > wrote: >>>> >>>> ??? Please, review a fix for: >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8222072 >>>> >>>> ??? Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >>>> >>>> >>>> >>>> >>>> >>>> ??? Summary: >>>> ??? ? The JVMTI GenerateEvents() must send CompiledMethodLoad events >>>> ??? only to the agent which called it. >>>> ??? ? However, it sends events to all agents (jvmti environements) >>>> ??? which violates the JVMTI spec. >>>> ??? ? The webrev above fixes this issue and adds new jtreg test: >>>> test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>>> >>>> >>>> ??? Testing: >>>> ??? ? Mach5 submission for: >>>> ??? ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>> ??? - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>>> >>>> ??? Thanks, >>>> ??? Serguei >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> > From jcbeyler at google.com Wed Apr 10 02:38:51 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 9 Apr 2019 19:38:51 -0700 Subject: RFR: 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails In-Reply-To: <564d8a98-cf4b-476e-4196-bbf4fcacf565@oracle.com> References: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> <564d8a98-cf4b-476e-4196-bbf4fcacf565@oracle.com> Message-ID: Hi Daniil, Looks good to me too :-) Jc On Tue, Apr 9, 2019 at 7:01 PM wrote: > Hi Daniil, > > It looks good. > > Thanks, > Serguei > > > On 4/9/19 4:37 PM, Daniil Titov wrote: > > Please review the change that fixes intermittent failure of the test > when running with Graal on. > > > > The problem here is the similar to the one fixed in JDK-8218401, the > callbacks this test enables keep processing events and perform JVMTI calls > after VM is terminated. The fix ensures that the test does a quick return > from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222224/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222224 > > > > Thanks! > > --Daniil > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Wed Apr 10 12:32:38 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 10 Apr 2019 12:32:38 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> Message-ID: <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Apr 10 16:53:06 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Apr 2019 09:53:06 -0700 Subject: RFR(MS): 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv In-Reply-To: References: <9ecaa750-052f-c160-badc-9a13cf0011ab@oracle.com> <296611b6-a57c-1025-aa1b-3d79047e87b3@oracle.com> <177d6126-1270-d1fd-a0a6-a6123daa25c4@oracle.com> <3e86a28e-5770-f3de-ebcd-66f01fe7de35@oracle.com> Message-ID: <8f4b2574-d589-f851-3184-9eb1140bc3a0@oracle.com> Much simpler and cleaner! LGTM. --alex On 04/09/2019 18:56, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > New webrev version with refactoring: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.3/ > > > I will also re-submit mach5 jobs for jvmti tests and new test. > > Thanks, > Serguei > > > On 4/9/19 5:39 PM, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you for review! >> >> On 4/9/19 4:57 PM, Alex Menkov wrote: >>> Hi Serguei, >>> >>> Maybe resolve code duplication in post_compiled_method_load(nmethod >>> *nm) and post_compiled_method_load(JvmtiEnv* env, nmethod *nm)? >>> >>> Looks like the only difference is logging, but I don't think it's >>> important as old post_compiled_method_load(JvmtiEnv* env, const >>> jmethodID method, const jint length, ...) was not used. >> >> Another difference is that in case of GenerateEvents the phase is >> guaranteed to be LIVE. >> So, there is no need for the PRINORDIAL phase check. >> >> Also, I'm not sure yet how important the difference in logging is. >> Let me think a little bit more on this. >> >> Thanks, >> Serguei >> >>> --alex >>> >>> On 04/09/2019 13:58, serguei.spitsyn at oracle.com wrote: >>>> Hi Jc, >>>> >>>> Thank you a lot for looking at this! >>>> >>>> On 4/9/19 9:29 AM, Jean Christophe Beyler wrote: >>>>> Hi Serguei, >>>>> >>>>> I saw a nit here: >>>>> >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java.html >>>>> >>>>> >>>>> >>>>> arei -> are >>>> >>>> Nice catch, fixed. >>>> >>>>> - I'm not sure you needed two files for the agents, you could have >>>>> re-used some of the code and just called twice GetEnv but that is a >>>>> detail. >>>> >>>> Right. >>>> I initially wanted to use this way but then decided to use two real >>>> agent libraries. >>>> Wanted to exercise this path. >>>> >>>>> - I thought JNIEnv was not supposed to be really kept because it >>>>> should not be used by another thread, is there not a risk that you >>>>> are doing that? It doesn't look like it but I've been surprised in >>>>> the past >>>> >>>> You are right. >>>> Tried to fix it in new webrev version below. >>>> >>>> >>>>> - Isn't there a chance that your second agent gets a normal >>>>> JVMTI_EVENT_COMPILED_METHOD_LOAD before the GenerateEvents call and >>>>> increments its counter? >>>>> ? ?- I guess we'd see if it becomes flaky at some point? :) >>>> Yes, it is expected. >>>> But they should be posted on threads other than Main thread. >>>> The callback should ignore them. >>>> >>>> >>>> The updated fix version is: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.2/ >>>> >>>> >>>> >>>> Thanks! >>>> Serguei >>>> >>>>> >>>>> Thanks! >>>>> Jc >>>>> >>>>> >>>>> On Mon, Apr 8, 2019 at 12:29 PM serguei.spitsyn at oracle.com >>>>> >>>> > wrote: >>>>> >>>>> ??? Please, review a fix for: >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8222072 >>>>> >>>>> ??? Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222072-jvmti-GenerateEvents.1/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ??? Summary: >>>>> ??? ? The JVMTI GenerateEvents() must send CompiledMethodLoad events >>>>> ??? only to the agent which called it. >>>>> ??? ? However, it sends events to all agents (jvmti environements) >>>>> ??? which violates the JVMTI spec. >>>>> ??? ? The webrev above fixes this issue and adds new jtreg test: >>>>> test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>>>> >>>>> >>>>> ??? Testing: >>>>> ??? ? Mach5 submission for: >>>>> ??? ?? - JVMTI tests: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> ??? - new test: test/hotspot/jtreg/serviceability/jvmti/GenerateEvents >>>>> >>>>> ??? Thanks, >>>>> ??? Serguei >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>> >> > From alexey.menkov at oracle.com Wed Apr 10 16:56:07 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Apr 2019 09:56:07 -0700 Subject: RFR: 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails In-Reply-To: References: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> <564d8a98-cf4b-476e-4196-bbf4fcacf565@oracle.com> Message-ID: <94259763-97b8-6f36-597e-8024eaf27ab9@oracle.com> +1 --alex On 04/09/2019 19:38, Jean Christophe Beyler wrote: > Hi Daniil, > > Looks good to me too :-) > Jc > > On Tue, Apr 9, 2019 at 7:01 PM > wrote: > > Hi Daniil, > > It looks good. > > Thanks, > Serguei > > > On 4/9/19 4:37 PM, Daniil Titov wrote: > > Please review the change that fixes intermittent failure of the > test when running with Graal on. > > > > The problem here is the similar to the one fixed in JDK-8218401, > the callbacks this test enables keep processing events and perform > JVMTI calls after VM is terminated. The fix ensures that the test > does a quick return from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222224/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222224 > > > > Thanks! > > --Daniil > > > > > > > > -- > > Thanks, > Jc From jcbeyler at google.com Wed Apr 10 20:40:18 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 10 Apr 2019 13:40:18 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> Message-ID: Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? wrote: > Dear Jc, > Thanks a lot for your comments, here is the refined webrev. May I ask > your help to review again? > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ > > BRs, > Lin > > ? 2019?4?4????4:57?Jean Christophe Beyler ??? > > Hi Lin, > > Just a few nits to be honest: > > - > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html > > -> I don't think it's a good idea to just pass a char* and implicitly > imagine it is 256 in length > -> Should we not add that length as a parameter? btw, the test you have > len > 255 is a bit too restrictive no? Technically you should wait until > you find the last '/' and then test there no? > (technically we could use strrchr, no?) > > > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > -> the adding of the "," seems a bit off; I think it would be smarter to > just have a helper add_option to cmdline that checks if it is not empty, > then add "," and the new option > -> otherwise you always end the "," if there are more options even if > you are ignoring them, no? > > Finally: > } else if (subopt.equals("live")) { > - liveopt = "-live"; > + // Add '-' for compatibility. > + cmdline += "-" + subopt; > > for consistency with how you do it for "all", should this not be: > } else if (subopt.equals("live")) { > - liveopt = "-live"; > + // Add '-' for compatibility. > + cmdline += "-live"; > > Thanks, > Jc > > On Mon, Apr 1, 2019 at 5:18 AM ?? wrote: > >> Dear All? >> Here I updated the latest changeset which did the following refine: >> * fixed the compatibility issues so that old version of jmap can >> work normally with latest changeset. >> * revised the code for parsing the jmap histo arguments. >> * revised the logic for incremental dumping of jmap histo. >> The main change of this webrev is making all arguments passed to >> virtual machine as one line. So there is no need to care about the max >> argument count limitation. And hence resolved the compatibility issues as >> discussed in >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html >> >> May I ask your help to review? >> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ >> >> >> BRs, >> Lin >> >> ? 2019?2?26????10:50??? ??? >> >> Dear All, >> I have revised the webrev at >> http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. >> May I ask your help for reviewing? Thanks >> >> >> BRs, >> Lin >> >> -----Original Message----- >> From: ?? >> Sent: Friday, January 25, 2019 9:01 AM >> To: Hohensee, Paul ; serviceability- >> dev at openjdk.java.net >> Subject: Re: [RFR]8215623: Add incremental dump for jmap histo >> >> Dear All, >> May I get more review about this webrev? >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >> >> >> Thanks! >> Lin >> ________________________________________ >> From: ?? >> Sent: Wednesday, January 9, 2019 9:46:55 AM >> To: Hohensee, Paul; serviceability-dev at openjdk.java.net >> Subject: RE: [RFR]8215623: Add incremental dump for jmap histo >> >> Hi Paul and All, >> Thanks a lot for your review and comments, I have updated the webrev >> to >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >> Would you like to help review it. Thanks. >> >> BRs >> Lin >> >> From: ?? >> Sent: Monday, January 7, 2019 7:14 PM >> To: Hohensee, Paul ; serviceability- >> dev at openjdk.java.net; ?? >> Subject: RE: [RFR]8215623: Add incremental dump for jmap histo >> >> And another way is to add a argument ?IncrementalFile=?,which >> specifies the location for saving the intermediate data file. And if it >> is not >> specified, incremental data will dump to ?out?. >> >> What do you think? >> >> Thanks, >> Lin >> From: ?? >> Sent: Monday, January 7, 2019 7:02 PM >> To: Hohensee, Paul >> >; serviceability- >> dev at openjdk.java.net >> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo >> >> >> Dear Paul, >> >> Thanks for your review, I agree your suggestion to make incremental >> general. and >> >> I think the incremental file is better to be different with the >> file or the >> "out", because >> >> in future the parallel histo will have each thread individually dump >> their data, >> and I want >> >> it to be lock-free, so each thread need to dump to their own file. The >> final >> data >> >> will be sum up and dump to the file that "filename=" specified. >> Moreover, the incremental >> >> file contains intermediate data, if it is dumped to "", it more or >> less >> "pollute" the final file (final file that contains lots intermediate >> data). >> >> so the logic is that incremental data will be dumped to a file named >> "Histo_Dump_Temp.dump", >> >> if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be >> generated under the same folder, >> >> if "filename" not specified, it will dump to current dir. And if >> "chunkcount" is 0 >> or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. >> >> ________________________________ >> ???: Hohensee, Paul >> > >> ????: 2019?1?1? 4:56 >> ???: ??; serviceability-dev at openjdk.java.net> dev at openjdk.java.net> >> ??: Re: [RFR]8215623: Add incremental dump for jmap histo >> >> >> As for 8215622, update the copyright dates to 2019 please, since this >> won?t >> get pushed until then. >> >> >> >> You might generalize the implementation so that all inspections are done >> incrementally, and parameterize RecordInstanceClosure with the incremental >> threshold. ?incremental? could become ?chunkcount=?, where >> defaults to infinity (max value of size_t). >> >> >> >> I?d not use a default file name when ?chunkcount? is specified, I?d just >> write to >> whatever the output stream is. ?chunkcount? is then independent of ?file?. >> >> >> >> I?d add another histo argument for the maximum file size, call it >> ?maxfilesize?, >> and parameterize RecordInstanceClosure with it. Default would be infinity >> (max value of size_t). >> >> >> >> If you want to make it easy to use your 8k and 5mb chunkcount and >> maxfilesize combination, you could redefine your original ?incremental? >> argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. >> >> >> >> INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become >> DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and >> should be defined as ?const int? within RecordInstanceClosure. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> From: serviceability-dev > bounces at openjdk.java.net> bounces at openjdk.java.net>> on behalf of ?? >> > >> Date: Thursday, December 20, 2018 at 11:13 PM >> To: "serviceability-dev at openjdk.java.net> dev at openjdk.java.net>" > dev at openjdk.java.net> >> Subject: [RFR]8215623: Add incremental dump for jmap histo >> >> >> >> Hi All, >> >> May I ask your help to review this patch for enhance jmap ?histo. >> >> It adds the ?incremental? arguments that allow jmap ?histo to >> incrementally >> save the intermediate data into a temp file. >> >> The intermediate data is dumped incrementally and write to a rolling file, >> which limit the size of the temp file to be small. >> >> This is useful for user to get intermediate results when jmap/jvm process >> is >> killed accidentally. Especially when the heap is large. >> >> >> >> This patch is also part of the enhancement described in >> https://bugs.openjdk.java.net/browse/JDK-8214535. >> >> >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >> >> >> >> Thanks. >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Wed Apr 10 21:19:46 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 10 Apr 2019 14:19:46 -0700 Subject: 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails In-Reply-To: <84D92C52-7EFA-4249-8AE2-5D943069FEE2@oracle.com> References: <0C049494-F9A4-4ADC-B3AF-C5E3AB8CA75B@oracle.com> <564d8a98-cf4b-476e-4196-bbf4fcacf565@oracle.com> <84D92C52-7EFA-4249-8AE2-5D943069FEE2@oracle.com> Message-ID: Thank you, Serguei, JC, and Alex, for reviewing this change. Best regards, Daniil ?On 4/10/19, 9:58 AM, "serviceability-dev on behalf of Alex Menkov" wrote: +1 --alex On 04/09/2019 19:38, Jean Christophe Beyler wrote: > Hi Daniil, > > Looks good to me too :-) > Jc > > On Tue, Apr 9, 2019 at 7:01 PM > wrote: > > Hi Daniil, > > It looks good. > > Thanks, > Serguei > > > On 4/9/19 4:37 PM, Daniil Titov wrote: > > Please review the change that fixes intermittent failure of the > test when running with Graal on. > > > > The problem here is the similar to the one fixed in JDK-8218401, > the callbacks this test enables keep processing events and perform > JVMTI calls after VM is terminated. The fix ensures that the test > does a quick return from the callbacks after VMDeath event is received. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222224/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222224 > > > > Thanks! > > --Daniil > > > > > > > > -- > > Thanks, > Jc From zanglin5 at jd.com Thu Apr 11 02:26:03 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 11 Apr 2019 02:26:03 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> Message-ID: <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ? 2019?4?11????4:40?Jean Christophe Beyler > ??? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Thu Apr 11 03:16:01 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 11 Apr 2019 03:16:01 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> Message-ID: <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> Also realized it requires a JCP ticket, I will create it. Cheers, Lin ? 2019?4?11????10:26??? > ??? Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ? 2019?4?11????4:40?Jean Christophe Beyler > ??? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Thu Apr 11 03:22:41 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 11 Apr 2019 03:22:41 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> Message-ID: Sorry, it should be CSR ticket Thanks? Lin ? 2019?4?11????11:16??? > ??? Also realized it requires a JCP ticket, I will create it. Cheers, Lin ? 2019?4?11????10:26??? > ??? Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ? 2019?4?11????4:40?Jean Christophe Beyler > ??? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Thu Apr 11 06:55:38 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 11 Apr 2019 06:55:38 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> Message-ID: <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> Dear All, I have created a CSR at https://bugs.openjdk.java.net/browse/JDK-8222319. May I ask your help to review it? Thanks! BRs, Lin ? 2019?4?11????11:22??? > ??? Sorry, it should be CSR ticket Thanks? Lin ? 2019?4?11????11:16??? > ??? Also realized it requires a JCP ticket, I will create it. Cheers, Lin ? 2019?4?11????10:26??? > ??? Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ? 2019?4?11????4:40?Jean Christophe Beyler > ??? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Apr 11 18:24:31 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 11 Apr 2019 14:24:31 -0400 Subject: JDK-8177064: jcmd help command should not require the process identification Message-ID: <5CAF865F.3090702@oracle.com> Two years ago a request was made to allow jcmd help to be interpretted as a request for help from the current jcmd process rather than requiring a separate target process to be involved. Some attempts were made to close the issue, because the command was not documented to work that way. It was also pointed out that the help from the running jcmd might not match the cmds available from a subsequent request to a different process possibly running a different version of the vm. As proof of concept exercise this webrev shows a minimal set of changes that could support jcmd self help Before fleshing out additional changes in documentation and testing, I'd like to know if this is still a worth while enhancement. Also, I'd like to know more about the history of the checks preventing self attach. Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html Issue: https://bugs.openjdk.java.net/browse/JDK-8177064 From thomas.stuefe at gmail.com Thu Apr 11 18:52:20 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 11 Apr 2019 20:52:20 +0200 Subject: JDK-8177064: jcmd help command should not require the process identification In-Reply-To: <5CAF865F.3090702@oracle.com> References: <5CAF865F.3090702@oracle.com> Message-ID: Hi Gary, I am not sure this makes sense. jcmd can be used to access wildly different VMs with different command sets, including Vendor-specific commands (we have additional commands in the SapMachine, for instance). Also, jcmd is up- and downward compatible, and you can run older jcmd versions against newer VMs. So I do not think the list of commands of the VM jcmd happens to run under has any relation to the capabilities of the VMs one plans to attach to. Cheers Thomas On Thu, Apr 11, 2019 at 8:23 PM Gary Adams wrote: > Two years ago a request was made to allow > > jcmd help > > to be interpretted as a request for help from the current jcmd process > rather than requiring a separate target process to be involved. > > Some attempts were made to close the issue, because the > command was not documented to work that way. > It was also pointed out that the help from the running jcmd > might not match the cmds available from a subsequent > request to a different process possibly running a different version > of the vm. > > As proof of concept exercise this webrev shows a minimal set of > changes that could support > > jcmd self help > > Before fleshing out additional changes in documentation and testing, > I'd like to know if this is still a worth while enhancement. Also, > I'd like to know more about the history of the checks preventing self > attach. > > Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html > Issue: https://bugs.openjdk.java.net/browse/JDK-8177064 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Apr 12 00:16:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 10:16:35 +1000 Subject: JDK-8177064: jcmd help command should not require the process identification In-Reply-To: <5CAF865F.3090702@oracle.com> References: <5CAF865F.3090702@oracle.com> Message-ID: <15e69bee-6bf5-0865-0fa5-dbaf953220db@oracle.com> Hi Gary, On 12/04/2019 4:24 am, Gary Adams wrote: > Two years ago a request was made to allow > > ?? jcmd help > > to be interpretted as a request for help from the current jcmd process > rather than requiring a separate target process to be involved. > > Some attempts were made to close the issue, because the > command was not documented to work that way. > It was also pointed out that the help from the running jcmd > might not match the cmds available from a subsequent > request to a different process possibly running a different version > of the vm. > > As proof of concept exercise this webrev shows a minimal set of > changes that could support > > ? jcmd self help > > Before fleshing out additional changes in documentation and testing, > I'd like to know if this is still a worth while enhancement. Also, Given we allow a pid of 0 to mean all Java processes I can see scope for a special value that means "the current Java process", but using a text word like "self" seems awkward at best. Plus within a shell you can use: jcmd $$ help to act on the jcmd VM itself, so there doesn't need to be special treatment in that sense. Perhaps some tweaks to the "jcmd -h" text. > I'd like to know more about the history of the checks preventing self > attach. This may give you a start: https://bugs.openjdk.java.net/browse/JDK-8177154 Cheers, David > ? Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8177064 From serguei.spitsyn at oracle.com Fri Apr 12 00:18:19 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Apr 2019 17:18:19 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> Message-ID: <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> Hi Alex, Great debugging feature! While I'm still reading all the details, could you, please, fix some minor format issues? http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html + * If host is a literal IPv6 address, it may be in square brackets. Extra space before "square". http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html ?I'd suggest to unify comments before functions: ? - start comment with a capital latter and ended with a dot ? - use comment format like this: ?? /* ??? */ ?Examples of comments that need this change: 262 /* result must be release with dbgsysFreeAddrInfo */ => /* * Result must be release with dbgsysFreeAddrInfo. ?*/ 325 // input is sockaddr just because all clients have it => /* * Input is sockaddr just because all clients have it. */ 1129 /* reads boolean system value, 1130 * sets *result to trueValue if the ptoperty is "true", 1131 * to falseValue if the property if "false", 1132 * doesn't change *result if the property is not set or failed to read. 1133 */ => /* * Read boolean system value andset result to: * - trueValue if the property is "true" * - falseValue if the property is "false" * * Return JNI_OK if result is set, return JNI_ERR otherwise. */ . . . 293 * use IPv6 socket (to accept IPv6 and mapped Ipv4),... 342 * (with AF_INET6 Ipv4 addresses are not parsed even with AI_V4MAPPED and AI_ALL flags) ...345 hints.ai_family = AF_UNSPEC; // IPv6 or mapped Ipv4 ... 360 } else { // Ipv4 address Replace Ipv4 with IPv4 for unification with IPv6 For unification replace: convertIpv4ToIpv6 => convertIPv4ToIPv6 297 hints.ai_flags |= AI_PASSIVE 298 | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); Better to have just one line 1135 JNIEnv* env, . . . 1165 JNIEnv* jniEnv = NULL; A suggestion is to use the same name for JNIEnv*: ? 1135 JNIEnv* jni, . . . ? 1165 JNIEnv* jni = NULL; ? Reformat: 608 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 609 || (pass == 1 && ai->ai_family != preferredAddressFamily)) and 828 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 829 || (pass == 1 && ai->ai_family != preferredAddressFamily)) => if ((pass == 0 && ai->ai_family == preferredAddressFamily) || (pass == 1 && ai->ai_family != preferredAddressFamily)) ? Even better, replace it with logical XOR: if ((pass == 0 ^^ ai->ai_family == preferredAddressFamily) http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java.frames.html 102 /* Check that listening address returned by ListeningConnector.startListening() 103 * matches the address which was set via connector's arguments. 104 * Empty host address causes listening for local connections only (loopback interface) 105 * */ Dot is missed at the end. Replace "* */" with "*/". http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/jdk/com/sun/jdi/JdwpAllowTest.java.frames.html 162 // generate allow address by changing random bit in the local address 163 // and calculate 2 masks (prefix length) - one is matches original local address 164 // and another doesn't. Replace with /* style of comment. 249 positiveTest("PositiveMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + test.prefixLengthGood); 250 positiveTest("NegativeMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + test.prefixLengthBad); ? A suggestion to move second argument to additional line: positiveTest("PositiveMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + test.prefixLengthGood); positiveTest("NegativeMaskTest(" + test.localAddress + ")", test.allowAddress + "/" + test.prefixLengthBad); Thanks, Serguei On 4/2/19 4:14 PM, Alex Menkov wrote: > Updated webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/ > > - added support for addresses enclosed in square brackets; > - updated SocketTransportService.java to handle empty hostname the > same way as JDWP agent (listen/attach to loopback address); > Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java > (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). > > --alex > > On 04/01/2019 11:21, Alex Menkov wrote: >> Hi Chris, >> >> On 04/01/2019 04:50, Chris Hegarty wrote: >>> Alex, >>> >>> On 29/03/2019 22:07, Alex Menkov wrote: >>>> (added net-dev as suggested by Alan) >>>> >>>> Net gurus, please assist in reviewing socket-related code. >>>> >>>> New webrev: >>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >>> >>> Specifically on SocketTransportService.java. What Arthur has >>> proposed is better ( changing to lastIndexOf alone is not >>> sufficient ). Or is your assumption that the IPv6 literal is >>> not enclosed in square brackets? >> >> I didn't know about enclosing IPv6 in square brackets, but looks like >> that's standard way to alleviate conflict between IPv6 address and >> colon as port separator. >> Will update the fix to handle them in both JDI connectors >> (SocketTransportService.java) and debugger agent (socketTransport.c) >> >>> >>> If keeping Arthur's `static class HostPort` please make the >>> fields final. >>> >>> ?>> Would it make sense to support the preference properties? >>> ?>>??? java.net.preferIPv4Stack >>> ?>>??? java.net.preferIPv6Addresses >>> >>> I'm not sure about this, especially given the property name >>> prefixes. I need to think a little more on it. >> >> In the initial version of the fix I didn't check the properties. >> The rationale here is backward compatibility - is address is empty, >> old debuggers tries to connect to IPv4 address only. >> But handling this properties we will better handle clients with >> properties set (as jdb or any other debugger which uses JDI >> connectors are affected by the properties). >> >> BTW fix provided by Arthur implements listening on localhost >> differently - it creates several sockets and binds them to both IPv4 >> and IPv6 addresses. But the problem here (and that's the reason I >> decide to not implement it this way) - how to handle the case when we >> successfully bind on one address (for example IPv4), but fail to bind >> on other (for example the port is busy for IPv6 stack). Arthur's >> version just fail in the case (i.e. the whole Java process >> terminates) and I don't think this is good behavior. >> >> >>> >>> There is quite a bit of new native code, is it possible to >>> rewrite any of this in Java, e.g. reading of the system >>> properties ( if that is to remain )? >> >> socketTransport.c is a debugger agent which is completely native. >> >> --alex >> >>> >>> -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Apr 12 11:47:52 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 12 Apr 2019 07:47:52 -0400 Subject: JDK-8177064: jcmd help command should not require the process identification In-Reply-To: <15e69bee-6bf5-0865-0fa5-dbaf953220db@oracle.com> References: <5CAF865F.3090702@oracle.com> <15e69bee-6bf5-0865-0fa5-dbaf953220db@oracle.com> Message-ID: <5CB07AE8.2030602@oracle.com> On 4/11/19, 8:16 PM, David Holmes wrote: > Hi Gary, > > On 12/04/2019 4:24 am, Gary Adams wrote: >> Two years ago a request was made to allow >> >> jcmd help >> >> to be interpretted as a request for help from the current jcmd process >> rather than requiring a separate target process to be involved. >> >> Some attempts were made to close the issue, because the >> command was not documented to work that way. >> It was also pointed out that the help from the running jcmd >> might not match the cmds available from a subsequent >> request to a different process possibly running a different version >> of the vm. >> >> As proof of concept exercise this webrev shows a minimal set of >> changes that could support >> >> jcmd self help >> >> Before fleshing out additional changes in documentation and testing, >> I'd like to know if this is still a worth while enhancement. Also, > > Given we allow a pid of 0 to mean all Java processes I can see scope > for a special value that means "the current Java process", but using a > text word like "self" seems awkward at best. Plus within a shell you > can use: > jcmd $$ help $$ is the pid for the shell where the command is running, not the jcmd pid. $ jcmd $$ help 17076: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded at sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) at sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208) at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147) at sun.tools.jcmd.JCmd.main(JCmd.java:131) > > to act on the jcmd VM itself, so there doesn't need to be special > treatment in that sense. Perhaps some tweaks to the "jcmd -h" text. If we did allow the self attach, we would need to update the help text. I initially worked with -1 as another special value, but that looks a lot like -l the list argument. > >> I'd like to know more about the history of the checks preventing self >> attach. > > This may give you a start: > https://bugs.openjdk.java.net/browse/JDK-8177154 I understand the dangers of agent loading and the arguments against command line options and default settings that took place in jdk9 release. I'm looking for something older that explains the rationale about not allowing attach to the current process. > > Cheers, > David > >> Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html >> Issue: https://bugs.openjdk.java.net/browse/JDK-8177064 From david.holmes at oracle.com Fri Apr 12 13:06:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Apr 2019 23:06:08 +1000 Subject: JDK-8177064: jcmd help command should not require the process identification In-Reply-To: <5CB07AE8.2030602@oracle.com> References: <5CAF865F.3090702@oracle.com> <15e69bee-6bf5-0865-0fa5-dbaf953220db@oracle.com> <5CB07AE8.2030602@oracle.com> Message-ID: <06eb8f72-5a65-9a82-2aa7-f8147203c1ca@oracle.com> On 12/04/2019 9:47 pm, Gary Adams wrote: > On 4/11/19, 8:16 PM, David Holmes wrote: >> Hi Gary, >> >> On 12/04/2019 4:24 am, Gary Adams wrote: >>> Two years ago a request was made to allow >>> >>> ??? jcmd help >>> >>> to be interpretted as a request for help from the current jcmd process >>> rather than requiring a separate target process to be involved. >>> >>> Some attempts were made to close the issue, because the >>> command was not documented to work that way. >>> It was also pointed out that the help from the running jcmd >>> might not match the cmds available from a subsequent >>> request to a different process possibly running a different version >>> of the vm. >>> >>> As proof of concept exercise this webrev shows a minimal set of >>> changes that could support >>> >>> ?? jcmd self help >>> >>> Before fleshing out additional changes in documentation and testing, >>> I'd like to know if this is still a worth while enhancement. Also, >> >> Given we allow a pid of 0 to mean all Java processes I can see scope >> for a special value that means "the current Java process", but using a >> text word like "self" seems awkward at best. Plus within a shell you >> can use: jcmd $$ help > $$ is the pid for the shell where the command is running, > not the jcmd pid. Ooops. I thought there was a trick to pass the new process it's own pid as an arg. > $ jcmd $$ help > 17076: > com.sun.tools.attach.AttachNotSupportedException: Unable to open socket > file: target process not responding or HotSpot VM not loaded > ??? at > sun.tools.attach.BsdVirtualMachine.(BsdVirtualMachine.java:90) > ??? at > sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) > > ??? at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208) > ??? at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147) > ??? at sun.tools.jcmd.JCmd.main(JCmd.java:131) > >> >> to act on the jcmd VM itself, so there doesn't need to be special >> treatment in that sense. Perhaps some tweaks to the "jcmd -h" text. > If we did allow the self attach, we would need to update the help text. > I initially worked with -1 as another special value, but that looks a lot > like -l the list argument. > >> >>> I'd like to know more about the history of the checks preventing self >>> attach. >> >> This may give you a start: >> https://bugs.openjdk.java.net/browse/JDK-8177154 > I understand the dangers of agent loading and the arguments against > command line options and default settings that took place in jdk9 > release. > > I'm looking for something older that explains the rationale about > not allowing attach to the current process. I'd suggest speaking to Alan or Mandy. Cheers, David >> >> Cheers, >> David >> >>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8177064 > From yasuenag at gmail.com Fri Apr 12 14:05:30 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 12 Apr 2019 23:05:30 +0900 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent Message-ID: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> Hi all, I saw the message when I attached CLHSDB to target VM as below: ---- javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54 Warning! JS Engine can't start, some commands will not be available. ---- It has been reported as JDK-8157947. It is caused that jdk.hotspot.agent module is not exported to nashorn dynamic module. The comment in JDK-8157947 says that it will be fixed if we implement JSObject, but I think it is difficult because we cannot know what classes in SA are used in user scripts. So I think two approaches for this issue: 1. Open all packages in module-info in jdk.hotspot.agent I filed suggested fix to JBS, but it is not smart... 2. Open all packages in JSJavaScriptEngine:: Opens all packages to Module.EVERYONE_MODULE. But EVERYONE_MODULE is private field, so we need to access from JNI code. http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ This change has passed serviceability/sa jtreg tests. Both ideas is hackish, but I prefer to 2. to fix it. If 2. is accepted I will push it to submit repo and send review request. What do you think? Thanks, Yasumasa From jcbeyler at google.com Fri Apr 12 18:15:24 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 12 Apr 2019 11:15:24 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> Message-ID: Hi Lin, You could state in the CSR: - That not using the new flags makes the system behave as before; so it is a nop if you don't use the new flags - What happens if the flags are passed negative values? - What happens if the flags are passed crazy big numbers? Finally, I'd put a link to the current webrev if someone wanted more information. Apart from that, it looks good to me (I might skip the diff as you put the output below) the text could just say: here is the new usage text (maxchunk and maxfilesize are new) Thanks, Jc On Wed, Apr 10, 2019 at 11:56 PM ?? wrote: > Dear All, > I have created a CSR at > https://bugs.openjdk.java.net/browse/JDK-8222319. > May I ask your help to review it? Thanks! > > > BRs, > Lin > > ? 2019?4?11????11:22??? ??? > > Sorry, it should be CSR ticket > > Thanks? > Lin > > ? 2019?4?11????11:16??? ??? > > Also realized it requires a JCP ticket, I will create it. > > > Cheers, > Lin > > ? 2019?4?11????10:26??? ??? > > > Dear JC, > Thanks so much, I suddenly realized your way is exactly what I want. > And here is new wehbrev. > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ > > > BRs, > Lin > > ? 2019?4?11????4:40?Jean Christophe Beyler ??? > > Hi Lin, > > What I meant about the helper method was to not do this: > > > + private static String add_option(String cmd, String opt) { > + if (opt.equals("")) { > + return cmd; > + } > + return cmd + opt + ","; > + } > + > > but to do this: > > + private static String add_option(String cmd, String opt) { > + if (cmd.isEmpty()) { > + return opt; > + } > + return cmd + "," + opt; > + } > + > > That way you only put the ',' when needed, > Jc > > > > On Wed, Apr 10, 2019 at 5:33 AM ?? wrote: > >> Dear Jc, >> Thanks a lot for your comments, here is the refined webrev. May I >> ask your help to review again? >> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ >> >> BRs, >> Lin >> >> ? 2019?4?4????4:57?Jean Christophe Beyler ??? >> >> Hi Lin, >> >> Just a few nits to be honest: >> >> - >> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html >> >> -> I don't think it's a good idea to just pass a char* and implicitly >> imagine it is 256 in length >> -> Should we not add that length as a parameter? btw, the test you have >> len > 255 is a bit too restrictive no? Technically you should wait until >> you find the last '/' and then test there no? >> (technically we could use strrchr, no?) >> >> >> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html >> -> the adding of the "," seems a bit off; I think it would be smarter >> to just have a helper add_option to cmdline that checks if it is not empty, >> then add "," and the new option >> -> otherwise you always end the "," if there are more options even >> if you are ignoring them, no? >> >> Finally: >> } else if (subopt.equals("live")) { >> - liveopt = "-live"; >> + // Add '-' for compatibility. >> + cmdline += "-" + subopt; >> >> for consistency with how you do it for "all", should this not be: >> } else if (subopt.equals("live")) { >> - liveopt = "-live"; >> + // Add '-' for compatibility. >> + cmdline += "-live"; >> >> Thanks, >> Jc >> >> On Mon, Apr 1, 2019 at 5:18 AM ?? wrote: >> >>> Dear All? >>> Here I updated the latest changeset which did the following refine: >>> * fixed the compatibility issues so that old version of jmap can >>> work normally with latest changeset. >>> * revised the code for parsing the jmap histo arguments. >>> * revised the logic for incremental dumping of jmap histo. >>> The main change of this webrev is making all arguments passed to >>> virtual machine as one line. So there is no need to care about the max >>> argument count limitation. And hence resolved the compatibility issues as >>> discussed in >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html >>> >>> May I ask your help to review? >>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ >>> >>> >>> BRs, >>> Lin >>> >>> ? 2019?2?26????10:50??? ??? >>> >>> Dear All, >>> I have revised the webrev at >>> http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. >>> May I ask your help for reviewing? Thanks >>> >>> >>> BRs, >>> Lin >>> >>> -----Original Message----- >>> From: ?? >>> Sent: Friday, January 25, 2019 9:01 AM >>> To: Hohensee, Paul ; serviceability- >>> dev at openjdk.java.net >>> Subject: Re: [RFR]8215623: Add incremental dump for jmap histo >>> >>> Dear All, >>> May I get more review about this webrev? >>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >>> >>> >>> Thanks! >>> Lin >>> ________________________________________ >>> From: ?? >>> Sent: Wednesday, January 9, 2019 9:46:55 AM >>> To: Hohensee, Paul; serviceability-dev at openjdk.java.net >>> Subject: RE: [RFR]8215623: Add incremental dump for jmap histo >>> >>> Hi Paul and All, >>> Thanks a lot for your review and comments, I have updated the webrev >>> to >>> >>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >>> Would you like to help review it. Thanks. >>> >>> BRs >>> Lin >>> >>> From: ?? >>> Sent: Monday, January 7, 2019 7:14 PM >>> To: Hohensee, Paul ; serviceability- >>> dev at openjdk.java.net; ?? >>> Subject: RE: [RFR]8215623: Add incremental dump for jmap histo >>> >>> And another way is to add a argument ?IncrementalFile=?,which >>> specifies the location for saving the intermediate data file. And if it >>> is not >>> specified, incremental data will dump to ?out?. >>> >>> What do you think? >>> >>> Thanks, >>> Lin >>> From: ?? >>> Sent: Monday, January 7, 2019 7:02 PM >>> To: Hohensee, Paul >>> >; serviceability- >>> dev at openjdk.java.net >>> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo >>> >>> >>> Dear Paul, >>> >>> Thanks for your review, I agree your suggestion to make >>> incremental >>> general. and >>> >>> I think the incremental file is better to be different with the >>> file or the >>> "out", because >>> >>> in future the parallel histo will have each thread individually dump >>> their data, >>> and I want >>> >>> it to be lock-free, so each thread need to dump to their own file. The >>> final >>> data >>> >>> will be sum up and dump to the file that "filename=" specified. >>> Moreover, the incremental >>> >>> file contains intermediate data, if it is dumped to "", it more or >>> less >>> "pollute" the final file (final file that contains lots intermediate >>> data). >>> >>> so the logic is that incremental data will be dumped to a file >>> named >>> "Histo_Dump_Temp.dump", >>> >>> if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be >>> generated under the same folder, >>> >>> if "filename" not specified, it will dump to current dir. And if >>> "chunkcount" is 0 >>> or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. >>> >>> ________________________________ >>> ???: Hohensee, Paul >>> > >>> ????: 2019?1?1? 4:56 >>> ???: ??; serviceability-dev at openjdk.java.net>> dev at openjdk.java.net> >>> ??: Re: [RFR]8215623: Add incremental dump for jmap histo >>> >>> >>> As for 8215622, update the copyright dates to 2019 please, since this >>> won?t >>> get pushed until then. >>> >>> >>> >>> You might generalize the implementation so that all inspections are done >>> incrementally, and parameterize RecordInstanceClosure with the >>> incremental >>> threshold. ?incremental? could become ?chunkcount=?, where >>> defaults to infinity (max value of size_t). >>> >>> >>> >>> I?d not use a default file name when ?chunkcount? is specified, I?d just >>> write to >>> whatever the output stream is. ?chunkcount? is then independent of >>> ?file?. >>> >>> >>> >>> I?d add another histo argument for the maximum file size, call it >>> ?maxfilesize?, >>> and parameterize RecordInstanceClosure with it. Default would be infinity >>> (max value of size_t). >>> >>> >>> >>> If you want to make it easy to use your 8k and 5mb chunkcount and >>> maxfilesize combination, you could redefine your original ?incremental? >>> argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. >>> >>> >>> >>> INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become >>> DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and >>> should be defined as ?const int? within RecordInstanceClosure. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Paul >>> >>> >>> >>> From: serviceability-dev >> bounces at openjdk.java.net>> bounces at openjdk.java.net>> on behalf of ?? >>> > >>> Date: Thursday, December 20, 2018 at 11:13 PM >>> To: "serviceability-dev at openjdk.java.net>> dev at openjdk.java.net>" >> dev at openjdk.java.net> >>> Subject: [RFR]8215623: Add incremental dump for jmap histo >>> >>> >>> >>> Hi All, >>> >>> May I ask your help to review this patch for enhance jmap ?histo. >>> >>> It adds the ?incremental? arguments that allow jmap ?histo to >>> incrementally >>> save the intermediate data into a temp file. >>> >>> The intermediate data is dumped incrementally and write to a rolling >>> file, >>> which limit the size of the temp file to be small. >>> >>> This is useful for user to get intermediate results when jmap/jvm >>> process is >>> killed accidentally. Especially when the heap is large. >>> >>> >>> >>> This patch is also part of the enhancement described in >>> https://bugs.openjdk.java.net/browse/JDK-8214535. >>> >>> >>> >>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 >>> >>> >>> >>> Thanks. >>> >>> >>> >>> BRs, >>> >>> Lin >>> >>> >>> >>> >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Apr 12 23:58:17 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 12 Apr 2019 16:58:17 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> Message-ID: updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/ changes (vs webrev.02) are non-functional (added/edited comments, code reformatting, renaming convertIpv4ToIpv6 function to convertIPv4ToIPv6, renaming env variable to jniEnv (env is already used in one of the functions)). About pass/preferredAddressFamily conditions - there is no "logical xor" in C/C++. Also I think that the current condition is clearer. --alex On 04/11/2019 17:18, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Great debugging feature! > While I'm still reading all the details, could you, please, fix some > minor format issues? > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html > > + * If host is a literal IPv6 address, it may be in square > brackets. Extra space before "square". > > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html > > ?I'd suggest to unify comments before functions: > ? - start comment with a capital latter and ended with a dot > ? - use comment format like this: > ?? /* > ??? */ > > ?Examples of comments that need this change: > > 262 /* result must be release with dbgsysFreeAddrInfo */ => /* * Result > must be release with dbgsysFreeAddrInfo. ?*/ > > 325 // input is sockaddr just because all clients have it => > /* * Input is sockaddr just because all clients have it. */ > > 1129 /* reads boolean system value, > 1130 * sets *result to trueValue if the ptoperty is "true", > 1131 * to falseValue if the property if "false", > 1132 * doesn't change *result if the property is not set or failed to read. > 1133 */ => /* * Read boolean system value andset result to: * - > trueValue if the property is "true" > * - falseValue if the property is "false" * * Return JNI_OK if result is set, return JNI_ERR otherwise. > */ > > . . . > > 293 * use IPv6 socket (to accept IPv6 and mapped Ipv4),... > 342 * (with AF_INET6 Ipv4 addresses are not parsed even with AI_V4MAPPED > and AI_ALL flags) ...345 hints.ai_family = AF_UNSPEC; // IPv6 or mapped > Ipv4 ... 360 } else { // Ipv4 address Replace Ipv4 with IPv4 for > unification with IPv6 > For unification replace: convertIpv4ToIpv6 => convertIPv4ToIPv6 > > 297 hints.ai_flags |= AI_PASSIVE > 298 | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); Better to have just > one line > > > 1135 JNIEnv* env, . . . 1165 JNIEnv* jniEnv = NULL; > > A suggestion is to use the same name for JNIEnv*: > > ? 1135 JNIEnv* jni, . . . > ? 1165 JNIEnv* jni = NULL; > > > ? Reformat: > > 608 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 609 || > (pass == 1 && ai->ai_family != preferredAddressFamily)) and > > 828 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 829 || > (pass == 1 && ai->ai_family != preferredAddressFamily)) => if ((pass == > 0 && ai->ai_family == preferredAddressFamily) || (pass == 1 && > ai->ai_family != preferredAddressFamily)) > > ? Even better, replace it with logical XOR: > > if ((pass == 0 ^^ ai->ai_family == preferredAddressFamily) > > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java.frames.html > > 102 /* Check that listening address returned by > ListeningConnector.startListening() > 103 * matches the address which was set via connector's arguments. > 104 * Empty host address causes listening for local connections only > (loopback interface) > 105 * */ Dot is missed at the end. Replace "* */" with "*/". > > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/jdk/com/sun/jdi/JdwpAllowTest.java.frames.html > > 162 // generate allow address by changing random bit in the local address > 163 // and calculate 2 masks (prefix length) - one is matches original > local address > 164 // and another doesn't. Replace with /* style of comment. > > > 249 positiveTest("PositiveMaskTest(" + test.localAddress + ")", > test.allowAddress + "/" + test.prefixLengthGood); > 250 positiveTest("NegativeMaskTest(" + test.localAddress + ")", > test.allowAddress + "/" + test.prefixLengthBad); > > ? A suggestion to move second argument to additional line: > > positiveTest("PositiveMaskTest(" + test.localAddress + ")", > test.allowAddress + "/" + test.prefixLengthGood); > positiveTest("NegativeMaskTest(" + test.localAddress + ")", > test.allowAddress + "/" + test.prefixLengthBad); > > Thanks, > Serguei > > > On 4/2/19 4:14 PM, Alex Menkov wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/ >> >> - added support for addresses enclosed in square brackets; >> - updated SocketTransportService.java to handle empty hostname the >> same way as JDWP agent (listen/attach to loopback address); >> Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java >> (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). >> >> --alex >> >> On 04/01/2019 11:21, Alex Menkov wrote: >>> Hi Chris, >>> >>> On 04/01/2019 04:50, Chris Hegarty wrote: >>>> Alex, >>>> >>>> On 29/03/2019 22:07, Alex Menkov wrote: >>>>> (added net-dev as suggested by Alan) >>>>> >>>>> Net gurus, please assist in reviewing socket-related code. >>>>> >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >>>> >>>> Specifically on SocketTransportService.java. What Arthur has >>>> proposed is better ( changing to lastIndexOf alone is not >>>> sufficient ). Or is your assumption that the IPv6 literal is >>>> not enclosed in square brackets? >>> >>> I didn't know about enclosing IPv6 in square brackets, but looks like >>> that's standard way to alleviate conflict between IPv6 address and >>> colon as port separator. >>> Will update the fix to handle them in both JDI connectors >>> (SocketTransportService.java) and debugger agent (socketTransport.c) >>> >>>> >>>> If keeping Arthur's `static class HostPort` please make the >>>> fields final. >>>> >>>> ?>> Would it make sense to support the preference properties? >>>> ?>>??? java.net.preferIPv4Stack >>>> ?>>??? java.net.preferIPv6Addresses >>>> >>>> I'm not sure about this, especially given the property name >>>> prefixes. I need to think a little more on it. >>> >>> In the initial version of the fix I didn't check the properties. >>> The rationale here is backward compatibility - is address is empty, >>> old debuggers tries to connect to IPv4 address only. >>> But handling this properties we will better handle clients with >>> properties set (as jdb or any other debugger which uses JDI >>> connectors are affected by the properties). >>> >>> BTW fix provided by Arthur implements listening on localhost >>> differently - it creates several sockets and binds them to both IPv4 >>> and IPv6 addresses. But the problem here (and that's the reason I >>> decide to not implement it this way) - how to handle the case when we >>> successfully bind on one address (for example IPv4), but fail to bind >>> on other (for example the port is busy for IPv6 stack). Arthur's >>> version just fail in the case (i.e. the whole Java process >>> terminates) and I don't think this is good behavior. >>> >>> >>>> >>>> There is quite a bit of new native code, is it possible to >>>> rewrite any of this in Java, e.g. reading of the system >>>> properties ( if that is to remain )? >>> >>> socketTransport.c is a debugger agent which is completely native. >>> >>> --alex >>> >>>> >>>> -Chris. > From serguei.spitsyn at oracle.com Sat Apr 13 01:52:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Apr 2019 18:52:21 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> Message-ID: <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> Hi Alex, Thank you for the update! One more round of minor formatting change requests for better readability. :) #1: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html +??????????????? port = Integer.decode(hostPort.substring(splitIndex+1)); . . . +??????????? } else if (hostPort.charAt(0) == ?[? && hostPort.charAt(splitIndex-1) == ?]?) { ?Need spaces around ?+? and ?-? signs. #2: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c.udiff.html +??????? //make the socket a dual mode socket ?missed space at the start of comment Now, comments for: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html #3: 276???? /* check for host:port or port */ 277???? colon = strrchr(address, ?:?); 278???? port = (colon == NULL ? address : colon + 1); 279???? /* ensure the port is valid (getaddrinfo allows port to be empty) */ 280???? if (getPortNumber(port) < 0) { #4: 298???????? hints.ai_family = allowOnlyIPv4 ? AF_INET : AF_INET6; 299???????? hints.ai_flags |= AI_PASSIVE | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); 300???????? 301???? } else { #5: Replace ?fills? with ?fills in? in: 341? * Parses address (IPv4 or IPv6), fills result by parsed address. 383? * Parses prefix length from buffer (integer value), fills result with corresponding net mask. 485? * Parses ?allow? argument (fills list of allowed peers (global _peers variable)). #6: 410???? // generate mask for prefix length 411???? memset(result, 0, sizeof(*result)); 412???? // prefixLen <= 128, so we won?t go over result?s size 413???? for (int i = 0; prefixLen > 0; i++, prefixLen -= :sunglasses: { #7: 623 socketTransport_startListening(jdwpTransportEnv* env, const char* address, 624??????????????????????????????? char** actualAddress) 625 { . . . . 1173 static int readBooleanSysProp(int *result, int trueValue, int falseValue, 1174???? JNIEnv* jniEnv, jclass sysClass, jmethodID getPropMethod, const char *propName) 1175 { ?Move ?{? to the end of 624 and 1174. (edited) #8: 1176???? jstring value; 1177???? jstring name = (*jniEnv)->NewStringUTF(jniEnv, propName); 1178???? if (name == NULL) { . . . . 1259???? } while (0); 1260???? if (jniEnv != NULL && (*jniEnv)->ExceptionCheck(jniEnv)) { Thanks! Serguei On 4/12/19 4:58 PM, Alex Menkov wrote: > updated webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/ > > changes (vs webrev.02) are non-functional (added/edited comments, code > reformatting, renaming convertIpv4ToIpv6 function to > convertIPv4ToIPv6, renaming env variable to jniEnv (env is already > used in one of the functions)). > > About pass/preferredAddressFamily conditions - there is no "logical > xor" in C/C++. Also I think that the current condition is clearer. > > --alex > > On 04/11/2019 17:18, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Great debugging feature! >> While I'm still reading all the details, could you, please, fix some >> minor format issues? >> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html >> >> >> + * If host is a literal IPv6 address, it may be in >> square brackets. Extra space before "square". >> >> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html >> >> >> ??I'd suggest to unify comments before functions: >> ?? - start comment with a capital latter and ended with a dot >> ?? - use comment format like this: >> ??? /* >> ???? */ >> >> ??Examples of comments that need this change: >> >> 262 /* result must be release with dbgsysFreeAddrInfo */ => /* * >> Result must be release with dbgsysFreeAddrInfo. ?*/ >> >> 325 // input is sockaddr just because all clients have it => >> /* * Input is sockaddr just because all clients have it. */ >> >> 1129 /* reads boolean system value, >> 1130 * sets *result to trueValue if the ptoperty is "true", >> 1131 * to falseValue if the property if "false", >> 1132 * doesn't change *result if the property is not set or failed to >> read. >> 1133 */ => /* * Read boolean system value andset result to: * - >> trueValue if the property is "true" >> * - falseValue if the property is "false" *?? * Return JNI_OK if >> result is set, return JNI_ERR? otherwise. >> */ >> >> ? . . . >> >> 293 * use IPv6 socket (to accept IPv6 and mapped Ipv4),... >> 342 * (with AF_INET6 Ipv4 addresses are not parsed even with >> AI_V4MAPPED and AI_ALL flags) ...345 hints.ai_family = AF_UNSPEC; // >> IPv6 or mapped Ipv4 ... 360 } else { // Ipv4 address Replace Ipv4 >> with IPv4 for unification with IPv6 >> For unification replace: convertIpv4ToIpv6 => convertIPv4ToIPv6 >> >> 297 hints.ai_flags |= AI_PASSIVE >> 298 | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); Better to have just >> one line >> >> >> 1135 JNIEnv* env, . . . 1165 JNIEnv* jniEnv = NULL; >> >> A suggestion is to use the same name for JNIEnv*: >> >> ?? 1135 JNIEnv* jni, . . . >> ?? 1165 JNIEnv* jni = NULL; >> >> >> ?? Reformat: >> >> 608 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 609 || >> (pass == 1 && ai->ai_family != preferredAddressFamily)) and >> >> 828 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 829 || >> (pass == 1 && ai->ai_family != preferredAddressFamily)) => if ((pass >> == 0 && ai->ai_family == preferredAddressFamily) || (pass == 1 && >> ai->ai_family != preferredAddressFamily)) >> >> ?? Even better, replace it with logical XOR: >> >> ???????????? if ((pass == 0 ^^ ai->ai_family == preferredAddressFamily) >> >> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java.frames.html >> >> >> 102 /* Check that listening address returned by >> ListeningConnector.startListening() >> 103 * matches the address which was set via connector's arguments. >> 104 * Empty host address causes listening for local connections only >> (loopback interface) >> 105 * */ Dot is missed at the end. Replace "* */" with "*/". >> >> >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/jdk/com/sun/jdi/JdwpAllowTest.java.frames.html >> >> >> 162 // generate allow address by changing random bit in the local >> address >> 163 // and calculate 2 masks (prefix length) - one is matches >> original local address >> 164 // and another doesn't. Replace with /* style of comment. >> >> >> 249 positiveTest("PositiveMaskTest(" + test.localAddress + ")", >> test.allowAddress + "/" + test.prefixLengthGood); >> 250 positiveTest("NegativeMaskTest(" + test.localAddress + ")", >> test.allowAddress + "/" + test.prefixLengthBad); >> >> ?? A suggestion to move second argument to additional line: >> >> positiveTest("PositiveMaskTest(" + test.localAddress + ")", >> test.allowAddress + "/" + test.prefixLengthGood); >> positiveTest("NegativeMaskTest(" + test.localAddress + ")", >> test.allowAddress + "/" + test.prefixLengthBad); >> >> Thanks, >> Serguei >> >> >> On 4/2/19 4:14 PM, Alex Menkov wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/ >>> >>> - added support for addresses enclosed in square brackets; >>> - updated SocketTransportService.java to handle empty hostname the >>> same way as JDWP agent (listen/attach to loopback address); >>> Has to update >>> nsk/jdi/ListeningConnector/startListening/startlis001.java >>> (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). >>> >>> --alex >>> >>> On 04/01/2019 11:21, Alex Menkov wrote: >>>> Hi Chris, >>>> >>>> On 04/01/2019 04:50, Chris Hegarty wrote: >>>>> Alex, >>>>> >>>>> On 29/03/2019 22:07, Alex Menkov wrote: >>>>>> (added net-dev as suggested by Alan) >>>>>> >>>>>> Net gurus, please assist in reviewing socket-related code. >>>>>> >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >>>>> >>>>> Specifically on SocketTransportService.java. What Arthur has >>>>> proposed is better ( changing to lastIndexOf alone is not >>>>> sufficient ). Or is your assumption that the IPv6 literal is >>>>> not enclosed in square brackets? >>>> >>>> I didn't know about enclosing IPv6 in square brackets, but looks >>>> like that's standard way to alleviate conflict between IPv6 address >>>> and colon as port separator. >>>> Will update the fix to handle them in both JDI connectors >>>> (SocketTransportService.java) and debugger agent (socketTransport.c) >>>> >>>>> >>>>> If keeping Arthur's `static class HostPort` please make the >>>>> fields final. >>>>> >>>>> ?>> Would it make sense to support the preference properties? >>>>> ?>>??? java.net.preferIPv4Stack >>>>> ?>>??? java.net.preferIPv6Addresses >>>>> >>>>> I'm not sure about this, especially given the property name >>>>> prefixes. I need to think a little more on it. >>>> >>>> In the initial version of the fix I didn't check the properties. >>>> The rationale here is backward compatibility - is address is empty, >>>> old debuggers tries to connect to IPv4 address only. >>>> But handling this properties we will better handle clients with >>>> properties set (as jdb or any other debugger which uses JDI >>>> connectors are affected by the properties). >>>> >>>> BTW fix provided by Arthur implements listening on localhost >>>> differently - it creates several sockets and binds them to both >>>> IPv4 and IPv6 addresses. But the problem here (and that's the >>>> reason I decide to not implement it this way) - how to handle the >>>> case when we successfully bind on one address (for example IPv4), >>>> but fail to bind on other (for example the port is busy for IPv6 >>>> stack). Arthur's version just fail in the case (i.e. the whole Java >>>> process terminates) and I don't think this is good behavior. >>>> >>>> >>>>> >>>>> There is quite a bit of new native code, is it possible to >>>>> rewrite any of this in Java, e.g. reading of the system >>>>> properties ( if that is to remain )? >>>> >>>> socketTransport.c is a debugger agent which is completely native. >>>> >>>> --alex >>>> >>>>> >>>>> -Chris. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Mon Apr 15 02:54:02 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Mon, 15 Apr 2019 02:54:02 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> Message-ID: Dear Jc, Thanks a lot for your suggestions, I have updated the CSR. Hi All, May I get more review about the webrev and CSR, Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ CSR: https://bugs.openjdk.java.net/browse/JDK-8222319. BRs, Lin ? 2019?4?13????2:15?Jean Christophe Beyler > ??? Hi Lin, You could state in the CSR: - That not using the new flags makes the system behave as before; so it is a nop if you don't use the new flags - What happens if the flags are passed negative values? - What happens if the flags are passed crazy big numbers? Finally, I'd put a link to the current webrev if someone wanted more information. Apart from that, it looks good to me (I might skip the diff as you put the output below) the text could just say: here is the new usage text (maxchunk and maxfilesize are new) Thanks, Jc On Wed, Apr 10, 2019 at 11:56 PM ?? > wrote: Dear All, I have created a CSR at https://bugs.openjdk.java.net/browse/JDK-8222319. May I ask your help to review it? Thanks! BRs, Lin ? 2019?4?11????11:22??? > ??? Sorry, it should be CSR ticket Thanks? Lin ? 2019?4?11????11:16??? > ??? Also realized it requires a JCP ticket, I will create it. Cheers, Lin ? 2019?4?11????10:26??? > ??? Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ? 2019?4?11????4:40?Jean Christophe Beyler > ??? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ?? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ? 2019?4?4????4:57?Jean Christophe Beyler > ??? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ?? > wrote: Dear All? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ? 2019?2?26????10:50??? > ??? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ?? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ?? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ?? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ?? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ?IncrementalFile=?,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ?out?. What do you think? Thanks, Lin From: ?? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ??: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ???: Hohensee, Paul >> ????: 2019?1?1? 4:56 ???: ??; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ??: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won?t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ?incremental? could become ?chunkcount=?, where defaults to infinity (max value of size_t). I?d not use a default file name when ?chunkcount? is specified, I?d just write to whatever the output stream is. ?chunkcount? is then independent of ?file?. I?d add another histo argument for the maximum file size, call it ?maxfilesize?, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ?incremental? argument as syntactic sugar for ?chunkcount=8k,maxfilesize=5m?. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ?const int? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ?? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It adds the ?incremental? arguments that allow jmap ?histo to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Mon Apr 15 07:58:59 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 15 Apr 2019 13:28:59 +0530 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> Message-ID: <5CB439C3.6020105@oracle.com> Both options are hacks :( Personally I'm not comfortable with either option. JSObject wrapper suggested in the bug is not impossible to do. VM.getVM() would the "initial object" -- a JSObject impl. that walks through objects is possible. JSObject impls. can cache fields/methods reflectively and invoke those as needed. If SA class is needed, we can add JSClassObject impl. (which would a JSObject impl. that'd support static method/field access). -Sundar On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: > Hi all, > > I saw the message when I attached CLHSDB to target VM as below: > > ---- > javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not > a function in sa.js at line number 54 > Warning! JS Engine can't start, some commands will not be available. > ---- > > It has been reported as JDK-8157947. > > > It is caused that jdk.hotspot.agent module is not exported to > nashorn dynamic module. > The comment in JDK-8157947 says that it will be fixed if we implement > JSObject, but I think it is difficult because we cannot know > what classes in SA are used in user scripts. > > So I think two approaches for this issue: > > > 1. Open all packages in module-info in jdk.hotspot.agent > I filed suggested fix to JBS, but it is not smart... > > 2. Open all packages in JSJavaScriptEngine:: > Opens all packages to Module.EVERYONE_MODULE. > But EVERYONE_MODULE is private field, so we need to access > from JNI code. > http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ > This change has passed serviceability/sa jtreg tests. > > > Both ideas is hackish, but I prefer to 2. to fix it. > If 2. is accepted I will push it to submit repo and send review request. > > What do you think? > > > Thanks, > > Yasumasa From ralf.schmelter at sap.com Mon Apr 15 13:47:49 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 15 Apr 2019 13:47:49 +0000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings Message-ID: Hi, please review the small fix to jcmd. Instead of trying to convert only partially read bytes to Strings by hand, we now use an InputStreamReader instead. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8222491/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8222491 Best regards, Ralf From jcbeyler at google.com Mon Apr 15 14:30:01 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 15 Apr 2019 09:30:01 -0500 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: References: Message-ID: Hi Ralf, Not an official reviewer but it looks good to me :) Jc On Mon, Apr 15, 2019 at 8:49 AM Schmelter, Ralf wrote: > Hi, > > please review the small fix to jcmd. Instead of trying to convert only > partially read bytes to Strings by hand, we now use an InputStreamReader > instead. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8222491/webrev.0/ > bugreport: https://bugs.openjdk.java.net/browse/JDK-8222491 > > Best regards, > Ralf > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Mon Apr 15 23:51:45 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 16 Apr 2019 08:51:45 +0900 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <5CB439C3.6020105@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> Message-ID: Hi Sundar, On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: > Both options are hacks :( Personally I'm not comfortable with either > option. > > JSObject wrapper suggested in the bug is not impossible to do. > > VM.getVM() would the "initial object" -- a JSObject impl. that walks > through objects is possible. JSObject impls. can cache fields/methods > reflectively and invoke those as needed. If SA class is needed, we can > add JSClassObject impl. (which would a JSObject impl. that'd support > static method/field access). I guess SA classes will be added / modified due to HotSpot improvement (e.g. GC, JIT, etc...) So I think it is not reasonable to add JSClassObject implementations. In addition, I guess this restriction is on Nashorn only. Nashorn might be replaced to Graal.js . Do we see this issue with other JS Engine? If not so, I want to use other JS Engine (e,g, Graal). Thanks, Yasumasa > -Sundar > > On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I saw the message when I attached CLHSDB to target VM as below: >> >> ---- >> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not >> a function in sa.js at line number 54 >> Warning! JS Engine can't start, some commands will not be available. >> ---- >> >> It has been reported as JDK-8157947. >> >> >> It is caused that jdk.hotspot.agent module is not exported to >> nashorn dynamic module. >> The comment in JDK-8157947 says that it will be fixed if we implement >> JSObject, but I think it is difficult because we cannot know >> what classes in SA are used in user scripts. >> >> So I think two approaches for this issue: >> >> >> 1. Open all packages in module-info in jdk.hotspot.agent >> I filed suggested fix to JBS, but it is not smart... >> >> 2. Open all packages in JSJavaScriptEngine:: >> Opens all packages to Module.EVERYONE_MODULE. >> But EVERYONE_MODULE is private field, so we need to access >> from JNI code. >> http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >> This change has passed serviceability/sa jtreg tests. >> >> >> Both ideas is hackish, but I prefer to 2. to fix it. >> If 2. is accepted I will push it to submit repo and send review request. >> >> What do you think? >> >> >> Thanks, >> >> Yasumasa From sundararajan.athijegannathan at oracle.com Tue Apr 16 04:32:19 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 16 Apr 2019 10:02:19 +0530 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> Message-ID: <5CB55AD2.70106@oracle.com> Hi Yasumasa, Response comments inlined below.. On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote: > Hi Sundar, > > On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: >> Both options are hacks :( Personally I'm not comfortable with either >> option. >> >> JSObject wrapper suggested in the bug is not impossible to do. >> >> VM.getVM() would the "initial object" -- a JSObject impl. that walks >> through objects is possible. JSObject impls. can cache fields/methods >> reflectively and invoke those as needed. If SA class is needed, we can >> add JSClassObject impl. (which would a JSObject impl. that'd support >> static method/field access). > > I guess SA classes will be added / modified due to HotSpot improvement > (e.g. GC, JIT, etc...) > So I think it is not reasonable to add JSClassObject implementations. We need to add only *one* JSClassObject class (which can expose static fields/methods of a given java.lang.Class which is maintained as an instance field). Also, we may need to add a hook for looking for a class (like Java.type - but constructs JSClassObject instance instead). > > In addition, I guess this restriction is on Nashorn only. > Nashorn might be replaced to Graal.js . I'm not sure. If a JS implementation is module aware, it'll have the same issue. The core issue issue here we don't want public/exposed API from hotspot module. But we want to allow access to hotspot types, methods *only* from scripts => we need some sort of backdoor. I'd like JS reflection (JSObject) based backdoors rather than breaking module boundary using JNI code. > > Do we see this issue with other JS Engine? > If not so, I want to use other JS Engine (e,g, Graal). Yes, definitely no harm trying to see if other impls. have the same issue or not. Thanks, -Sundar > > > Thanks, > > Yasumasa > > >> -Sundar >> >> On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I saw the message when I attached CLHSDB to target VM as below: >>> >>> ---- >>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not >>> a function in sa.js at line number 54 >>> Warning! JS Engine can't start, some commands will not be available. >>> ---- >>> >>> It has been reported as JDK-8157947. >>> >>> >>> It is caused that jdk.hotspot.agent module is not exported to >>> nashorn dynamic module. >>> The comment in JDK-8157947 says that it will be fixed if we implement >>> JSObject, but I think it is difficult because we cannot know >>> what classes in SA are used in user scripts. >>> >>> So I think two approaches for this issue: >>> >>> >>> 1. Open all packages in module-info in jdk.hotspot.agent >>> I filed suggested fix to JBS, but it is not smart... >>> >>> 2. Open all packages in JSJavaScriptEngine:: >>> Opens all packages to Module.EVERYONE_MODULE. >>> But EVERYONE_MODULE is private field, so we need to access >>> from JNI code. >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >>> This change has passed serviceability/sa jtreg tests. >>> >>> >>> Both ideas is hackish, but I prefer to 2. to fix it. >>> If 2. is accepted I will push it to submit repo and send review >>> request. >>> >>> What do you think? >>> >>> >>> Thanks, >>> >>> Yasumasa From christoph.langer at sap.com Tue Apr 16 05:54:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 16 Apr 2019 05:54:43 +0000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: References: Message-ID: Hi Ralf, looks good, thanks for fixing this. I can push it for you. Can we please get another Reviewer's review? ?? Thanks & Best regards Christoph > -----Original Message----- > From: serviceability-dev On > Behalf Of Schmelter, Ralf > Sent: Montag, 15. April 2019 15:48 > To: serviceability-dev at openjdk.java.net > Subject: [CAUTION] RFR (S) 8222491: jcmd can fail converting UTF8 output to > strings > > Hi, > > please review the small fix to jcmd. Instead of trying to convert only partially > read bytes to Strings by hand, we now use an InputStreamReader instead. > > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8222491/webrev.0/ > bugreport: https://bugs.openjdk.java.net/browse/JDK-8222491 > > Best regards, > Ralf From david.holmes at oracle.com Tue Apr 16 06:40:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Apr 2019 16:40:41 +1000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: References: Message-ID: <68bda953-8b79-37c4-572a-26b097ae793a@oracle.com> Hi Ralf, Christoph, On 16/04/2019 3:54 pm, Langer, Christoph wrote: > Hi Ralf, > > looks good, thanks for fixing this. I can push it for you. > > Can we please get another Reviewer's review? ?? Well I agree that the fix addresses the problem that has been described. But I can't help but think there has to be a simpler way to pipe one inputstream into an outputstream without all the intermediary steps - ie creating strings. ?? Cheers, David > Thanks & Best regards > Christoph > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of Schmelter, Ralf >> Sent: Montag, 15. April 2019 15:48 >> To: serviceability-dev at openjdk.java.net >> Subject: [CAUTION] RFR (S) 8222491: jcmd can fail converting UTF8 output to >> strings >> >> Hi, >> >> please review the small fix to jcmd. Instead of trying to convert only partially >> read bytes to Strings by hand, we now use an InputStreamReader instead. >> >> webrev: >> http://cr.openjdk.java.net/~rschmelter/webrevs/8222491/webrev.0/ >> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222491 >> >> Best regards, >> Ralf From ralf.schmelter at sap.com Tue Apr 16 09:06:35 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 16 Apr 2019 09:06:35 +0000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: <68bda953-8b79-37c4-572a-26b097ae793a@oracle.com> References: <68bda953-8b79-37c4-572a-26b097ae793a@oracle.com> Message-ID: Hi David, of course you could just copy the bytes to System.out, but that would not respect the platforms character encoding. And since the PrintWriter of System.out has no write(char[], int, int) method, it is probably easier to just convert to a string. At least I've not found a convenience method to pipe a Reader to a PrintWriter using the char[] based methods. Best regards, Ralf -----Original Message----- From: David Holmes Sent: Dienstag, 16. April 2019 08:41 To: Langer, Christoph ; Schmelter, Ralf ; serviceability-dev at openjdk.java.net Subject: Re: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings Hi Ralf, Christoph, On 16/04/2019 3:54 pm, Langer, Christoph wrote: > Hi Ralf, > > looks good, thanks for fixing this. I can push it for you. > > Can we please get another Reviewer's review? ?? Well I agree that the fix addresses the problem that has been described. But I can't help but think there has to be a simpler way to pipe one inputstream into an outputstream without all the intermediary steps - ie creating strings. ?? Cheers, David From serguei.spitsyn at oracle.com Tue Apr 16 09:40:46 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 16 Apr 2019 02:40:46 -0700 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Apr 16 10:30:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Apr 2019 20:30:44 +1000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: References: <68bda953-8b79-37c4-572a-26b097ae793a@oracle.com> Message-ID: On 16/04/2019 7:06 pm, Schmelter, Ralf wrote: > Hi David, > > of course you could just copy the bytes to System.out, but that would not respect the platforms character encoding. I meant to do it with the encoding respected of course. > And since the PrintWriter of System.out has no write(char[], int, int) method, it is probably easier to just convert to a string. At least I've not found a convenience method to pipe a Reader to a PrintWriter using the char[] based methods. I feel there must be a better way :) but the fix is fine as-is. Thanks, David > > Best regards, > Ralf > > -----Original Message----- > From: David Holmes > Sent: Dienstag, 16. April 2019 08:41 > To: Langer, Christoph ; Schmelter, Ralf ; serviceability-dev at openjdk.java.net > Subject: Re: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings > > Hi Ralf, Christoph, > > On 16/04/2019 3:54 pm, Langer, Christoph wrote: >> Hi Ralf, >> >> looks good, thanks for fixing this. I can push it for you. >> >> Can we please get another Reviewer's review? ?? > > Well I agree that the fix addresses the problem that has been described. > > But I can't help but think there has to be a simpler way to pipe one > inputstream into an outputstream without all the intermediary steps - ie > creating strings. ?? > > Cheers, > David > From ralf.schmelter at sap.com Tue Apr 16 12:47:04 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 16 Apr 2019 12:47:04 +0000 Subject: RFR (S) 8222491: jcmd can fail converting UTF8 output to strings In-Reply-To: References: <68bda953-8b79-37c4-572a-26b097ae793a@oracle.com> Message-ID: > I feel there must be a better way :) but the fix is fine as-is. I share your feeling ;) The best we could come up with was to use the transferTo(Writer) method on the InpuStreamReader. But the PrintStream is unfortunately no Writer, although it is very close to being one. And wrapping the PrintStream in a OutputStreamWriter fails, since we cannot get the encoding used by the PrintStream (which is probably the default encoding, but I've not seen this specified). From ralf.schmelter at sap.com Wed Apr 17 08:30:42 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Wed, 17 Apr 2019 08:30:42 +0000 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding Message-ID: Can you please review this change, which ensures the sun.jdwp.listenerAddress property value is created using the platform encoding. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 Best regards, Ralf From yasuenag at gmail.com Wed Apr 17 14:07:00 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 17 Apr 2019 23:07:00 +0900 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <5CB55AD2.70106@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> Message-ID: Hi Sundar, On 2019/04/16 13:32, Sundararajan Athijegannathan wrote: > Hi Yasumasa, > > Response comments inlined below.. > > > On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote: >> Hi Sundar, >> >> On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: >>> Both options are hacks :( Personally I'm not comfortable with either >>> option. >>> >>> JSObject wrapper suggested in the bug is not impossible to do. >>> >>> VM.getVM() would the "initial object" -- a JSObject impl. that walks >>> through objects is possible. JSObject impls. can cache fields/methods >>> reflectively and invoke those as needed. If SA class is needed, we can >>> add JSClassObject impl. (which would a JSObject impl. that'd support >>> static method/field access). >> >> I guess SA classes will be added / modified due to HotSpot improvement >> (e.g. GC, JIT, etc...) >> So I think it is not reasonable to add JSClassObject implementations. > > We need to add only *one* JSClassObject class (which can expose static > fields/methods of a given java.lang.Class which is maintained as an > instance field). > > Also, we may need to add a hook for looking for a class (like Java.type > - but constructs JSClassObject instance instead). >> >> In addition, I guess this restriction is on Nashorn only. >> Nashorn might be replaced to Graal.js . > > I'm not sure. If a JS implementation is module aware, it'll have the > same issue. The core issue issue here we don't want public/exposed API > from hotspot module. But we want to allow access to hotspot types, > methods *only* from scripts => we need some sort of backdoor. I'd like > JS reflection (JSObject) based backdoors rather than breaking module > boundary using JNI code. > >> >> Do we see this issue with other JS Engine? >> If not so, I want to use other JS Engine (e,g, Graal). > > Yes, definitely no harm trying to see if other impls. have the same > issue or not. I tried to use Graal in CLHSDB, but it did not work well. Graal.js uses j.l.r.Proxy which is defined by dynamic module. So I saw IllegalAccessError when CLHSDB attempt to call VM.getVM(). Thanks, Yasumasa > Thanks, > -Sundar >> >> >> Thanks, >> >> Yasumasa >> >> >>> -Sundar >>> >>> On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I saw the message when I attached CLHSDB to target VM as below: >>>> >>>> ---- >>>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not >>>> a function in sa.js at line number 54 >>>> Warning! JS Engine can't start, some commands will not be available. >>>> ---- >>>> >>>> It has been reported as JDK-8157947. >>>> >>>> >>>> It is caused that jdk.hotspot.agent module is not exported to >>>> nashorn dynamic module. >>>> The comment in JDK-8157947 says that it will be fixed if we implement >>>> JSObject, but I think it is difficult because we cannot know >>>> what classes in SA are used in user scripts. >>>> >>>> So I think two approaches for this issue: >>>> >>>> >>>> ?? 1. Open all packages in module-info in jdk.hotspot.agent >>>> ??????? I filed suggested fix to JBS, but it is not smart... >>>> >>>> ?? 2. Open all packages in JSJavaScriptEngine:: >>>> ??????? Opens all packages to Module.EVERYONE_MODULE. >>>> ??????? But EVERYONE_MODULE is private field, so we need to access >>>> ??????? from JNI code. >>>> ????????? http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >>>> ??????? This change has passed serviceability/sa jtreg tests. >>>> >>>> >>>> Both ideas is hackish, but I prefer to 2. to fix it. >>>> If 2. is accepted I will push it to submit repo and send review >>>> request. >>>> >>>> What do you think? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From sgehwolf at redhat.com Wed Apr 17 17:32:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Apr 2019 19:32:12 +0200 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Ping? On Tue, 2019-04-09 at 11:33 +0200, Severin Gehwolf wrote: > Hi, > > Could I get another reviewer for this, please? Bob Vandette already reviewed it. > > Thank you! > > Cheers, > Severin > > On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: > > Could I get a second review, please? > > > > Thanks, > > Severin > > > > On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: > > > Sorry for the delay. The update looks good. > > > > > > Bob. > > > > > > > > > > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: > > > > > > > > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: > > > > > Could you maybe combine subsystem_file_contents with subsystem_file_line_contents > > > > > by adding an additional argument? > > > > > > > > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ > > > > > > > > Thanks, > > > > Severin > > > > From jcbeyler at google.com Wed Apr 17 18:17:45 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 17 Apr 2019 13:17:45 -0500 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: Hi Serguei, Looks good to me. When are we aiming to deprecate it entirely? Do we have an idea of the time frame? Thanks, Jc On Tue, Apr 16, 2019 at 4:41 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Please, review the fix of: > https://bugs.openjdk.java.net/browse/JDK-8192936 > > > Webrev (fix from Coleen): > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ > > I've already reviewed and updated the webrev with my suggestions. > > > Reviewed and approved CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Summary: > The fix introduces new VM option > -XX:AllowRedefinitionToAddOrDeleteMethods > for compatibility with previous releases. New option enables old > behavior > and allows the JVM TI RedefineClasses and RetransformClasses to > add/delete > private static and private final instance methods in the new class > versions. > Without this option the old behavior is disabled. > > New option is deprecated right away. > The plan is to keep this option for several releases to allow customers > (tool vendors) to remove dependency on old behavior from their tools. > > > Testing: > Added new test to verify that class redefinitions which add or delete > methods > return expected JVMTI error codes: > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > > Several jvmti, com/sun/jdi and java/lang/instrument tests which need old > behavior are updated to use new flag. > > Run locally on Linux-x64 the following test suites in release and > fastdebug mode: > - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ > - vmTestbase_nsk_jvmti > - vmTestbase_nsk_jdi > - vmTestbase_nsk_jdb > - vmTestbase_nsk_jdwp > - jdk_jdi > - jdk_instrument > > Submission of corresponding mach5 jobs is in progress. > > Thanks, > Serguei > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Apr 17 23:00:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Apr 2019 09:00:08 +1000 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: Hi Severin, I took a look at this (again**) and although I'm not at all familiar with the actual cgroup facilities the changes seem reasonable in that they only look for a hierarchical memory limit if the initial limit is "unlimited". So you can add me as a reviewer. Thanks, David ** I didn't previously review in the hope someone more cgroup knowledgeable would do so. On 18/04/2019 3:32 am, Severin Gehwolf wrote: > Ping? > > On Tue, 2019-04-09 at 11:33 +0200, Severin Gehwolf wrote: >> Hi, >> >> Could I get another reviewer for this, please? Bob Vandette already reviewed it. >> >> Thank you! >> >> Cheers, >> Severin >> >> On Tue, 2019-04-02 at 13:48 +0200, Severin Gehwolf wrote: >>> Could I get a second review, please? >>> >>> Thanks, >>> Severin >>> >>> On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote: >>>> Sorry for the delay. The update looks good. >>>> >>>> Bob. >>>> >>>> >>>>> On Mar 25, 2019, at 1:30 PM, Severin Gehwolf wrote: >>>>> >>>>> On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote: >>>>>> Could you maybe combine subsystem_file_contents with subsystem_file_line_contents >>>>>> by adding an additional argument? >>>>> >>>>> Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/ >>>>> >>>>> Thanks, >>>>> Severin >>>>> > From sgehwolf at redhat.com Thu Apr 18 07:52:37 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 18 Apr 2019 09:52:37 +0200 Subject: [PING2] RFR: 8217338: [Containers] Improve systemd slice memory limit support In-Reply-To: References: <4a1ae4e0e3efd68818bfe868349972aa878de60b.camel@redhat.com> <9a911da4b2a4a8eff42c7c2f1a19c06f6521da8d.camel@redhat.com> <226CB44C-7B3A-42E8-8385-4E85168DBA4E@oracle.com> <254f53446176175689373b346c11aabc26d9b4b0.camel@redhat.com> Message-ID: <6a7fce25a4aae4e64b8ca9f248cdf8d633db4132.camel@redhat.com> Hi, On Thu, 2019-04-18 at 09:00 +1000, David Holmes wrote: > So you can add me as a reviewer. Thank you, David! I appreciate that. Cheers, Severin From jcbeyler at google.com Thu Apr 18 14:18:22 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 18 Apr 2019 09:18:22 -0500 Subject: Providing users with thread type Message-ID: Hi all, When doing profiling, often users have a hard time determining what is happening inside libjvm.so. When doing profiling, the JVM seems like a black box and it is hard to differentiate between a thread doing GC/Compile/Actual VM work since all they get is profiles from libjvm.so but not what are the various profiles doing. We have a small patch that provides a method to users to ask what is the type of the current thread, which then provides one of those types (GC/Compile/Actual VM work). I'd like to ask if this seems like a reasonable thing to do and should I work on providing this via a JVMTI call. Something like GetCurrentThreadType. What do you all think? Is this sane and possible to try to push forward? Thanks for your opinions, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Apr 18 18:30:11 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 18 Apr 2019 14:30:11 -0400 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: <54782adf-5425-a041-4985-ac47e159f8b3@oracle.com> Hi Serguei, You made additional fixes for tests affected by this change to add -XX:+AllowRedefinitionToAddOrDeleteMethods.? These changes look good to me. Thanks, Coleen On 4/16/19 5:40 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix of: > https://bugs.openjdk.java.net/browse/JDK-8192936 > > > Webrev (fix from Coleen): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ > > I've already reviewed and updated the webrev with my suggestions. > > > Reviewed and approved CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Summary: > ? The fix introduces new VM option > -XX:AllowRedefinitionToAddOrDeleteMethods > ? for compatibility with previous releases.New option enables old behavior > ? and allows the JVM TI RedefineClasses and RetransformClasses to > add/delete > ? private static and private final instance methods in the new class > versions. > ? Without this option the old behavior is disabled. > > ? New option is deprecated right away. > ? The plan is to keep this option for several releases to allow customers > ? (tool vendors) to remove dependency on old behavior from their tools. > > > Testing: > ? Added new test to verify that class redefinitions which add or > delete methods > ? return expected JVMTI error codes: > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > > ? Several jvmti, com/sun/jdi and java/lang/instrument tests which need > old behavior are updated to use new flag. > > ? Run locally on Linux-x64 the following test suites in release and > fastdebug mode: > - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ > ??? - vmTestbase_nsk_jvmti > ??? - vmTestbase_nsk_jdi > ??? - vmTestbase_nsk_jdb > ??? - vmTestbase_nsk_jdwp > ? ? - jdk_jdi > ??? - jdk_instrument > > ? Submission of corresponding mach5 jobs is in progress. > > Thanks, > Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 18 19:58:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 18 Apr 2019 12:58:13 -0700 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: <54782adf-5425-a041-4985-ac47e159f8b3@oracle.com> References: <54782adf-5425-a041-4985-ac47e159f8b3@oracle.com> Message-ID: <541aa75d-7bdf-5e58-a50e-3bc5ece4c6f9@oracle.com> Hi Coleen, Thank you for review! Serguei On 4/18/19 11:30, coleen.phillimore at oracle.com wrote: > > Hi Serguei, > > You made additional fixes for tests affected by this change to add > -XX:+AllowRedefinitionToAddOrDeleteMethods.? These changes look good > to me. > > Thanks, > Coleen > > On 4/16/19 5:40 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix of: >> https://bugs.openjdk.java.net/browse/JDK-8192936 >> >> >> Webrev (fix from Coleen): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ >> >> I've already reviewed and updated the webrev with my suggestions. >> >> >> Reviewed and approved CSR: >> https://bugs.openjdk.java.net/browse/JDK-8221528 >> >> >> Summary: >> ? The fix introduces new VM option >> -XX:AllowRedefinitionToAddOrDeleteMethods >> ? for compatibility with previous releases. New option enables old >> behavior >> ? and allows the JVM TI RedefineClasses and RetransformClasses to >> add/delete >> ? private static and private final instance methods in the new class >> versions. >> ? Without this option the old behavior is disabled. >> >> ? New option is deprecated right away. >> ? The plan is to keep this option for several releases to allow customers >> ? (tool vendors) to remove dependency on old behavior from their tools. >> >> >> Testing: >> ? Added new test to verify that class redefinitions which add or >> delete methods >> ? return expected JVMTI error codes: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> ? Several jvmti, com/sun/jdi and java/lang/instrument tests which >> need old behavior are updated to use new flag. >> >> ? Run locally on Linux-x64 the following test suites in release and >> fastdebug mode: >> ??? - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ >> ??? - vmTestbase_nsk_jvmti >> ??? - vmTestbase_nsk_jdi >> ??? - vmTestbase_nsk_jdb >> ??? - vmTestbase_nsk_jdwp >> ? ? - jdk_jdi >> ??? - jdk_instrument >> >> ? Submission of corresponding mach5 jobs is in progress. >> >> Thanks, >> Serguei >> > From david.holmes at oracle.com Thu Apr 18 23:12:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Apr 2019 09:12:23 +1000 Subject: Providing users with thread type In-Reply-To: References: Message-ID: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> Hi Jc, On 19/04/2019 12:18 am, Jean Christophe Beyler wrote: > Hi all, > > When doing profiling, often users have a hard time determining what is > happening inside libjvm.so. When doing profiling, the JVM seems like a > black box and it is hard to differentiate between a thread doing > GC/Compile/Actual VM work since all they get is profiles from libjvm.so > but not what are the various profiles doing. > > We have a small patch that provides a method to users to ask what is the > type of the current thread, which then provides one of those types > (GC/Compile/Actual VM work). > > I'd like to ask if this seems like a reasonable thing to do and should I > work on providing this via a JVMTI call. Something like > GetCurrentThreadType. I think it would be difficult to put something like this in JVM TI given that the use of threads within the JVM are purely an implementation detail and not standardized in any way. And many of those threads are hidden from JVM TI anyway. The names of threads are the normal way to see what "type" of thread you're dealing with. Cheers, David > > What?do you all think? Is this sane and possible to try to push forward? > > Thanks for your opinions, > Jc From serguei.spitsyn at oracle.com Fri Apr 19 01:30:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 18 Apr 2019 18:30:58 -0700 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: Hi Jc, Thank you a lot for the review! The initial plan was to remove after a couple of releases. But there was an external suggestion to hit at least one LTS release before removal. So, the decision about exact release for removal is still on the table. We still collect information about tools that need this flag. Thanks, Serguei On 4/17/19 11:17 AM, Jean Christophe Beyler wrote: > Hi Serguei, > > Looks good to me. When are we aiming to deprecate it entirely? Do we > have an idea of the time frame? > > Thanks, > Jc > > On Tue, Apr 16, 2019 at 4:41 AM serguei.spitsyn at oracle.com > > wrote: > > Please, review the fix of: > https://bugs.openjdk.java.net/browse/JDK-8192936 > > > Webrev (fix from Coleen): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ > > > I've already reviewed and updated the webrev with my suggestions. > > > Reviewed and approved CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Summary: > ? The fix introduces new VM option > -XX:AllowRedefinitionToAddOrDeleteMethods > ? for compatibility with previous releases.New option enables old > behavior > ? and allows the JVM TI RedefineClasses and RetransformClasses to > add/delete > ? private static and private final instance methods in the new > class versions. > ? Without this option the old behavior is disabled. > > ? New option is deprecated right away. > ? The plan is to keep this option for several releases to allow > customers > ? (tool vendors) to remove dependency on old behavior from their > tools. > > > Testing: > ? Added new test to verify that class redefinitions which add or > delete methods > ? return expected JVMTI error codes: > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > > ? Several jvmti, com/sun/jdi and java/lang/instrument tests which > need old behavior are updated to use new flag. > > ? Run locally on Linux-x64 the following test suites in release > and fastdebug mode: > - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ > ??? - vmTestbase_nsk_jvmti > ??? - vmTestbase_nsk_jdi > ??? - vmTestbase_nsk_jdb > - vmTestbase_nsk_jdwp > ? ? - jdk_jdi > ??? - jdk_instrument > > ? Submission of corresponding mach5 jobs is in progress. > > Thanks, > Serguei > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Fri Apr 19 02:36:49 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 19 Apr 2019 08:06:49 +0530 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> Message-ID: <5CB93441.9080508@oracle.com> Hi Yasumasa Thanks for confirming that we've the same issue with Graal.js as well. I think JSObject impl. idea should be investigated. I think there is similar (script) reflective API in Graal.js as well. Thanks -Sundar On 17/04/19, 7:37 PM, Yasumasa Suenaga wrote: > Hi Sundar, > > On 2019/04/16 13:32, Sundararajan Athijegannathan wrote: >> Hi Yasumasa, >> >> Response comments inlined below.. >> >> >> On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote: >>> Hi Sundar, >>> >>> On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: >>>> Both options are hacks :( Personally I'm not comfortable with either >>>> option. >>>> >>>> JSObject wrapper suggested in the bug is not impossible to do. >>>> >>>> VM.getVM() would the "initial object" -- a JSObject impl. that walks >>>> through objects is possible. JSObject impls. can cache fields/methods >>>> reflectively and invoke those as needed. If SA class is needed, we can >>>> add JSClassObject impl. (which would a JSObject impl. that'd support >>>> static method/field access). >>> >>> I guess SA classes will be added / modified due to HotSpot >>> improvement (e.g. GC, JIT, etc...) >>> So I think it is not reasonable to add JSClassObject implementations. >> >> We need to add only *one* JSClassObject class (which can expose >> static fields/methods of a given java.lang.Class which is maintained >> as an instance field). >> >> Also, we may need to add a hook for looking for a class (like >> Java.type - but constructs JSClassObject instance instead). >>> >>> In addition, I guess this restriction is on Nashorn only. >>> Nashorn might be replaced to Graal.js . >> >> I'm not sure. If a JS implementation is module aware, it'll have the >> same issue. The core issue issue here we don't want public/exposed >> API from hotspot module. But we want to allow access to hotspot >> types, methods *only* from scripts => we need some sort of backdoor. >> I'd like JS reflection (JSObject) based backdoors rather than >> breaking module boundary using JNI code. >> >>> >>> Do we see this issue with other JS Engine? >>> If not so, I want to use other JS Engine (e,g, Graal). >> >> Yes, definitely no harm trying to see if other impls. have the same >> issue or not. > > I tried to use Graal in CLHSDB, but it did not work well. > Graal.js uses j.l.r.Proxy which is defined by dynamic module. > So I saw IllegalAccessError when CLHSDB attempt to call VM.getVM(). > > > Thanks, > > Yasumasa > > >> Thanks, >> -Sundar >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> -Sundar >>>> >>>> On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I saw the message when I attached CLHSDB to target VM as below: >>>>> >>>>> ---- >>>>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is >>>>> not >>>>> a function in sa.js at line number 54 >>>>> Warning! JS Engine can't start, some commands will not be available. >>>>> ---- >>>>> >>>>> It has been reported as JDK-8157947. >>>>> >>>>> >>>>> It is caused that jdk.hotspot.agent module is not exported to >>>>> nashorn dynamic module. >>>>> The comment in JDK-8157947 says that it will be fixed if we implement >>>>> JSObject, but I think it is difficult because we cannot know >>>>> what classes in SA are used in user scripts. >>>>> >>>>> So I think two approaches for this issue: >>>>> >>>>> >>>>> 1. Open all packages in module-info in jdk.hotspot.agent >>>>> I filed suggested fix to JBS, but it is not smart... >>>>> >>>>> 2. Open all packages in JSJavaScriptEngine:: >>>>> Opens all packages to Module.EVERYONE_MODULE. >>>>> But EVERYONE_MODULE is private field, so we need to access >>>>> from JNI code. >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >>>>> This change has passed serviceability/sa jtreg tests. >>>>> >>>>> >>>>> Both ideas is hackish, but I prefer to 2. to fix it. >>>>> If 2. is accepted I will push it to submit repo and send review >>>>> request. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa From yasuenag at gmail.com Fri Apr 19 13:07:52 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 19 Apr 2019 22:07:52 +0900 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <5CB93441.9080508@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> Message-ID: Hi Sundar, I tried to implement JSObject for SA. Following webrev is not completed, but it can get VM object and Debugger in it from sa.js: http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/jsobject.work/ It is not completed (error will occur when CLSDB is attached.) but I want to hear your opinion. So I share it. AFAIK JSObject impl. idea needs to use AbstractJSObject, but it is provided by jdk.scripting.nashorn module. However Nashorn has been deprecated by JEP 335 and it might be removed. Can we fix this issue not to depend on jdk.scripting.nashorn module? If it can't, is it allowed to use deprecated module? I guess Nashorn might be replaced to Graal.js in the future. So I concern it is not better to depend on Nashorn. Thanks, Yasumasa On 2019/04/19 11:36, Sundararajan Athijegannathan wrote: > Hi Yasumasa > > Thanks for confirming that we've the same issue with Graal.js as well. I > think JSObject impl. idea should be investigated. I think there is > similar (script) reflective API in Graal.js as well. > > Thanks > -Sundar > > On 17/04/19, 7:37 PM, Yasumasa Suenaga wrote: >> Hi Sundar, >> >> On 2019/04/16 13:32, Sundararajan Athijegannathan wrote: >>> Hi Yasumasa, >>> >>> Response comments inlined below.. >>> >>> >>> On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote: >>>> Hi Sundar, >>>> >>>> On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: >>>>> Both options are hacks :( Personally I'm not comfortable with either >>>>> option. >>>>> >>>>> JSObject wrapper suggested in the bug is not impossible to do. >>>>> >>>>> VM.getVM() would the "initial object" -- a JSObject impl. that walks >>>>> through objects is possible. JSObject impls. can cache fields/methods >>>>> reflectively and invoke those as needed. If SA class is needed, we can >>>>> add JSClassObject impl. (which would a JSObject impl. that'd support >>>>> static method/field access). >>>> >>>> I guess SA classes will be added / modified due to HotSpot >>>> improvement (e.g. GC, JIT, etc...) >>>> So I think it is not reasonable to add JSClassObject implementations. >>> >>> We need to add only *one* JSClassObject class (which can expose >>> static fields/methods of a given java.lang.Class which is maintained >>> as an instance field). >>> >>> Also, we may need to add a hook for looking for a class (like >>> Java.type - but constructs JSClassObject instance instead). >>>> >>>> In addition, I guess this restriction is on Nashorn only. >>>> Nashorn might be replaced to Graal.js . >>> >>> I'm not sure. If a JS implementation is module aware, it'll have the >>> same issue. The core issue issue here we don't want public/exposed >>> API from hotspot module. But we want to allow access to hotspot >>> types, methods *only* from scripts => we need some sort of backdoor. >>> I'd like JS reflection (JSObject) based backdoors rather than >>> breaking module boundary using JNI code. >>> >>>> >>>> Do we see this issue with other JS Engine? >>>> If not so, I want to use other JS Engine (e,g, Graal). >>> >>> Yes, definitely no harm trying to see if other impls. have the same >>> issue or not. >> >> I tried to use Graal in CLHSDB, but it did not work well. >> Graal.js uses j.l.r.Proxy which is defined by dynamic module. >> So I saw IllegalAccessError when CLHSDB attempt to call VM.getVM(). >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, >>> -Sundar >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> -Sundar >>>>> >>>>> On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I saw the message when I attached CLHSDB to target VM as below: >>>>>> >>>>>> ---- >>>>>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is >>>>>> not >>>>>> a function in sa.js at line number 54 >>>>>> Warning! JS Engine can't start, some commands will not be available. >>>>>> ---- >>>>>> >>>>>> It has been reported as JDK-8157947. >>>>>> >>>>>> >>>>>> It is caused that jdk.hotspot.agent module is not exported to >>>>>> nashorn dynamic module. >>>>>> The comment in JDK-8157947 says that it will be fixed if we implement >>>>>> JSObject, but I think it is difficult because we cannot know >>>>>> what classes in SA are used in user scripts. >>>>>> >>>>>> So I think two approaches for this issue: >>>>>> >>>>>> >>>>>> ?? 1. Open all packages in module-info in jdk.hotspot.agent >>>>>> ??????? I filed suggested fix to JBS, but it is not smart... >>>>>> >>>>>> ?? 2. Open all packages in JSJavaScriptEngine:: >>>>>> ??????? Opens all packages to Module.EVERYONE_MODULE. >>>>>> ??????? But EVERYONE_MODULE is private field, so we need to access >>>>>> ??????? from JNI code. >>>>>> ????????? http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >>>>>> ??????? This change has passed serviceability/sa jtreg tests. >>>>>> >>>>>> >>>>>> Both ideas is hackish, but I prefer to 2. to fix it. >>>>>> If 2. is accepted I will push it to submit repo and send review >>>>>> request. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa From Alan.Bateman at oracle.com Fri Apr 19 14:01:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Apr 2019 15:01:46 +0100 Subject: Providing users with thread type In-Reply-To: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> Message-ID: <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> On 19/04/2019 00:12, David Holmes wrote: > > I think it would be difficult to put something like this in JVM TI > given that the use of threads within the JVM are purely an > implementation detail and not standardized in any way. And many of > those threads are hidden from JVM TI anyway. > > The names of threads are the normal way to see what "type" of thread > you're dealing with. Right, JVM TI only deals with "Java threads" (jthread object) and has no knowledge about other threads. It might be possible to use its extension mechanism to provide information about other threads but it wouldn't be interoperable with anything that use jtherad objects. -Alan From jcbeyler at google.com Fri Apr 19 14:30:23 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 19 Apr 2019 09:30:23 -0500 Subject: Providing users with thread type In-Reply-To: <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> Message-ID: Problem is that if I don't have a jthread, I can't get the name it seems. Perhaps it could help if I gave more information: - In our JVM profiling mechanism, we have a SIGPROF (and maybe that's a wrong approach :-)) that gets cycled across threads (some Java threads, some are the other threads) - It is the other threads that I'm interested here to be able to distinguish what they are in terms of of profiles Is there any way we could provide that (not in JVMTI then)? - The only way I could imagine perhaps doing this would be perhaps to have a set of other tools at the same time running (either using beans before/after or JFR) but this seems crude as well (better than nothing though) - I wish there was a way to just be able to get a type for those internal frames while doing the actual SIGPROF handling FWIW, the method we expose basically is like this: Thread* current_thread = ThreadLocalStorage::get_thread_async_safe(); if (current_thread == NULL) { return -1; } else if (current_thread->is_Compiler_thread()) { return _activity_compile; } else if (current_thread->is_Java_thread()) { return -1; } else if (current_thread->is_GC_task_thread()) { return _activity_gc; } else if (current_thread->is_VM_thread()) { VMThread* vm_thread = (VMThread*) current_thread; VM_Operation* vm_op = vm_thread->vm_operation(); if (vm_op != NULL) { switch (vm_op->type()) { case VM_Operation::VMOp_GC_HeapInspection: case VM_Operation::VMOp_GenCollectFull: case VM_Operation::VMOp_GenCollectFullConcurrent: case VM_Operation::VMOp_GenCollectForAllocation: case VM_Operation::VMOp_ParallelGCFailedAllocation: case VM_Operation::VMOp_ParallelGCSystemGC: case VM_Operation::VMOp_CGC_Operation: case VM_Operation::VMOp_CMS_Initial_Mark: case VM_Operation::VMOp_CMS_Final_Remark: case VM_Operation::VMOp_G1CollectFull: case VM_Operation::VMOp_G1CollectForAllocation: case VM_Operation::VMOp_G1IncCollectionPause: return _activity_gc; default: break; } } } return _activity_other_vm; } It's crude but we believe it is effective to at least "bucketize" the internals while doing our profiling. Thanks for your input, Jc On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman wrote: > On 19/04/2019 00:12, David Holmes wrote: > > > > I think it would be difficult to put something like this in JVM TI > > given that the use of threads within the JVM are purely an > > implementation detail and not standardized in any way. And many of > > those threads are hidden from JVM TI anyway. > > > > The names of threads are the normal way to see what "type" of thread > > you're dealing with. > Right, JVM TI only deals with "Java threads" (jthread object) and has no > knowledge about other threads. It might be possible to use its extension > mechanism to provide information about other threads but it wouldn't be > interoperable with anything that use jtherad objects. > > -Alan > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Apr 19 17:06:35 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 19 Apr 2019 13:06:35 -0400 Subject: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException Message-ID: <5CBA001B.3070608@oracle.com> Prevent the debuggee from exiting too quickly by holding it at the breakpoint until the end of processing flag has been read by the main thread from the debugger process. Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8222741 From jcbeyler at google.com Fri Apr 19 17:49:59 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 19 Apr 2019 12:49:59 -0500 Subject: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException In-Reply-To: <5CBA001B.3070608@oracle.com> References: <5CBA001B.3070608@oracle.com> Message-ID: Hi Gary, Looks good to me :-) Jc On Fri, Apr 19, 2019 at 12:06 PM Gary Adams wrote: > Prevent the debuggee from exiting too quickly by > holding it at the breakpoint until the end of processing > flag has been read by the main thread from the debugger process. > > Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8222741 > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Apr 19 17:58:17 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 19 Apr 2019 10:58:17 -0700 Subject: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException In-Reply-To: <5CBA001B.3070608@oracle.com> References: <5CBA001B.3070608@oracle.com> Message-ID: Hi Gary, Can you add the backtrace of the exception to the CR. It will make it a bit easier to understand when/why this bug is happening. If I understand correctly, the second time through the loop the debuggee should be at a breakpoint, but we do the vm.resume() before we check for the breakpoint event, and this sometimes leads to the debuggee exiting before the call to eventIterator.nextEvent(), and this is where the exception occurs. Also, I assume with the old implementation that the vm.resume() done at lines 321 or 329 actually is not doing anything on the 2nd and subsequent iterations since the debuggee is already resumed by the resume() at the top of the loop. With your fix, they now are providing a needed resume(). If my understanding is correct, then your fix looks good. thanks, Chris On 4/19/19 10:06 AM, Gary Adams wrote: > Prevent the debuggee from exiting too quickly by > holding it at the breakpoint until the end of processing > flag has been read by the main thread from the debugger process. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8222741 From gary.adams at oracle.com Fri Apr 19 18:24:10 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 19 Apr 2019 14:24:10 -0400 Subject: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException In-Reply-To: References: <5CBA001B.3070608@oracle.com> Message-ID: <5CBA124A.4010102@oracle.com> From the CR : --> debugger: -----t2: method 'run' exit Thead2 from the debugger process has completed. remove004.java:531 debugee.stderr> **> debuggee: after: Thread.sleep Debuggee process has completed the sleep operation. remove004a.java:113 --> debugger: breakpointForCommunication Debugger main thread has passed the breakpoint event check. remove004.java:315 breakpointForCommunication:479 remove004a.java:120 methodForCommunication Since VMDisconnectedException is a RunTimeException, it may have been thrown during the breakpointForCommunication processing or in the debuggeeClass.getValue field lookup. # ERROR: ##> debugger: ERROR: VMDisconnectedException : com.sun.jdi.VMDisconnectedException The following stacktrace is for failure analysis. nsk.share.TestFailure: ##> debugger: ERROR: VMDisconnectedException : com.sun.jdi.VMDisconnectedException at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428) at nsk.share.Log.complain(Log.java:399) at nsk.jdi.EventQueue.remove.remove004.log3(remove004.java:120) at nsk.jdi.EventQueue.remove.remove004.runTest(remove004.java:262) at nsk.jdi.EventQueue.remove.remove004.runThis(remove004.java:195) at nsk.jdi.EventQueue.remove.remove004.run(remove004.java:101) The VMDisconnectedException is caught in runTest:262 which was processing the testRun:252 steps where the proposed change would be placed. If the failure was detected in the final steps confirming the VMDeathEvent, then we would have seen the log message at remove004.java:254. On 4/19/19, 1:58 PM, Chris Plummer wrote: > Hi Gary, > > Can you add the backtrace of the exception to the CR. It will make it > a bit easier to understand when/why this bug is happening. > > If I understand correctly, the second time through the loop the > debuggee should be at a breakpoint, but we do the vm.resume() before > we check for the breakpoint event, and this sometimes leads to the > debuggee exiting before the call to eventIterator.nextEvent(), and > this is where the exception occurs. > > Also, I assume with the old implementation that the vm.resume() done > at lines 321 or 329 actually is not doing anything on the 2nd and > subsequent iterations since the debuggee is already resumed by the > resume() at the top of the loop. With your fix, they now are providing > a needed resume(). > > If my understanding is correct, then your fix looks good. > > thanks, > > Chris > > On 4/19/19 10:06 AM, Gary Adams wrote: >> Prevent the debuggee from exiting too quickly by >> holding it at the breakpoint until the end of processing >> flag has been read by the main thread from the debugger process. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8222741 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Fri Apr 19 18:23:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 19 Apr 2019 20:23:51 +0200 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> Message-ID: Hi JC, not sure if that helps, but we set - originally for debugging purposes - the thread name for platforms where that is possible. This is what you see in gdb when listing threads. On POSIX platforms this means we call some form of pthread_setname_np(), which can be queried from the outside with pthread_getname_np(). See os::set_native_thread_name(). Feels a bit wrong to rely on this though, but maybe it helps. Cheers, Thomas On Fri, Apr 19, 2019 at 4:30 PM Jean Christophe Beyler wrote: > Problem is that if I don't have a jthread, I can't get the name it seems. > Perhaps it could help if I gave more information: > > - In our JVM profiling mechanism, we have a SIGPROF (and maybe that's a > wrong approach :-)) that gets cycled across threads (some Java threads, > some are the other threads) > - It is the other threads that I'm interested here to be able to > distinguish what they are in terms of of profiles > > Is there any way we could provide that (not in JVMTI then)? > - The only way I could imagine perhaps doing this would be perhaps to > have a set of other tools at the same time running (either using beans > before/after or JFR) but this seems crude as well (better than nothing > though) > - I wish there was a way to just be able to get a type for those > internal frames while doing the actual SIGPROF handling > > FWIW, the method we expose basically is like this: > Thread* current_thread = ThreadLocalStorage::get_thread_async_safe(); > if (current_thread == NULL) { > return -1; > } else if (current_thread->is_Compiler_thread()) { > return _activity_compile; > } else if (current_thread->is_Java_thread()) { > return -1; > } else if (current_thread->is_GC_task_thread()) { > return _activity_gc; > } else if (current_thread->is_VM_thread()) { > VMThread* vm_thread = (VMThread*) current_thread; > VM_Operation* vm_op = vm_thread->vm_operation(); > if (vm_op != NULL) { > switch (vm_op->type()) { > case VM_Operation::VMOp_GC_HeapInspection: > case VM_Operation::VMOp_GenCollectFull: > case VM_Operation::VMOp_GenCollectFullConcurrent: > case VM_Operation::VMOp_GenCollectForAllocation: > case VM_Operation::VMOp_ParallelGCFailedAllocation: > case VM_Operation::VMOp_ParallelGCSystemGC: > case VM_Operation::VMOp_CGC_Operation: > case VM_Operation::VMOp_CMS_Initial_Mark: > case VM_Operation::VMOp_CMS_Final_Remark: > case VM_Operation::VMOp_G1CollectFull: > case VM_Operation::VMOp_G1CollectForAllocation: > case VM_Operation::VMOp_G1IncCollectionPause: > return _activity_gc; > default: > break; > } > } > } > return _activity_other_vm; > } > > It's crude but we believe it is effective to at least "bucketize" the > internals while doing our profiling. > > Thanks for your input, > Jc > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > wrote: > >> On 19/04/2019 00:12, David Holmes wrote: >> > >> > I think it would be difficult to put something like this in JVM TI >> > given that the use of threads within the JVM are purely an >> > implementation detail and not standardized in any way. And many of >> > those threads are hidden from JVM TI anyway. >> > >> > The names of threads are the normal way to see what "type" of thread >> > you're dealing with. >> Right, JVM TI only deals with "Java threads" (jthread object) and has no >> knowledge about other threads. It might be possible to use its extension >> mechanism to provide information about other threads but it wouldn't be >> interoperable with anything that use jtherad objects. >> >> -Alan >> > > > -- > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Fri Apr 19 18:25:51 2019 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 19 Apr 2019 20:25:51 +0200 Subject: Providing users with thread type In-Reply-To: (Jean Christophe Beyler's message of "Fri, 19 Apr 2019 09:30:23 -0500") References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> Message-ID: <87zholua1c.fsf@oldenburg2.str.redhat.com> * Jean Christophe Beyler: > Is there any way we could provide that (not in JVMTI then)? On Linux, you can get truncated thread names from /proc/PID/task/*/comm. Maybe that's sufficient for your needs? Thanks, Florian From chris.plummer at oracle.com Fri Apr 19 19:20:05 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 19 Apr 2019 12:20:05 -0700 Subject: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException In-Reply-To: <5CBA124A.4010102@oracle.com> References: <5CBA001B.3070608@oracle.com> <5CBA124A.4010102@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Apr 19 21:39:31 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 19 Apr 2019 16:39:31 -0500 Subject: Providing users with thread type In-Reply-To: <87zholua1c.fsf@oldenburg2.str.redhat.com> References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <87zholua1c.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian and Thomas, @ both: apparently our internal jobs have a tendency to rename threads so all the naming is out the window (it is not clear to me why this happens) It looks like IF I could get that fixed this might work but does seem a bit "hacky" at best, is there no good solution to put the code I pasted above somewhere so that we could call it at some point? I'm wondering if it would be just appropriate to maybe augment AsyncGetCallTrace (since we call that at the same time) and perhaps fill an extra type parameter... Something like: void AsyncGetCallTraceWithType(ASGCT_CallTrace *trace, jint depth, void* ucontext, ASGCT_ThreadType* thread_type) Or augment ASGCT_CallTrace with the extra information in there: typedef struct { JNIEnv *env_id; // Env where trace was recorded jint num_frames; // number of frames in this trace ASGCT_CallFrame *frames; // frames ASGCT_ThreadType thread_type; // type of event recorded: java, compiler, gc, vm } ASGCT_CallTrace; Any opinions? Thanks for your help, Jc On Fri, Apr 19, 2019 at 1:26 PM Florian Weimer wrote: > * Jean Christophe Beyler: > > > Is there any way we could provide that (not in JVMTI then)? > > On Linux, you can get truncated thread names from /proc/PID/task/*/comm. > Maybe that's sufficient for your needs? > > Thanks, > Florian > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Apr 19 23:49:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 20 Apr 2019 09:49:23 +1000 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> Message-ID: <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> Hi Jc, On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > Problem is that if I don't have a jthread, I can't get the name it > seems. Perhaps it could help if I gave more information: > > - In our JVM profiling mechanism, we have a SIGPROF (and maybe that's a > wrong approach :-)) that gets cycled across threads (some Java threads, > some are the other threads) > ? ?- It is the other threads that I'm interested here to be able to > distinguish what they are in terms of of profiles > > Is there any way we could provide? that (not in JVMTI then)? > ? ?- The only way I could imagine perhaps doing this would be perhaps > to have a set of other tools at the same time running (either using > beans before/after or JFR) but this seems crude as well (better than > nothing though) > ? ?- I wish there was a way to just be able to get a type for those > internal frames while doing the actual SIGPROF handling > > FWIW, the method we expose basically is like this: > ? ? Thread* current_thread = ThreadLocalStorage::get_thread_async_safe(); We have Thread::current_or_null_safe() for that. > ? ? if (current_thread == NULL) { > ? ? ? return -1; > ? ? } else if (current_thread->is_Compiler_thread()) { > ? ? ? return _activity_compile; > ? ? } else if (current_thread->is_Java_thread()) { > ? ? ? return -1; > ? ? } else if (current_thread->is_GC_task_thread()) { > ? ? ? return _activity_gc; > ? ? } else if (current_thread->is_VM_thread()) { > ? ? ? VMThread* vm_thread = (VMThread*) current_thread; > ? ? ? VM_Operation* vm_op = vm_thread->vm_operation(); > ? ? ? if (vm_op != NULL) { > ? ? ? ? switch (vm_op->type()) { > ? ? ? ? ? case VM_Operation::VMOp_GC_HeapInspection: > ? ? ? ? ? case VM_Operation::VMOp_GenCollectFull: > ? ? ? ? ? case VM_Operation::VMOp_GenCollectFullConcurrent: > ? ? ? ? ? case VM_Operation::VMOp_GenCollectForAllocation: > ? ? ? ? ? case VM_Operation::VMOp_ParallelGCFailedAllocation: > ? ? ? ? ? case VM_Operation::VMOp_ParallelGCSystemGC: > ? ? ? ? ? case VM_Operation::VMOp_CGC_Operation: > ? ? ? ? ? case VM_Operation::VMOp_CMS_Initial_Mark: > ? ? ? ? ? case VM_Operation::VMOp_CMS_Final_Remark: > ? ? ? ? ? case VM_Operation::VMOp_G1CollectFull: > ? ? ? ? ? case VM_Operation::VMOp_G1CollectForAllocation: > ? ? ? ? ? case VM_Operation::VMOp_G1IncCollectionPause: > ? ? ? ? ? ? return _activity_gc; > ? ? ? ? ? default: > ? ? ? ? ? ? break; > ? ? ? ? } > ? ? ? } > ? ? } > ? ? return _activity_other_vm; > } So it's not really the thread "type" but the logical "activity". For "type" you'd just need a query version of Thread::print_on_error (more or less). Not at all sure where you could put this - nor clear why you need to put it somewhere: isn't this just something executed by your SIGPROF handler? David > It's crude but we believe it is effective to at least "bucketize" the > internals while doing our profiling. > > Thanks for your input, > Jc > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > wrote: > > On 19/04/2019 00:12, David Holmes wrote: > > > > I think it would be difficult to put something like this in JVM TI > > given that the use of threads within the JVM are purely an > > implementation detail and not standardized in any way. And many of > > those threads are hidden from JVM TI anyway. > > > > The names of threads are the normal way to see what "type" of thread > > you're dealing with. > Right, JVM TI only deals with "Java threads" (jthread object) and > has no > knowledge about other threads. It might be possible to use its > extension > mechanism to provide information about other threads but it wouldn't be > interoperable with anything that use jtherad objects. > > -Alan > > > > -- > > Thanks, > Jc From jcbeyler at google.com Sat Apr 20 00:29:35 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 19 Apr 2019 19:29:35 -0500 Subject: Providing users with thread type In-Reply-To: <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> Message-ID: Hi David, On Fri, Apr 19, 2019 at 6:49 PM David Holmes wrote: > Hi Jc, > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > > Problem is that if I don't have a jthread, I can't get the name it > > seems. Perhaps it could help if I gave more information: > > > > - In our JVM profiling mechanism, we have a SIGPROF (and maybe that's a > > wrong approach :-)) that gets cycled across threads (some Java threads, > > some are the other threads) > > - It is the other threads that I'm interested here to be able to > > distinguish what they are in terms of of profiles > > > > Is there any way we could provide that (not in JVMTI then)? > > - The only way I could imagine perhaps doing this would be perhaps > > to have a set of other tools at the same time running (either using > > beans before/after or JFR) but this seems crude as well (better than > > nothing though) > > - I wish there was a way to just be able to get a type for those > > internal frames while doing the actual SIGPROF handling > > > > FWIW, the method we expose basically is like this: > > Thread* current_thread = > ThreadLocalStorage::get_thread_async_safe(); > > We have Thread::current_or_null_safe() for that. > A decade old code might have rotted a bit (or been wrong from the start), I'll change this internal code :) > > > if (current_thread == NULL) { > > return -1; > > } else if (current_thread->is_Compiler_thread()) { > > return _activity_compile; > > } else if (current_thread->is_Java_thread()) { > > return -1; > > } else if (current_thread->is_GC_task_thread()) { > > return _activity_gc; > > } else if (current_thread->is_VM_thread()) { > > VMThread* vm_thread = (VMThread*) current_thread; > > VM_Operation* vm_op = vm_thread->vm_operation(); > > if (vm_op != NULL) { > > switch (vm_op->type()) { > > case VM_Operation::VMOp_GC_HeapInspection: > > case VM_Operation::VMOp_GenCollectFull: > > case VM_Operation::VMOp_GenCollectFullConcurrent: > > case VM_Operation::VMOp_GenCollectForAllocation: > > case VM_Operation::VMOp_ParallelGCFailedAllocation: > > case VM_Operation::VMOp_ParallelGCSystemGC: > > case VM_Operation::VMOp_CGC_Operation: > > case VM_Operation::VMOp_CMS_Initial_Mark: > > case VM_Operation::VMOp_CMS_Final_Remark: > > case VM_Operation::VMOp_G1CollectFull: > > case VM_Operation::VMOp_G1CollectForAllocation: > > case VM_Operation::VMOp_G1IncCollectionPause: > > return _activity_gc; > > default: > > break; > > } > > } > > } > > return _activity_other_vm; > > } > > So it's not really the thread "type" but the logical "activity". For > "type" you'd just need a query version of Thread::print_on_error (more > or less). > Not at all sure where you could put this - nor clear why you need to put > it somewhere: isn't this just something executed by your SIGPROF handler? > Well problem is that I'm not in the JVM at the sigprof handler level. I'm actually in the agent, so basically from the agent's point of view, I don't really know what "Activity" I just stopped but would love to know. We added internally this change to figure it out but I'd like to get it in the open-source so that all could use it and not just us internally. Basically, like I said ,when using open-source profilers, this would help divide up the "libjvm.so" bucket that a lot of profilers are getting. Thanks for your insight as always, Jc > David > > > It's crude but we believe it is effective to at least "bucketize" the > > internals while doing our profiling. > > > > Thanks for your input, > > Jc > > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > > wrote: > > > > On 19/04/2019 00:12, David Holmes wrote: > > > > > > I think it would be difficult to put something like this in JVM TI > > > given that the use of threads within the JVM are purely an > > > implementation detail and not standardized in any way. And many of > > > those threads are hidden from JVM TI anyway. > > > > > > The names of threads are the normal way to see what "type" of > thread > > > you're dealing with. > > Right, JVM TI only deals with "Java threads" (jthread object) and > > has no > > knowledge about other threads. It might be possible to use its > > extension > > mechanism to provide information about other threads but it wouldn't > be > > interoperable with anything that use jtherad objects. > > > > -Alan > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Apr 20 05:19:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 20 Apr 2019 15:19:57 +1000 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> Message-ID: On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: > Hi David, > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes > wrote: > > Hi Jc, > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > > Problem is that if I don't have a jthread, I can't get the name it > > seems. Perhaps it could help if I gave more information: > > > > - In our JVM profiling mechanism, we have a SIGPROF (and maybe > that's a > > wrong approach :-)) that gets cycled across threads (some Java > threads, > > some are the other threads) > >? ? ?- It is the other threads that I'm interested here to be able to > > distinguish what they are in terms of of profiles > > > > Is there any way we could provide? that (not in JVMTI then)? > >? ? ?- The only way I could imagine perhaps doing this would be > perhaps > > to have a set of other tools at the same time running (either using > > beans before/after or JFR) but this seems crude as well (better than > > nothing though) > >? ? ?- I wish there was a way to just be able to get a type for those > > internal frames while doing the actual SIGPROF handling > > > > FWIW, the method we expose basically is like this: > >? ? ? Thread* current_thread = > ThreadLocalStorage::get_thread_async_safe(); > > We have Thread::current_or_null_safe() for that. > > > A decade old code might have rotted a bit (or been wrong from the > start), I'll change this internal code :) > > > >? ? ? if (current_thread == NULL) { > >? ? ? ? return -1; > >? ? ? } else if (current_thread->is_Compiler_thread()) { > >? ? ? ? return _activity_compile; > >? ? ? } else if (current_thread->is_Java_thread()) { > >? ? ? ? return -1; > >? ? ? } else if (current_thread->is_GC_task_thread()) { > >? ? ? ? return _activity_gc; > >? ? ? } else if (current_thread->is_VM_thread()) { > >? ? ? ? VMThread* vm_thread = (VMThread*) current_thread; > >? ? ? ? VM_Operation* vm_op = vm_thread->vm_operation(); > >? ? ? ? if (vm_op != NULL) { > >? ? ? ? ? switch (vm_op->type()) { > >? ? ? ? ? ? case VM_Operation::VMOp_GC_HeapInspection: > >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectFull: > >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectFullConcurrent: > >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectForAllocation: > >? ? ? ? ? ? case VM_Operation::VMOp_ParallelGCFailedAllocation: > >? ? ? ? ? ? case VM_Operation::VMOp_ParallelGCSystemGC: > >? ? ? ? ? ? case VM_Operation::VMOp_CGC_Operation: > >? ? ? ? ? ? case VM_Operation::VMOp_CMS_Initial_Mark: > >? ? ? ? ? ? case VM_Operation::VMOp_CMS_Final_Remark: > >? ? ? ? ? ? case VM_Operation::VMOp_G1CollectFull: > >? ? ? ? ? ? case VM_Operation::VMOp_G1CollectForAllocation: > >? ? ? ? ? ? case VM_Operation::VMOp_G1IncCollectionPause: > >? ? ? ? ? ? ? return _activity_gc; > >? ? ? ? ? ? default: > >? ? ? ? ? ? ? break; > >? ? ? ? ? } > >? ? ? ? } > >? ? ? } > >? ? ? return _activity_other_vm; > > } > > So it's not really the thread "type" but the logical "activity". For > "type" you'd just need a query version of Thread::print_on_error (more > or less). > > > Not at all sure where you could put this - nor clear why you need to > put > it somewhere: isn't this just something executed by your SIGPROF > handler? > > > Well problem is that I'm not in the JVM at the sigprof handler level. > I'm actually in the agent, Not sure what you mean. I'm assuming you're sending a SIGPROF to each thread and using the handler for profiling - no? Otherwise please clarify what is happening in each thread. > so basically from the agent's point of? view, > I don't really know what "Activity" I just stopped but would love to > know. We added internally this change to figure it out but I'd like to > get it in the open-source so that all could use it and not just us A "char* Thread::get_thread_type()" API might be useful (as I said a query version of print_on_error(). But otherwise this seems something peculiar to your agent so simply composing existing API calls - as you outline - seems the appropriate way to deal with this. Seems to me the VMThread is the problem here because you want to try and attribute the VM_operation to different "buckets". But given the bulk of the work is actually done by other threads (e.g. GC), and going forward less and less will be done by the VMThread itself (e.g. async monitor deflation), is it really worth trying to classify this at a finer level than just "in the VM"? Cheers, David > internally. Basically, like I said ,when using open-source profilers, > this would help divide up the "libjvm.so" bucket that a lot of profilers > are getting. > Thanks for your insight as always, > Jc > > > > David > > > It's crude but we believe it is effective to at least "bucketize" > the > > internals while doing our profiling. > > > > Thanks for your input, > > Jc > > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > > > >> wrote: > > > >? ? ?On 19/04/2019 00:12, David Holmes wrote: > >? ? ? > > >? ? ? > I think it would be difficult to put something like this > in JVM TI > >? ? ? > given that the use of threads within the JVM are purely an > >? ? ? > implementation detail and not standardized in any way. And > many of > >? ? ? > those threads are hidden from JVM TI anyway. > >? ? ? > > >? ? ? > The names of threads are the normal way to see what "type" > of thread > >? ? ? > you're dealing with. > >? ? ?Right, JVM TI only deals with "Java threads" (jthread object) and > >? ? ?has no > >? ? ?knowledge about other threads. It might be possible to use its > >? ? ?extension > >? ? ?mechanism to provide information about other threads but it > wouldn't be > >? ? ?interoperable with anything that use jtherad objects. > > > >? ? ?-Alan > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From daniel.daugherty at oracle.com Sat Apr 20 18:29:40 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 20 Apr 2019 14:29:40 -0400 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: On 4/16/19 5:40 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix of: > https://bugs.openjdk.java.net/browse/JDK-8192936 > > > Webrev (fix from Coleen): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ src/hotspot/share/prims/jvmtiRedefineClasses.cpp ??? No comments. src/hotspot/share/runtime/arguments.cpp ??? No comments. src/hotspot/share/runtime/globals.hpp ??? No comments. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDeleteJmethod.java test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java ??? No comments. test/jdk/com/sun/jdi/RedefineAddPrivateMethod.java ??? No comments. test/jdk/com/sun/jdi/lib/jdb/Debuggee.java ??? No comments. test/jdk/com/sun/jdi/lib/jdb/JdbTest.java ??? No comments. test/jdk/java/lang/instrument/RedefineAddDeleteMethod/DeleteMethodHandle/MethodHandleDeletedMethod.java test/jdk/java/lang/instrument/RedefineMethodAddInvoke.sh test/jdk/java/lang/instrument/RedefineMethodDelInvoke.sh test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh ??? No comments. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java ??? I like the new test! It gives me hope about converting ??? the old shell tests into java tests. Thumbs up! Update: I see the fix was already pushed. Sorry I didn't get to this review in time. Dan > > I've already reviewed and updated the webrev with my suggestions. > > > Reviewed and approved CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Summary: > ? The fix introduces new VM option > -XX:AllowRedefinitionToAddOrDeleteMethods > ? for compatibility with previous releases.New option enables old behavior > ? and allows the JVM TI RedefineClasses and RetransformClasses to > add/delete > ? private static and private final instance methods in the new class > versions. > ? Without this option the old behavior is disabled. > > ? New option is deprecated right away. > ? The plan is to keep this option for several releases to allow customers > ? (tool vendors) to remove dependency on old behavior from their tools. > > > Testing: > ? Added new test to verify that class redefinitions which add or > delete methods > ? return expected JVMTI error codes: > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > > ? Several jvmti, com/sun/jdi and java/lang/instrument tests which need > old behavior are updated to use new flag. > > ? Run locally on Linux-x64 the following test suites in release and > fastdebug mode: > - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ > ??? - vmTestbase_nsk_jvmti > ??? - vmTestbase_nsk_jdi > ??? - vmTestbase_nsk_jdb > ??? - vmTestbase_nsk_jdwp > ? ? - jdk_jdi > ??? - jdk_instrument > > ? Submission of corresponding mach5 jobs is in progress. > > Thanks, > Serguei > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Apr 20 20:47:42 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 20 Apr 2019 13:47:42 -0700 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: On 4/20/19 11:29, Daniel D. Daugherty wrote: > On 4/16/19 5:40 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix of: >> https://bugs.openjdk.java.net/browse/JDK-8192936 >> >> >> Webrev (fix from Coleen): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > ??? No comments. > > src/hotspot/share/runtime/arguments.cpp > ??? No comments. > > src/hotspot/share/runtime/globals.hpp > ??? No comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDeleteJmethod.java > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java > ??? No comments. > > test/jdk/com/sun/jdi/RedefineAddPrivateMethod.java > ??? No comments. > > test/jdk/com/sun/jdi/lib/jdb/Debuggee.java > ??? No comments. > > test/jdk/com/sun/jdi/lib/jdb/JdbTest.java > ??? No comments. > > test/jdk/java/lang/instrument/RedefineAddDeleteMethod/DeleteMethodHandle/MethodHandleDeletedMethod.java > test/jdk/java/lang/instrument/RedefineMethodAddInvoke.sh > test/jdk/java/lang/instrument/RedefineMethodDelInvoke.sh > test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh > ??? No comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > ??? I like the new test! It gives me hope about converting > ??? the old shell tests into java tests. > > Thumbs up! Thank you a lot for the review, Dan! > > Update: I see the fix was already pushed. Sorry I didn't get > to this review in time. No worry. It is is nice to get your thumbs up anyway! Also, I want to say that I extremely appreciate the help from number of HotSpot engineers: Coleen, David H. (especially, Coleen and David!), Karen, Alan, Mandy, Dan and V. Ivanov! We had several rounds of discussions on this issue. It is on our plans to make this analysis publicly available. Thanks! Serguei > > Dan > >> >> I've already reviewed and updated the webrev with my suggestions. >> >> >> Reviewed and approved CSR: >> https://bugs.openjdk.java.net/browse/JDK-8221528 >> >> >> Summary: >> ? The fix introduces new VM option >> -XX:AllowRedefinitionToAddOrDeleteMethods >> ? for compatibility with previous releases. New option enables old >> behavior >> ? and allows the JVM TI RedefineClasses and RetransformClasses to >> add/delete >> ? private static and private final instance methods in the new class >> versions. >> ? Without this option the old behavior is disabled. >> >> ? New option is deprecated right away. >> ? The plan is to keep this option for several releases to allow customers >> ? (tool vendors) to remove dependency on old behavior from their tools. >> >> >> Testing: >> ? Added new test to verify that class redefinitions which add or >> delete methods >> ? return expected JVMTI error codes: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> ? Several jvmti, com/sun/jdi and java/lang/instrument tests which >> need old behavior are updated to use new flag. >> >> ? Run locally on Linux-x64 the following test suites in release and >> fastdebug mode: >> ??? - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ >> ??? - vmTestbase_nsk_jvmti >> ??? - vmTestbase_nsk_jdi >> ??? - vmTestbase_nsk_jdb >> ??? - vmTestbase_nsk_jdwp >> ? ? - jdk_jdi >> ??? - jdk_instrument >> >> ? Submission of corresponding mach5 jobs is in progress. >> >> Thanks, >> Serguei >> > From jcbeyler at google.com Sat Apr 20 22:15:11 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Sat, 20 Apr 2019 17:15:11 -0500 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> Message-ID: Hi David, Hopefully this gives more details :) Basically, in the Java agent, we set up a SIGPROF handler and we get a handler call at a set frequency rate (generally the profiling is for 30 seconds). The thread that is doing the signal handler can be a thread from the JVM and as we have said in this thread, internal VM threads can't get a JNIEnv or are visible to JVMTI anyway so we can't really get the name. Our current implementation, when faced with a thread like that, calls a method like above that we added in the JVM to provide information about what type of work was being done so that when we provide our profiles, we can give that information to the user. However for agents that cannot use the modified JVM, we cannot provide this information it seems and basically we have to fallback to getting the PC and just attributing it to libjvm.so (see an example here https://github.com/GoogleCloudPlatform/cloud-profiler-java/blob/master/src/profiler.cc#L127 ) So basically, in cases where we are in a signal handler, where we are asynchronous and cannot do a lot, getting a side method to just say : "hey is this a compiler thread, is this a GC thread, etc." would actually be helpful information during profiling instead of the general "well this many threads were in libjvm.so but we don't know what was going on". I've thought about using some other information such as CompilationMXBean to try to assess what is going on during profiling but it seems hard to correctly attribute that back into the actual profiles and untangle the libjvm.so buccket. Hopefully this makes sense, Jc On Sat, Apr 20, 2019 at 12:20 AM David Holmes wrote: > On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: > > Hi David, > > > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes > > wrote: > > > > Hi Jc, > > > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > > > Problem is that if I don't have a jthread, I can't get the name it > > > seems. Perhaps it could help if I gave more information: > > > > > > - In our JVM profiling mechanism, we have a SIGPROF (and maybe > > that's a > > > wrong approach :-)) that gets cycled across threads (some Java > > threads, > > > some are the other threads) > > > - It is the other threads that I'm interested here to be able > to > > > distinguish what they are in terms of of profiles > > > > > > Is there any way we could provide that (not in JVMTI then)? > > > - The only way I could imagine perhaps doing this would be > > perhaps > > > to have a set of other tools at the same time running (either > using > > > beans before/after or JFR) but this seems crude as well (better > than > > > nothing though) > > > - I wish there was a way to just be able to get a type for > those > > > internal frames while doing the actual SIGPROF handling > > > > > > FWIW, the method we expose basically is like this: > > > Thread* current_thread = > > ThreadLocalStorage::get_thread_async_safe(); > > > > We have Thread::current_or_null_safe() for that. > > > > > > A decade old code might have rotted a bit (or been wrong from the > > start), I'll change this internal code :) > > > > > > > if (current_thread == NULL) { > > > return -1; > > > } else if (current_thread->is_Compiler_thread()) { > > > return _activity_compile; > > > } else if (current_thread->is_Java_thread()) { > > > return -1; > > > } else if (current_thread->is_GC_task_thread()) { > > > return _activity_gc; > > > } else if (current_thread->is_VM_thread()) { > > > VMThread* vm_thread = (VMThread*) current_thread; > > > VM_Operation* vm_op = vm_thread->vm_operation(); > > > if (vm_op != NULL) { > > > switch (vm_op->type()) { > > > case VM_Operation::VMOp_GC_HeapInspection: > > > case VM_Operation::VMOp_GenCollectFull: > > > case VM_Operation::VMOp_GenCollectFullConcurrent: > > > case VM_Operation::VMOp_GenCollectForAllocation: > > > case VM_Operation::VMOp_ParallelGCFailedAllocation: > > > case VM_Operation::VMOp_ParallelGCSystemGC: > > > case VM_Operation::VMOp_CGC_Operation: > > > case VM_Operation::VMOp_CMS_Initial_Mark: > > > case VM_Operation::VMOp_CMS_Final_Remark: > > > case VM_Operation::VMOp_G1CollectFull: > > > case VM_Operation::VMOp_G1CollectForAllocation: > > > case VM_Operation::VMOp_G1IncCollectionPause: > > > return _activity_gc; > > > default: > > > break; > > > } > > > } > > > } > > > return _activity_other_vm; > > > } > > > > So it's not really the thread "type" but the logical "activity". For > > "type" you'd just need a query version of Thread::print_on_error > (more > > or less). > > > > > > Not at all sure where you could put this - nor clear why you need to > > put > > it somewhere: isn't this just something executed by your SIGPROF > > handler? > > > > > > Well problem is that I'm not in the JVM at the sigprof handler level. > > I'm actually in the agent, > > Not sure what you mean. I'm assuming you're sending a SIGPROF to each > thread and using the handler for profiling - no? Otherwise please > clarify what is happening in each thread. > > > so basically from the agent's point of view, > > I don't really know what "Activity" I just stopped but would love to > > know. We added internally this change to figure it out but I'd like to > > get it in the open-source so that all could use it and not just us > > A "char* Thread::get_thread_type()" API might be useful (as I said a > query version of print_on_error(). But otherwise this seems something > peculiar to your agent so simply composing existing API calls - as you > outline - seems the appropriate way to deal with this. > > Seems to me the VMThread is the problem here because you want to try and > attribute the VM_operation to different "buckets". But given the bulk of > the work is actually done by other threads (e.g. GC), and going forward > less and less will be done by the VMThread itself (e.g. async monitor > deflation), is it really worth trying to classify this at a finer level > than just "in the VM"? > > Cheers, > David > > > internally. Basically, like I said ,when using open-source profilers, > > this would help divide up the "libjvm.so" bucket that a lot of profilers > > are getting. > > Thanks for your insight as always, > > Jc > > > > > > > > David > > > > > It's crude but we believe it is effective to at least "bucketize" > > the > > > internals while doing our profiling. > > > > > > Thanks for your input, > > > Jc > > > > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > > > > > > >> wrote: > > > > > > On 19/04/2019 00:12, David Holmes wrote: > > > > > > > > I think it would be difficult to put something like this > > in JVM TI > > > > given that the use of threads within the JVM are purely an > > > > implementation detail and not standardized in any way. And > > many of > > > > those threads are hidden from JVM TI anyway. > > > > > > > > The names of threads are the normal way to see what "type" > > of thread > > > > you're dealing with. > > > Right, JVM TI only deals with "Java threads" (jthread object) > and > > > has no > > > knowledge about other threads. It might be possible to use its > > > extension > > > mechanism to provide information about other threads but it > > wouldn't be > > > interoperable with anything that use jtherad objects. > > > > > > -Alan > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Apr 20 23:14:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 21 Apr 2019 09:14:16 +1000 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> Message-ID: <1e3359e6-f4c9-7dd9-dbd9-6136fdaaa63b@oracle.com> Hi Jc, On 21/04/2019 8:15 am, Jean Christophe Beyler wrote: > Hi David, > > Hopefully this gives more details :) > > Basically, in the Java agent, we set up a SIGPROF handler and we get a > handler call at a set frequency rate (generally the profiling is for 30 > seconds). The thread that is doing the signal handler can be a thread > from the JVM and as we have said in this thread, internal VM threads > can't get a JNIEnv or are visible to JVMTI anyway so we can't really get > the name. And yet ... > Our current implementation, when faced with a thread like that, calls a > method like above that we added in the JVM to provide information about > what type of work was being done so that when we provide our profiles, > we can give that information to the user. ... they can call this method you added to the JVM? How do they do that? And if they can do that why can't they get the name the same way? Or call any existing query methods to piece together the information? Cheers, David > However for agents that cannot use the modified JVM, we cannot provide > this information it seems and basically we have to fallback to getting > the PC and just attributing it to libjvm.so (see an example here > https://github.com/GoogleCloudPlatform/cloud-profiler-java/blob/master/src/profiler.cc#L127) > > So basically, in cases where we are in a signal handler, where we are > asynchronous and cannot do a lot, getting a side method to just say : > "hey is this a compiler thread, is this a GC thread, etc." would > actually be helpful information during profiling instead of the general > "well this many threads were in libjvm.so but we don't know what was > going on". > > I've thought about using some other information such as > CompilationMXBean to try to assess what is going on during profiling but > it seems hard to correctly attribute that back into the actual profiles > and untangle the libjvm.so buccket. > > Hopefully this makes sense, > Jc > > On Sat, Apr 20, 2019 at 12:20 AM David Holmes > wrote: > > On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: > > Hi David, > > > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > >? ? ? > Problem is that if I don't have a jthread, I can't get the > name it > >? ? ? > seems. Perhaps it could help if I gave more information: > >? ? ? > > >? ? ? > - In our JVM profiling mechanism, we have a SIGPROF (and maybe > >? ? ?that's a > >? ? ? > wrong approach :-)) that gets cycled across threads (some Java > >? ? ?threads, > >? ? ? > some are the other threads) > >? ? ? >? ? ?- It is the other threads that I'm interested here to > be able to > >? ? ? > distinguish what they are in terms of of profiles > >? ? ? > > >? ? ? > Is there any way we could provide? that (not in JVMTI then)? > >? ? ? >? ? ?- The only way I could imagine perhaps doing this would be > >? ? ?perhaps > >? ? ? > to have a set of other tools at the same time running > (either using > >? ? ? > beans before/after or JFR) but this seems crude as well > (better than > >? ? ? > nothing though) > >? ? ? >? ? ?- I wish there was a way to just be able to get a type > for those > >? ? ? > internal frames while doing the actual SIGPROF handling > >? ? ? > > >? ? ? > FWIW, the method we expose basically is like this: > >? ? ? >? ? ? Thread* current_thread = > >? ? ?ThreadLocalStorage::get_thread_async_safe(); > > > >? ? ?We have Thread::current_or_null_safe() for that. > > > > > > A decade old code might have rotted a bit (or been wrong from the > > start), I'll change this internal code :) > > > > > >? ? ? >? ? ? if (current_thread == NULL) { > >? ? ? >? ? ? ? return -1; > >? ? ? >? ? ? } else if (current_thread->is_Compiler_thread()) { > >? ? ? >? ? ? ? return _activity_compile; > >? ? ? >? ? ? } else if (current_thread->is_Java_thread()) { > >? ? ? >? ? ? ? return -1; > >? ? ? >? ? ? } else if (current_thread->is_GC_task_thread()) { > >? ? ? >? ? ? ? return _activity_gc; > >? ? ? >? ? ? } else if (current_thread->is_VM_thread()) { > >? ? ? >? ? ? ? VMThread* vm_thread = (VMThread*) current_thread; > >? ? ? >? ? ? ? VM_Operation* vm_op = vm_thread->vm_operation(); > >? ? ? >? ? ? ? if (vm_op != NULL) { > >? ? ? >? ? ? ? ? switch (vm_op->type()) { > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_GC_HeapInspection: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectFull: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectFullConcurrent: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_GenCollectForAllocation: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_ParallelGCFailedAllocation: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_ParallelGCSystemGC: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_CGC_Operation: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_CMS_Initial_Mark: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_CMS_Final_Remark: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_G1CollectFull: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_G1CollectForAllocation: > >? ? ? >? ? ? ? ? ? case VM_Operation::VMOp_G1IncCollectionPause: > >? ? ? >? ? ? ? ? ? ? return _activity_gc; > >? ? ? >? ? ? ? ? ? default: > >? ? ? >? ? ? ? ? ? ? break; > >? ? ? >? ? ? ? ? } > >? ? ? >? ? ? ? } > >? ? ? >? ? ? } > >? ? ? >? ? ? return _activity_other_vm; > >? ? ? > } > > > >? ? ?So it's not really the thread "type" but the logical > "activity". For > >? ? ?"type" you'd just need a query version of > Thread::print_on_error (more > >? ? ?or less). > > > > > >? ? ?Not at all sure where you could put this - nor clear why you > need to > >? ? ?put > >? ? ?it somewhere: isn't this just something executed by your SIGPROF > >? ? ?handler? > > > > > > Well problem is that I'm not in the JVM at the sigprof handler > level. > > I'm actually in the agent, > > Not sure what you mean. I'm assuming you're sending a SIGPROF to each > thread and using the handler for profiling - no? Otherwise please > clarify what is happening in each thread. > > > so basically from the agent's point of? view, > > I don't really know what "Activity" I just stopped but would love to > > know. We added internally this change to figure it out but I'd > like to > > get it in the open-source so that all could use it and not just us > > A "char* Thread::get_thread_type()" API might be useful (as I said a > query version of print_on_error(). But otherwise this seems something > peculiar to your agent so simply composing existing API calls - as you > outline - seems the appropriate way to deal with this. > > Seems to me the VMThread is the problem here because you want to try > and > attribute the VM_operation to different "buckets". But given the > bulk of > the work is actually done by other threads (e.g. GC), and going forward > less and less will be done by the VMThread itself (e.g. async monitor > deflation), is it really worth trying to classify this at a finer level > than just "in the VM"? > > Cheers, > David > > > internally. Basically, like I said ,when using open-source > profilers, > > this would help divide up the "libjvm.so" bucket that a lot of > profilers > > are getting. > > Thanks for your insight as always, > > Jc > > > > > > > >? ? ?David > > > >? ? ? > It's crude but we believe it is effective to at least > "bucketize" > >? ? ?the > >? ? ? > internals while doing our profiling. > >? ? ? > > >? ? ? > Thanks for your input, > >? ? ? > Jc > >? ? ? > > >? ? ? > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > >? ? ? > > > >? ? ? > > >? ? ? >>> wrote: > >? ? ? > > >? ? ? >? ? ?On 19/04/2019 00:12, David Holmes wrote: > >? ? ? >? ? ? > > >? ? ? >? ? ? > I think it would be difficult to put something like > this > >? ? ?in JVM TI > >? ? ? >? ? ? > given that the use of threads within the JVM are > purely an > >? ? ? >? ? ? > implementation detail and not standardized in any > way. And > >? ? ?many of > >? ? ? >? ? ? > those threads are hidden from JVM TI anyway. > >? ? ? >? ? ? > > >? ? ? >? ? ? > The names of threads are the normal way to see what > "type" > >? ? ?of thread > >? ? ? >? ? ? > you're dealing with. > >? ? ? >? ? ?Right, JVM TI only deals with "Java threads" (jthread > object) and > >? ? ? >? ? ?has no > >? ? ? >? ? ?knowledge about other threads. It might be possible to > use its > >? ? ? >? ? ?extension > >? ? ? >? ? ?mechanism to provide information about other threads > but it > >? ? ?wouldn't be > >? ? ? >? ? ?interoperable with anything that use jtherad objects. > >? ? ? > > >? ? ? >? ? ?-Alan > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > -- > >? ? ? > > >? ? ? > Thanks, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Sun Apr 21 01:00:37 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Sat, 20 Apr 2019 20:00:37 -0500 Subject: Providing users with thread type In-Reply-To: <1e3359e6-f4c9-7dd9-dbd9-6136fdaaa63b@oracle.com> References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> <1e3359e6-f4c9-7dd9-dbd9-6136fdaaa63b@oracle.com> Message-ID: Ahh there lies the problem of understanding then :) We can provide that for our users that can use a non-vanilla OpenJDK. Vanilla OpenJDK cannot use that kind of thing since there is no "C" style symbol you could dlsym to. I don't think there is a good mechanism to currently piece the information together using a vanilla OpenJDK. So this conversation is about providing a mechanism for all OpenJDK agent writers to figure this out, even if they had to jump through hoops. The pthread_getname_np would have been a good one presumably but it seems that a lot of systems just rename the native threads for some reason... Hence I was offering to either extend AsyncGetCallTrace method (or create a side-one) or extend the JVMPI_CallTrace structure. Either of these would allow profilers to gather this information on future vanilla OpenJDKs. If that makes sense, Jc On Sat, Apr 20, 2019 at 6:14 PM David Holmes wrote: > Hi Jc, > > On 21/04/2019 8:15 am, Jean Christophe Beyler wrote: > > Hi David, > > > > Hopefully this gives more details :) > > > > Basically, in the Java agent, we set up a SIGPROF handler and we get a > > handler call at a set frequency rate (generally the profiling is for 30 > > seconds). The thread that is doing the signal handler can be a thread > > from the JVM and as we have said in this thread, internal VM threads > > can't get a JNIEnv or are visible to JVMTI anyway so we can't really get > > the name. > > And yet ... > > > Our current implementation, when faced with a thread like that, calls a > > method like above that we added in the JVM to provide information about > > what type of work was being done so that when we provide our profiles, > > we can give that information to the user. > > ... they can call this method you added to the JVM? How do they do that? > And if they can do that why can't they get the name the same way? Or > call any existing query methods to piece together the information? > > Cheers, > David > > > However for agents that cannot use the modified JVM, we cannot provide > > this information it seems and basically we have to fallback to getting > > the PC and just attributing it to libjvm.so (see an example here > > > https://github.com/GoogleCloudPlatform/cloud-profiler-java/blob/master/src/profiler.cc#L127 > ) > > > > So basically, in cases where we are in a signal handler, where we are > > asynchronous and cannot do a lot, getting a side method to just say : > > "hey is this a compiler thread, is this a GC thread, etc." would > > actually be helpful information during profiling instead of the general > > "well this many threads were in libjvm.so but we don't know what was > > going on". > > > > I've thought about using some other information such as > > CompilationMXBean to try to assess what is going on during profiling but > > it seems hard to correctly attribute that back into the actual profiles > > and untangle the libjvm.so buccket. > > > > Hopefully this makes sense, > > Jc > > > > On Sat, Apr 20, 2019 at 12:20 AM David Holmes > > wrote: > > > > On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: > > > Hi David, > > > > > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes > > > > > > >> wrote: > > > > > > Hi Jc, > > > > > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: > > > > Problem is that if I don't have a jthread, I can't get the > > name it > > > > seems. Perhaps it could help if I gave more information: > > > > > > > > - In our JVM profiling mechanism, we have a SIGPROF (and > maybe > > > that's a > > > > wrong approach :-)) that gets cycled across threads (some > Java > > > threads, > > > > some are the other threads) > > > > - It is the other threads that I'm interested here to > > be able to > > > > distinguish what they are in terms of of profiles > > > > > > > > Is there any way we could provide that (not in JVMTI > then)? > > > > - The only way I could imagine perhaps doing this > would be > > > perhaps > > > > to have a set of other tools at the same time running > > (either using > > > > beans before/after or JFR) but this seems crude as well > > (better than > > > > nothing though) > > > > - I wish there was a way to just be able to get a type > > for those > > > > internal frames while doing the actual SIGPROF handling > > > > > > > > FWIW, the method we expose basically is like this: > > > > Thread* current_thread = > > > ThreadLocalStorage::get_thread_async_safe(); > > > > > > We have Thread::current_or_null_safe() for that. > > > > > > > > > A decade old code might have rotted a bit (or been wrong from the > > > start), I'll change this internal code :) > > > > > > > > > > if (current_thread == NULL) { > > > > return -1; > > > > } else if (current_thread->is_Compiler_thread()) { > > > > return _activity_compile; > > > > } else if (current_thread->is_Java_thread()) { > > > > return -1; > > > > } else if (current_thread->is_GC_task_thread()) { > > > > return _activity_gc; > > > > } else if (current_thread->is_VM_thread()) { > > > > VMThread* vm_thread = (VMThread*) current_thread; > > > > VM_Operation* vm_op = vm_thread->vm_operation(); > > > > if (vm_op != NULL) { > > > > switch (vm_op->type()) { > > > > case VM_Operation::VMOp_GC_HeapInspection: > > > > case VM_Operation::VMOp_GenCollectFull: > > > > case > VM_Operation::VMOp_GenCollectFullConcurrent: > > > > case VM_Operation::VMOp_GenCollectForAllocation: > > > > case > VM_Operation::VMOp_ParallelGCFailedAllocation: > > > > case VM_Operation::VMOp_ParallelGCSystemGC: > > > > case VM_Operation::VMOp_CGC_Operation: > > > > case VM_Operation::VMOp_CMS_Initial_Mark: > > > > case VM_Operation::VMOp_CMS_Final_Remark: > > > > case VM_Operation::VMOp_G1CollectFull: > > > > case VM_Operation::VMOp_G1CollectForAllocation: > > > > case VM_Operation::VMOp_G1IncCollectionPause: > > > > return _activity_gc; > > > > default: > > > > break; > > > > } > > > > } > > > > } > > > > return _activity_other_vm; > > > > } > > > > > > So it's not really the thread "type" but the logical > > "activity". For > > > "type" you'd just need a query version of > > Thread::print_on_error (more > > > or less). > > > > > > > > > Not at all sure where you could put this - nor clear why you > > need to > > > put > > > it somewhere: isn't this just something executed by your > SIGPROF > > > handler? > > > > > > > > > Well problem is that I'm not in the JVM at the sigprof handler > > level. > > > I'm actually in the agent, > > > > Not sure what you mean. I'm assuming you're sending a SIGPROF to each > > thread and using the handler for profiling - no? Otherwise please > > clarify what is happening in each thread. > > > > > so basically from the agent's point of view, > > > I don't really know what "Activity" I just stopped but would love > to > > > know. We added internally this change to figure it out but I'd > > like to > > > get it in the open-source so that all could use it and not just us > > > > A "char* Thread::get_thread_type()" API might be useful (as I said a > > query version of print_on_error(). But otherwise this seems something > > peculiar to your agent so simply composing existing API calls - as > you > > outline - seems the appropriate way to deal with this. > > > > Seems to me the VMThread is the problem here because you want to try > > and > > attribute the VM_operation to different "buckets". But given the > > bulk of > > the work is actually done by other threads (e.g. GC), and going > forward > > less and less will be done by the VMThread itself (e.g. async monitor > > deflation), is it really worth trying to classify this at a finer > level > > than just "in the VM"? > > > > Cheers, > > David > > > > > internally. Basically, like I said ,when using open-source > > profilers, > > > this would help divide up the "libjvm.so" bucket that a lot of > > profilers > > > are getting. > > > Thanks for your insight as always, > > > Jc > > > > > > > > > > > > David > > > > > > > It's crude but we believe it is effective to at least > > "bucketize" > > > the > > > > internals while doing our profiling. > > > > > > > > Thanks for your input, > > > > Jc > > > > > > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman > > > > > > > > > > > > > > > >>> wrote: > > > > > > > > On 19/04/2019 00:12, David Holmes wrote: > > > > > > > > > > I think it would be difficult to put something like > > this > > > in JVM TI > > > > > given that the use of threads within the JVM are > > purely an > > > > > implementation detail and not standardized in any > > way. And > > > many of > > > > > those threads are hidden from JVM TI anyway. > > > > > > > > > > The names of threads are the normal way to see what > > "type" > > > of thread > > > > > you're dealing with. > > > > Right, JVM TI only deals with "Java threads" (jthread > > object) and > > > > has no > > > > knowledge about other threads. It might be possible to > > use its > > > > extension > > > > mechanism to provide information about other threads > > but it > > > wouldn't be > > > > interoperable with anything that use jtherad objects. > > > > > > > > -Alan > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Sun Apr 21 06:25:14 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 21 Apr 2019 08:25:14 +0200 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> <1e3359e6-f4c9-7dd9-dbd9-6136fdaaa63b@oracle.com> Message-ID: On Sun, Apr 21, 2019 at 3:01 AM Jean Christophe Beyler wrote: > Ahh there lies the problem of understanding then :) > > We can provide that for our users that can use a non-vanilla OpenJDK. > Vanilla OpenJDK cannot use that kind of thing since there is no "C" style > symbol you could dlsym to. I don't think there is a good mechanism to > currently piece the information together using a vanilla OpenJDK. > > So this conversation is about providing a mechanism for all OpenJDK agent > writers to figure this out, even if they had to jump through hoops. The > pthread_getname_np would have been a good one presumably but it seems that > a lot of systems just rename the native threads for some reason... > I would like to understand this better. From user code, the way to rename a thread is to call pthread_setname_np on it, for which you need the pthread_t of the thread, and how would user code get that for a VM internal thread that never yields control to the outside world? Or do you think this renaming is done at kernel/libC level? Might also be that we have an error somewhere and do not always set the thread name. AFAIK we do not have tests for that, so that could bitrot. ..Thomas > > Hence I was offering to either extend AsyncGetCallTrace method (or create > a side-one) or extend the JVMPI_CallTrace structure. Either of these would > allow profilers to gather this information on future vanilla OpenJDKs. If > that makes sense, > Jc > > On Sat, Apr 20, 2019 at 6:14 PM David Holmes > wrote: > >> Hi Jc, >> >> On 21/04/2019 8:15 am, Jean Christophe Beyler wrote: >> > Hi David, >> > >> > Hopefully this gives more details :) >> > >> > Basically, in the Java agent, we set up a SIGPROF handler and we get a >> > handler call at a set frequency rate (generally the profiling is for 30 >> > seconds). The thread that is doing the signal handler can be a thread >> > from the JVM and as we have said in this thread, internal VM threads >> > can't get a JNIEnv or are visible to JVMTI anyway so we can't really >> get >> > the name. >> >> And yet ... >> >> > Our current implementation, when faced with a thread like that, calls a >> > method like above that we added in the JVM to provide information about >> > what type of work was being done so that when we provide our profiles, >> > we can give that information to the user. >> >> ... they can call this method you added to the JVM? How do they do that? >> And if they can do that why can't they get the name the same way? Or >> call any existing query methods to piece together the information? >> >> Cheers, >> David >> >> > However for agents that cannot use the modified JVM, we cannot provide >> > this information it seems and basically we have to fallback to getting >> > the PC and just attributing it to libjvm.so (see an example here >> > >> https://github.com/GoogleCloudPlatform/cloud-profiler-java/blob/master/src/profiler.cc#L127 >> ) >> > >> > So basically, in cases where we are in a signal handler, where we are >> > asynchronous and cannot do a lot, getting a side method to just say : >> > "hey is this a compiler thread, is this a GC thread, etc." would >> > actually be helpful information during profiling instead of the general >> > "well this many threads were in libjvm.so but we don't know what was >> > going on". >> > >> > I've thought about using some other information such as >> > CompilationMXBean to try to assess what is going on during profiling >> but >> > it seems hard to correctly attribute that back into the actual profiles >> > and untangle the libjvm.so buccket. >> > >> > Hopefully this makes sense, >> > Jc >> > >> > On Sat, Apr 20, 2019 at 12:20 AM David Holmes > > > wrote: >> > >> > On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: >> > > Hi David, >> > > >> > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes >> > >> > > > > >> wrote: >> > > >> > > Hi Jc, >> > > >> > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: >> > > > Problem is that if I don't have a jthread, I can't get the >> > name it >> > > > seems. Perhaps it could help if I gave more information: >> > > > >> > > > - In our JVM profiling mechanism, we have a SIGPROF (and >> maybe >> > > that's a >> > > > wrong approach :-)) that gets cycled across threads (some >> Java >> > > threads, >> > > > some are the other threads) >> > > > - It is the other threads that I'm interested here to >> > be able to >> > > > distinguish what they are in terms of of profiles >> > > > >> > > > Is there any way we could provide that (not in JVMTI >> then)? >> > > > - The only way I could imagine perhaps doing this >> would be >> > > perhaps >> > > > to have a set of other tools at the same time running >> > (either using >> > > > beans before/after or JFR) but this seems crude as well >> > (better than >> > > > nothing though) >> > > > - I wish there was a way to just be able to get a type >> > for those >> > > > internal frames while doing the actual SIGPROF handling >> > > > >> > > > FWIW, the method we expose basically is like this: >> > > > Thread* current_thread = >> > > ThreadLocalStorage::get_thread_async_safe(); >> > > >> > > We have Thread::current_or_null_safe() for that. >> > > >> > > >> > > A decade old code might have rotted a bit (or been wrong from the >> > > start), I'll change this internal code :) >> > > >> > > >> > > > if (current_thread == NULL) { >> > > > return -1; >> > > > } else if (current_thread->is_Compiler_thread()) { >> > > > return _activity_compile; >> > > > } else if (current_thread->is_Java_thread()) { >> > > > return -1; >> > > > } else if (current_thread->is_GC_task_thread()) { >> > > > return _activity_gc; >> > > > } else if (current_thread->is_VM_thread()) { >> > > > VMThread* vm_thread = (VMThread*) current_thread; >> > > > VM_Operation* vm_op = vm_thread->vm_operation(); >> > > > if (vm_op != NULL) { >> > > > switch (vm_op->type()) { >> > > > case VM_Operation::VMOp_GC_HeapInspection: >> > > > case VM_Operation::VMOp_GenCollectFull: >> > > > case >> VM_Operation::VMOp_GenCollectFullConcurrent: >> > > > case >> VM_Operation::VMOp_GenCollectForAllocation: >> > > > case >> VM_Operation::VMOp_ParallelGCFailedAllocation: >> > > > case VM_Operation::VMOp_ParallelGCSystemGC: >> > > > case VM_Operation::VMOp_CGC_Operation: >> > > > case VM_Operation::VMOp_CMS_Initial_Mark: >> > > > case VM_Operation::VMOp_CMS_Final_Remark: >> > > > case VM_Operation::VMOp_G1CollectFull: >> > > > case VM_Operation::VMOp_G1CollectForAllocation: >> > > > case VM_Operation::VMOp_G1IncCollectionPause: >> > > > return _activity_gc; >> > > > default: >> > > > break; >> > > > } >> > > > } >> > > > } >> > > > return _activity_other_vm; >> > > > } >> > > >> > > So it's not really the thread "type" but the logical >> > "activity". For >> > > "type" you'd just need a query version of >> > Thread::print_on_error (more >> > > or less). >> > > >> > > >> > > Not at all sure where you could put this - nor clear why you >> > need to >> > > put >> > > it somewhere: isn't this just something executed by your >> SIGPROF >> > > handler? >> > > >> > > >> > > Well problem is that I'm not in the JVM at the sigprof handler >> > level. >> > > I'm actually in the agent, >> > >> > Not sure what you mean. I'm assuming you're sending a SIGPROF to >> each >> > thread and using the handler for profiling - no? Otherwise please >> > clarify what is happening in each thread. >> > >> > > so basically from the agent's point of view, >> > > I don't really know what "Activity" I just stopped but would >> love to >> > > know. We added internally this change to figure it out but I'd >> > like to >> > > get it in the open-source so that all could use it and not just >> us >> > >> > A "char* Thread::get_thread_type()" API might be useful (as I said a >> > query version of print_on_error(). But otherwise this seems >> something >> > peculiar to your agent so simply composing existing API calls - as >> you >> > outline - seems the appropriate way to deal with this. >> > >> > Seems to me the VMThread is the problem here because you want to try >> > and >> > attribute the VM_operation to different "buckets". But given the >> > bulk of >> > the work is actually done by other threads (e.g. GC), and going >> forward >> > less and less will be done by the VMThread itself (e.g. async >> monitor >> > deflation), is it really worth trying to classify this at a finer >> level >> > than just "in the VM"? >> > >> > Cheers, >> > David >> > >> > > internally. Basically, like I said ,when using open-source >> > profilers, >> > > this would help divide up the "libjvm.so" bucket that a lot of >> > profilers >> > > are getting. >> > > Thanks for your insight as always, >> > > Jc >> > > >> > > >> > > >> > > David >> > > >> > > > It's crude but we believe it is effective to at least >> > "bucketize" >> > > the >> > > > internals while doing our profiling. >> > > > >> > > > Thanks for your input, >> > > > Jc >> > > > >> > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman >> > > >> > > >> > > > > > >> > > > > >>> wrote: >> > > > >> > > > On 19/04/2019 00:12, David Holmes wrote: >> > > > > >> > > > > I think it would be difficult to put something like >> > this >> > > in JVM TI >> > > > > given that the use of threads within the JVM are >> > purely an >> > > > > implementation detail and not standardized in any >> > way. And >> > > many of >> > > > > those threads are hidden from JVM TI anyway. >> > > > > >> > > > > The names of threads are the normal way to see what >> > "type" >> > > of thread >> > > > > you're dealing with. >> > > > Right, JVM TI only deals with "Java threads" (jthread >> > object) and >> > > > has no >> > > > knowledge about other threads. It might be possible to >> > use its >> > > > extension >> > > > mechanism to provide information about other threads >> > but it >> > > wouldn't be >> > > > interoperable with anything that use jtherad objects. >> > > > >> > > > -Alan >> > > > >> > > > >> > > > >> > > > -- >> > > > >> > > > Thanks, >> > > > Jc >> > > >> > > >> > > >> > > -- >> > > >> > > Thanks, >> > > Jc >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Mon Apr 22 02:05:39 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Mon, 22 Apr 2019 02:05:39 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> , Message-ID: <7c7f6ab507b0471baad13de89141c365@jd.com> Dear All, May I ask for more review of this webrev and CSR? Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ CSR: https://bugs.openjdk.java.net/browse/JDK-8222319. Thanks! Lin ________________________________________ From: ???? Sent: Monday, April 15, 2019 10:54 To: Jean Christophe Beyler Cc: ????; Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Jc, Thanks a lot for your suggestions, I have updated the CSR. Hi All, May I get more review about the webrev and CSR, Webrev: http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ CSR: https://bugs.openjdk.java.net/browse/JDK-8222319. BRs, Lin ?? 2019??4??13????????2:15??Jean Christophe Beyler > ?????? Hi Lin, You could state in the CSR: - That not using the new flags makes the system behave as before; so it is a nop if you don't use the new flags - What happens if the flags are passed negative values? - What happens if the flags are passed crazy big numbers? Finally, I'd put a link to the current webrev if someone wanted more information. Apart from that, it looks good to me (I might skip the diff as you put the output below) the text could just say: here is the new usage text (maxchunk and maxfilesize are new) Thanks, Jc On Wed, Apr 10, 2019 at 11:56 PM ???? > wrote: Dear All, I have created a CSR at https://bugs.openjdk.java.net/browse/JDK-8222319. May I ask your help to review it? Thanks! BRs, Lin ?? 2019??4??11????????11:22?????? > ?????? Sorry, it should be CSR ticket Thanks?? Lin ?? 2019??4??11????????11:16?????? > ?????? Also realized it requires a JCP ticket, I will create it. Cheers, Lin ?? 2019??4??11????????10:26?????? > ?????? Dear JC, Thanks so much, I suddenly realized your way is exactly what I want. And here is new wehbrev. http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ BRs, Lin ?? 2019??4??11????????4:40??Jean Christophe Beyler > ?????? Hi Lin, What I meant about the helper method was to not do this: + private static String add_option(String cmd, String opt) { + if (opt.equals("")) { + return cmd; + } + return cmd + opt + ","; + } + but to do this: + private static String add_option(String cmd, String opt) { + if (cmd.isEmpty()) { + return opt; + } + return cmd + "," + opt; + } + That way you only put the ',' when needed, Jc On Wed, Apr 10, 2019 at 5:33 AM ???? > wrote: Dear Jc, Thanks a lot for your comments, here is the refined webrev. May I ask your help to review again? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ BRs, Lin ?? 2019??4??4????????4:57??Jean Christophe Beyler > ?????? Hi Lin, Just a few nits to be honest: - http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html -> I don't think it's a good idea to just pass a char* and implicitly imagine it is 256 in length -> Should we not add that length as a parameter? btw, the test you have len > 255 is a bit too restrictive no? Technically you should wait until you find the last '/' and then test there no? (technically we could use strrchr, no?) http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html -> the adding of the "," seems a bit off; I think it would be smarter to just have a helper add_option to cmdline that checks if it is not empty, then add "," and the new option -> otherwise you always end the "," if there are more options even if you are ignoring them, no? Finally: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-" + subopt; for consistency with how you do it for "all", should this not be: } else if (subopt.equals("live")) { - liveopt = "-live"; + // Add '-' for compatibility. + cmdline += "-live"; Thanks, Jc On Mon, Apr 1, 2019 at 5:18 AM ???? > wrote: Dear All?? Here I updated the latest changeset which did the following refine: * fixed the compatibility issues so that old version of jmap can work normally with latest changeset. * revised the code for parsing the jmap histo arguments. * revised the logic for incremental dumping of jmap histo. The main change of this webrev is making all arguments passed to virtual machine as one line. So there is no need to care about the max argument count limitation. And hence resolved the compatibility issues as discussed in http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html May I ask your help to review? http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ BRs, Lin ?? 2019??2??26????????10:50?????? > ?????? Dear All, I have revised the webrev at http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/. May I ask your help for reviewing? Thanks BRs, Lin -----Original Message----- From: ???? Sent: Friday, January 25, 2019 9:01 AM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ???? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ???? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul >; serviceability- dev at openjdk.java.net; ???? > Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ??IncrementalFile=??,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ??out??. What do you think? Thanks, Lin From: ???? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >>; serviceability- dev at openjdk.java.net> Subject: ????: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ??????: Hohensee, Paul >> ????????: 2019??1??1?? 4:56 ??????: ????; serviceability-dev at openjdk.java.net dev at openjdk.java.net> ????: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won??t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ??incremental?? could become ??chunkcount=??, where defaults to infinity (max value of size_t). I??d not use a default file name when ??chunkcount?? is specified, I??d just write to whatever the output stream is. ??chunkcount?? is then independent of ??file??. I??d add another histo argument for the maximum file size, call it ??maxfilesize??, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ??incremental?? argument as syntactic sugar for ??chunkcount=8k,maxfilesize=5m??. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ??const int?? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev bounces at openjdk.java.net>> on behalf of ???? >> Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net dev at openjdk.java.net>" >> Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?Chisto. It adds the ??incremental?? arguments that allow jmap ?Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -- Thanks, Jc From coleen.phillimore at oracle.com Mon Apr 22 15:08:28 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 22 Apr 2019 11:08:28 -0400 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: <8dad4576-fc88-a7a0-004f-b9dfe14f2a18@oracle.com> On 4/20/19 4:47 PM, serguei.spitsyn at oracle.com wrote: > > On 4/20/19 11:29, Daniel D. Daugherty wrote: >> On 4/16/19 5:40 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix of: >>> https://bugs.openjdk.java.net/browse/JDK-8192936 >>> >>> >>> Webrev (fix from Coleen): >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ >>> >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> ??? No comments. >> >> src/hotspot/share/runtime/arguments.cpp >> ??? No comments. >> >> src/hotspot/share/runtime/globals.hpp >> ??? No comments. >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDeleteJmethod.java >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java >> >> ??? No comments. >> >> test/jdk/com/sun/jdi/RedefineAddPrivateMethod.java >> ??? No comments. >> >> test/jdk/com/sun/jdi/lib/jdb/Debuggee.java >> ??? No comments. >> >> test/jdk/com/sun/jdi/lib/jdb/JdbTest.java >> ??? No comments. >> >> test/jdk/java/lang/instrument/RedefineAddDeleteMethod/DeleteMethodHandle/MethodHandleDeletedMethod.java >> >> test/jdk/java/lang/instrument/RedefineMethodAddInvoke.sh >> test/jdk/java/lang/instrument/RedefineMethodDelInvoke.sh >> test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh >> ??? No comments. >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> ??? I like the new test! It gives me hope about converting >> ??? the old shell tests into java tests. Thank you for reviewing the test.? I'm glad you liked it. >> >> Thumbs up! > > Thank you a lot for the review, Dan! > >> >> Update: I see the fix was already pushed. Sorry I didn't get >> to this review in time. > > No worry. > It is is nice to get your thumbs up anyway! > > Also, I want to say that I extremely appreciate the help from number > of HotSpot engineers: > Coleen, David H. (especially, Coleen and David!), Karen, Alan, Mandy, > Dan and V. Ivanov! > We had several rounds of discussions on this issue. > It is on our plans to make this analysis publicly available. We should add the internal pages to the openjdk wiki here. https://wiki.openjdk.java.net/display/HotSpot/Serviceability Coleen > > Thanks! > Serguei > >> >> Dan >> >>> >>> I've already reviewed and updated the webrev with my suggestions. >>> >>> >>> Reviewed and approved CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8221528 >>> >>> >>> Summary: >>> ? The fix introduces new VM option >>> -XX:AllowRedefinitionToAddOrDeleteMethods >>> ? for compatibility with previous releases. New option enables old >>> behavior >>> ? and allows the JVM TI RedefineClasses and RetransformClasses to >>> add/delete >>> ? private static and private final instance methods in the new class >>> versions. >>> ? Without this option the old behavior is disabled. >>> >>> ? New option is deprecated right away. >>> ? The plan is to keep this option for several releases to allow >>> customers >>> ? (tool vendors) to remove dependency on old behavior from their tools. >>> >>> >>> Testing: >>> ? Added new test to verify that class redefinitions which add or >>> delete methods >>> ? return expected JVMTI error codes: >>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>> >>> >>> ? Several jvmti, com/sun/jdi and java/lang/instrument tests which >>> need old behavior are updated to use new flag. >>> >>> ? Run locally on Linux-x64 the following test suites in release and >>> fastdebug mode: >>> ??? - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ >>> ??? - vmTestbase_nsk_jvmti >>> ??? - vmTestbase_nsk_jdi >>> ??? - vmTestbase_nsk_jdb >>> ??? - vmTestbase_nsk_jdwp >>> ? ? - jdk_jdi >>> ??? - jdk_instrument >>> >>> ? Submission of corresponding mach5 jobs is in progress. >>> >>> Thanks, >>> Serguei >>> >> > From david.holmes at oracle.com Tue Apr 23 00:44:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Apr 2019 10:44:02 +1000 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: Hi Serguei, A belated LGTM - sorry I didn't get to this sooner. Three minor comments: 1. I would have suggested to add "(Deprecated)" to the description of the new flag in globals.hpp 2. The new flag should have been added to the deprecated VM options tests. 3. The new test should run in both a positive and negative mode so that it also checks that the new flag works. Thanks for taking care of this - it has been a hard slog. :) David ----- On 16/04/2019 7:40 pm, serguei.spitsyn at oracle.com wrote: > Please, review the fix of: > https://bugs.openjdk.java.net/browse/JDK-8192936 > > > Webrev (fix from Coleen): > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ > > I've already reviewed and updated the webrev with my suggestions. > > > Reviewed and approved CSR: > https://bugs.openjdk.java.net/browse/JDK-8221528 > > > Summary: > ? The fix introduces new VM option > -XX:AllowRedefinitionToAddOrDeleteMethods > ? for compatibility with previous releases.New option enables old behavior > ? and allows the JVM TI RedefineClasses and RetransformClasses to > add/delete > ? private static and private final instance methods in the new class > versions. > ? Without this option the old behavior is disabled. > > ? New option is deprecated right away. > ? The plan is to keep this option for several releases to allow customers > ? (tool vendors) to remove dependency on old behavior from their tools. > > > Testing: > ? Added new test to verify that class redefinitions which add or delete > methods > ? return expected JVMTI error codes: > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java > > ? Several jvmti, com/sun/jdi and java/lang/instrument tests which need > old behavior are updated to use new flag. > > ? Run locally on Linux-x64 the following test suites in release and > fastdebug mode: > - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ > ??? - vmTestbase_nsk_jvmti > ??? - vmTestbase_nsk_jdi > ??? - vmTestbase_nsk_jdb > ??? - vmTestbase_nsk_jdwp > ? ? - jdk_jdi > ??? - jdk_instrument > > ? Submission of corresponding mach5 jobs is in progress. > > Thanks, > Serguei > From serguei.spitsyn at oracle.com Tue Apr 23 09:28:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Apr 2019 02:28:27 -0700 Subject: RFR(S): 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition In-Reply-To: References: Message-ID: <97fcebc4-01fb-72c0-3334-5a4e73d91018@oracle.com> Hi David, Thank you a lot for review! All suggestions are good. I'll file new bug to cover them. Thanks, Serguei On 4/22/19 17:44, David Holmes wrote: > Hi Serguei, > > A belated LGTM - sorry I didn't get to this sooner. > > Three minor comments: > > 1. I would have suggested to add "(Deprecated)" to the description of > the new flag in globals.hpp > > 2. The new flag should have been added to the deprecated VM options > tests. > > 3. The new test should run in both a positive and negative mode so > that it also checks that the new flag works. > > Thanks for taking care of this - it has been a hard slog. :) > > David > ----- > > On 16/04/2019 7:40 pm, serguei.spitsyn at oracle.com wrote: >> Please, review the fix of: >> https://bugs.openjdk.java.net/browse/JDK-8192936 >> >> >> Webrev (fix from Coleen): >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8192936-redef-add-delete.1/ >> >> >> I've already reviewed and updated the webrev with my suggestions. >> >> >> Reviewed and approved CSR: >> https://bugs.openjdk.java.net/browse/JDK-8221528 >> >> >> Summary: >> ?? The fix introduces new VM option >> -XX:AllowRedefinitionToAddOrDeleteMethods >> ?? for compatibility with previous releases.New option enables old >> behavior >> ?? and allows the JVM TI RedefineClasses and RetransformClasses to >> add/delete >> ?? private static and private final instance methods in the new class >> versions. >> ?? Without this option the old behavior is disabled. >> >> ?? New option is deprecated right away. >> ?? The plan is to keep this option for several releases to allow >> customers >> ?? (tool vendors) to remove dependency on old behavior from their tools. >> >> >> Testing: >> ?? Added new test to verify that class redefinitions which add or >> delete methods >> ?? return expected JVMTI error codes: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> >> ?? Several jvmti, com/sun/jdi and java/lang/instrument tests which >> need old behavior are updated to use new flag. >> >> ?? Run locally on Linux-x64 the following test suites in release and >> fastdebug mode: >> - open/test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ >> ???? - vmTestbase_nsk_jvmti >> ???? - vmTestbase_nsk_jdi >> ???? - vmTestbase_nsk_jdb >> ???? - vmTestbase_nsk_jdwp >> ?? ? - jdk_jdi >> ???? - jdk_instrument >> >> ?? Submission of corresponding mach5 jobs is in progress. >> >> Thanks, >> Serguei >> From alexey.menkov at oracle.com Tue Apr 23 23:35:44 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 23 Apr 2019 16:35:44 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> Message-ID: Hi Serguei, updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ Fixed everything except #7 (for consistency - in the file if function arguments spread on several lines, opening curly bracket is placed to separate line to separate function declaration from the function body). --alex On 04/12/2019 18:52, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Thank you for the update! > > One more round of minor formatting change requests for better > readability. :) > > #1: > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html > > +??????????????? port = Integer.decode(hostPort.substring(splitIndex+1)); > . . . > +??????????? } else if (hostPort.charAt(0) == ?[? && > hostPort.charAt(splitIndex-1) == ?]?) { > > ?Need spaces around ?+? and ?-? signs. > > #2: > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c.udiff.html > > +??????? //make the socket a dual mode socket > > ?missed space at the start of comment > > > Now, comments for: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html > > #3: > > 276???? /* check for host:port or port */ > 277???? colon = strrchr(address, ?:?); > 278???? port = (colon == NULL ? address : colon + 1); > > 279???? /* ensure the port is valid (getaddrinfo allows port to be empty) */ > 280???? if (getPortNumber(port) < 0) { > > #4: > > 298???????? hints.ai_family = allowOnlyIPv4 ? AF_INET : AF_INET6; > 299???????? hints.ai_flags |= AI_PASSIVE | (allowOnlyIPv4 ? 0 : > AI_V4MAPPED | AI_ALL); > 300???????? > 301???? } else { > > #5: Replace ?fills? with ?fills in? in: > > 341? * Parses address (IPv4 or IPv6), fills result by parsed address. > 383? * Parses prefix length from buffer (integer value), fills result > with corresponding net mask. > 485? * Parses ?allow? argument (fills list of allowed peers (global > _peers variable)). > > #6: > > 410???? // generate mask for prefix length > 411???? memset(result, 0, sizeof(*result)); > > 412???? // prefixLen <= 128, so we won?t go over result?s size > 413???? for (int i = 0; prefixLen > 0; i++, prefixLen -= :sunglasses: { > > #7: > > 623 socketTransport_startListening(jdwpTransportEnv* env, const char* > address, > 624??????????????????????????????? char** actualAddress) > 625 { > . . . . > 1173 static int readBooleanSysProp(int *result, int trueValue, int > falseValue, > 1174???? JNIEnv* jniEnv, jclass sysClass, jmethodID getPropMethod, const > char *propName) > 1175 { > > ?Move ?{? to the end of 624 and 1174. (edited) > > #8: > > 1176???? jstring value; > 1177???? jstring name = (*jniEnv)->NewStringUTF(jniEnv, propName); > > 1178???? if (name == NULL) { > . . . . > 1259???? } while (0); > > 1260???? if (jniEnv != NULL && (*jniEnv)->ExceptionCheck(jniEnv)) { > > > Thanks! > Serguei > > > On 4/12/19 4:58 PM, Alex Menkov wrote: >> updated webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.03/ >> >> changes (vs webrev.02) are non-functional (added/edited comments, code >> reformatting, renaming convertIpv4ToIpv6 function to >> convertIPv4ToIPv6, renaming env variable to jniEnv (env is already >> used in one of the functions)). >> >> About pass/preferredAddressFamily conditions - there is no "logical >> xor" in C/C++. Also I think that the current condition is clearer. >> >> --alex >> >> On 04/11/2019 17:18, serguei.spitsyn at oracle.com wrote: >>> Hi Alex, >>> >>> Great debugging feature! >>> While I'm still reading all the details, could you, please, fix some >>> minor format issues? >>> >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketTransportService.java.udiff.html >>> >>> >>> + * If host is a literal IPv6 address, it may be in >>> square brackets. Extra space before "square". >>> >>> >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html >>> >>> >>> ??I'd suggest to unify comments before functions: >>> ?? - start comment with a capital latter and ended with a dot >>> ?? - use comment format like this: >>> ??? /* >>> ???? */ >>> >>> ??Examples of comments that need this change: >>> >>> 262 /* result must be release with dbgsysFreeAddrInfo */ => /* * >>> Result must be release with dbgsysFreeAddrInfo. ?*/ >>> >>> 325 // input is sockaddr just because all clients have it => >>> /* * Input is sockaddr just because all clients have it. */ >>> >>> 1129 /* reads boolean system value, >>> 1130 * sets *result to trueValue if the ptoperty is "true", >>> 1131 * to falseValue if the property if "false", >>> 1132 * doesn't change *result if the property is not set or failed to >>> read. >>> 1133 */ => /* * Read boolean system value andset result to: * - >>> trueValue if the property is "true" >>> * - falseValue if the property is "false" *?? * Return JNI_OK if >>> result is set, return JNI_ERR? otherwise. >>> */ >>> >>> ? . . . >>> >>> 293 * use IPv6 socket (to accept IPv6 and mapped Ipv4),... >>> 342 * (with AF_INET6 Ipv4 addresses are not parsed even with >>> AI_V4MAPPED and AI_ALL flags) ...345 hints.ai_family = AF_UNSPEC; // >>> IPv6 or mapped Ipv4 ... 360 } else { // Ipv4 address Replace Ipv4 >>> with IPv4 for unification with IPv6 >>> For unification replace: convertIpv4ToIpv6 => convertIPv4ToIPv6 >>> >>> 297 hints.ai_flags |= AI_PASSIVE >>> 298 | (allowOnlyIPv4 ? 0 : AI_V4MAPPED | AI_ALL); Better to have just >>> one line >>> >>> >>> 1135 JNIEnv* env, . . . 1165 JNIEnv* jniEnv = NULL; >>> >>> A suggestion is to use the same name for JNIEnv*: >>> >>> ?? 1135 JNIEnv* jni, . . . >>> ?? 1165 JNIEnv* jni = NULL; >>> >>> >>> ?? Reformat: >>> >>> 608 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 609 || >>> (pass == 1 && ai->ai_family != preferredAddressFamily)) and >>> >>> 828 if ((pass == 0 && ai->ai_family == preferredAddressFamily) 829 || >>> (pass == 1 && ai->ai_family != preferredAddressFamily)) => if ((pass >>> == 0 && ai->ai_family == preferredAddressFamily) || (pass == 1 && >>> ai->ai_family != preferredAddressFamily)) >>> >>> ?? Even better, replace it with logical XOR: >>> >>> ???????????? if ((pass == 0 ^^ ai->ai_family == preferredAddressFamily) >>> >>> >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/startListening/startlis001.java.frames.html >>> >>> >>> 102 /* Check that listening address returned by >>> ListeningConnector.startListening() >>> 103 * matches the address which was set via connector's arguments. >>> 104 * Empty host address causes listening for local connections only >>> (loopback interface) >>> 105 * */ Dot is missed at the end. Replace "* */" with "*/". >>> >>> >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/test/jdk/com/sun/jdi/JdwpAllowTest.java.frames.html >>> >>> >>> 162 // generate allow address by changing random bit in the local >>> address >>> 163 // and calculate 2 masks (prefix length) - one is matches >>> original local address >>> 164 // and another doesn't. Replace with /* style of comment. >>> >>> >>> 249 positiveTest("PositiveMaskTest(" + test.localAddress + ")", >>> test.allowAddress + "/" + test.prefixLengthGood); >>> 250 positiveTest("NegativeMaskTest(" + test.localAddress + ")", >>> test.allowAddress + "/" + test.prefixLengthBad); >>> >>> ?? A suggestion to move second argument to additional line: >>> >>> positiveTest("PositiveMaskTest(" + test.localAddress + ")", >>> test.allowAddress + "/" + test.prefixLengthGood); >>> positiveTest("NegativeMaskTest(" + test.localAddress + ")", >>> test.allowAddress + "/" + test.prefixLengthBad); >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/2/19 4:14 PM, Alex Menkov wrote: >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/ >>>> >>>> - added support for addresses enclosed in square brackets; >>>> - updated SocketTransportService.java to handle empty hostname the >>>> same way as JDWP agent (listen/attach to loopback address); >>>> Has to update >>>> nsk/jdi/ListeningConnector/startListening/startlis001.java >>>> (all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed). >>>> >>>> --alex >>>> >>>> On 04/01/2019 11:21, Alex Menkov wrote: >>>>> Hi Chris, >>>>> >>>>> On 04/01/2019 04:50, Chris Hegarty wrote: >>>>>> Alex, >>>>>> >>>>>> On 29/03/2019 22:07, Alex Menkov wrote: >>>>>>> (added net-dev as suggested by Alan) >>>>>>> >>>>>>> Net gurus, please assist in reviewing socket-related code. >>>>>>> >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/ >>>>>> >>>>>> Specifically on SocketTransportService.java. What Arthur has >>>>>> proposed is better ( changing to lastIndexOf alone is not >>>>>> sufficient ). Or is your assumption that the IPv6 literal is >>>>>> not enclosed in square brackets? >>>>> >>>>> I didn't know about enclosing IPv6 in square brackets, but looks >>>>> like that's standard way to alleviate conflict between IPv6 address >>>>> and colon as port separator. >>>>> Will update the fix to handle them in both JDI connectors >>>>> (SocketTransportService.java) and debugger agent (socketTransport.c) >>>>> >>>>>> >>>>>> If keeping Arthur's `static class HostPort` please make the >>>>>> fields final. >>>>>> >>>>>> ?>> Would it make sense to support the preference properties? >>>>>> ?>>??? java.net.preferIPv4Stack >>>>>> ?>>??? java.net.preferIPv6Addresses >>>>>> >>>>>> I'm not sure about this, especially given the property name >>>>>> prefixes. I need to think a little more on it. >>>>> >>>>> In the initial version of the fix I didn't check the properties. >>>>> The rationale here is backward compatibility - is address is empty, >>>>> old debuggers tries to connect to IPv4 address only. >>>>> But handling this properties we will better handle clients with >>>>> properties set (as jdb or any other debugger which uses JDI >>>>> connectors are affected by the properties). >>>>> >>>>> BTW fix provided by Arthur implements listening on localhost >>>>> differently - it creates several sockets and binds them to both >>>>> IPv4 and IPv6 addresses. But the problem here (and that's the >>>>> reason I decide to not implement it this way) - how to handle the >>>>> case when we successfully bind on one address (for example IPv4), >>>>> but fail to bind on other (for example the port is busy for IPv6 >>>>> stack). Arthur's version just fail in the case (i.e. the whole Java >>>>> process terminates) and I don't think this is good behavior. >>>>> >>>>> >>>>>> >>>>>> There is quite a bit of new native code, is it possible to >>>>>> rewrite any of this in Java, e.g. reading of the system >>>>>> properties ( if that is to remain )? >>>>> >>>>> socketTransport.c is a debugger agent which is completely native. >>>>> >>>>> --alex >>>>> >>>>>> >>>>>> -Chris. >>> > From jcbeyler at google.com Wed Apr 24 18:07:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 24 Apr 2019 11:07:19 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv Message-ID: Hi all, When pushing my fix for JDK-8213501, I did not push the added files which were the new test for the whole system. These were reviewed via the JDK-8213501 ( http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/) fix but I'm just asking for a review again to add this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 My apologies for this... This has been sent to the submit repo in parallel. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Apr 24 18:10:36 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 24 Apr 2019 11:10:36 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: LGTM --alex On 04/24/2019 11:07, Jean Christophe Beyler wrote: > Hi all, > > When pushing my fix for?JDK-8213501, I did not push the added files > which were the new test for the whole system. > > These were reviewed via the JDK-8213501 > (http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/) fix but I'm > just asking for a review again to add this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 > > My apologies for this... This has been sent to the submit repo in parallel. > > Thanks, > Jc From serguei.spitsyn at oracle.com Wed Apr 24 22:18:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Apr 2019 15:18:33 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated Message-ID: Please, review fix for: ? https://bugs.openjdk.java.net/browse/JDK-8222934 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ Summary: ? David, in review for https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: ?? 1. I would have suggested to add "(Deprecated)" to the description of the new flag in globals.hpp ?? 2. The new flag should have been added to the deprecated VM options tests. ?? 3. The new test should run in both a positive and negative mode so that it also checks that the new flag works. ? The webrev above implements this suggestion. Testing: ? In progress: Submit mach5 run for the updated tests. Thanks, Serguei From jcbeyler at google.com Wed Apr 24 23:42:54 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 24 Apr 2019 16:42:54 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: Hi all, Submit repo actually failed on the first version due to some loss of precision assignments. And also there was a slight bug in the exception messaging handling, so this is now fixed in the webrev: This version passes the test and the submit repo: Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 Thanks for your help, Jc On Wed, Apr 24, 2019 at 11:10 AM Alex Menkov wrote: > LGTM > > --alex > > On 04/24/2019 11:07, Jean Christophe Beyler wrote: > > Hi all, > > > > When pushing my fix for JDK-8213501, I did not push the added files > > which were the new test for the whole system. > > > > These were reviewed via the JDK-8213501 > > (http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/) fix but I'm > > just asking for a review again to add this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 > > > > My apologies for this... This has been sent to the submit repo in > parallel. > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 25 00:55:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Apr 2019 17:55:41 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: <1286878c-b04e-beb5-ecf1-63f3f335d15f@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Apr 25 01:14:37 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 24 Apr 2019 18:14:37 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Apr 25 02:53:24 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 24 Apr 2019 19:53:24 -0700 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: Thanks all, I fixed Serguei's issues and pushed it as it was apparently breaking tier5 testing. My sincere apologies again, Jc On Wed, Apr 24, 2019 at 6:16 PM Chris Plummer wrote: > Hi JC, > > Looks good. > > thanks, > > Chris > > On 4/24/19 4:42 PM, Jean Christophe Beyler wrote: > > Hi all, > > Submit repo actually failed on the first version due to some loss of > precision assignments. And also there was a slight bug in the exception > messaging handling, so this is now fixed in the webrev: > > This version passes the test and the submit repo: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 > > Thanks for your help, > Jc > > > On Wed, Apr 24, 2019 at 11:10 AM Alex Menkov > wrote: > >> LGTM >> >> --alex >> >> On 04/24/2019 11:07, Jean Christophe Beyler wrote: >> > Hi all, >> > >> > When pushing my fix for JDK-8213501, I did not push the added files >> > which were the new test for the whole system. >> > >> > These were reviewed via the JDK-8213501 >> > (http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/) fix but I'm >> > just asking for a review again to add this webrev: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.00/ >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 >> > >> > My apologies for this... This has been sent to the submit repo in >> parallel. >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Apr 25 08:36:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Apr 2019 18:36:06 +1000 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under JDK-8221503 which is now closed as a duplicate of JDK-8212117. So ProblemList.txt needs updating. Thanks, David ------ diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -159,7 +159,7 @@ vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all From gary.adams at oracle.com Thu Apr 25 12:07:31 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 25 Apr 2019 08:07:31 -0400 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: References: Message-ID: <5CC1A303.3040902@oracle.com> Looks OK to me. On 4/25/19, 4:36 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 > > vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under > JDK-8221503 which is now closed as a duplicate of JDK-8212117. So > ProblemList.txt needs updating. > > Thanks, > David > ------ > > diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -159,7 +159,7 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all > > vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all From daniel.daugherty at oracle.com Thu Apr 25 14:00:35 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 10:00:35 -0400 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: References: Message-ID: <1bb48a9c-849c-4691-84cb-26001c42f282@oracle.com> Thumbs up! Dan On 4/25/19 4:36 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 > > vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under > JDK-8221503 which is now closed as a duplicate of JDK-8212117. So > ProblemList.txt needs updating. > > Thanks, > David > ------ > > diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -159,7 +159,7 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all > > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all From serguei.spitsyn at oracle.com Thu Apr 25 17:41:08 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 10:41:08 -0700 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: References: Message-ID: <3a1c8f23-f79d-5360-ba0e-4eb7a698850f@oracle.com> Hi David, Looks good. Thank you for taking care about this! Thanks, Serguei On 4/25/19 01:36, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 > > vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under > JDK-8221503 which is now closed as a duplicate of JDK-8212117. So > ProblemList.txt needs updating. > > Thanks, > David > ------ > > diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -159,7 +159,7 @@ > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > > vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > > -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all > +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all > > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all From daniel.daugherty at oracle.com Thu Apr 25 19:40:44 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 15:40:44 -0400 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: Message-ID: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: > Please, review fix for: > ? https://bugs.openjdk.java.net/browse/JDK-8222934 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ > src/hotspot/share/runtime/globals.hpp ??? No comments. test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ??? L42: ??????? // deprecated class redefinition flags: ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, ??? L44: ??? L45: ??????? // deprecated non-alias flags: ??????? I think your new flag entry should have been added to the ??????? "deprecated non-alias flags" section. You don't need to ??????? call out that this is a "class redefinition" flag. ??????? The reason for the "// deprecated alias flags (see also aliased_jvm_flags):" ??????? section (below what you changed) is because there is more ??????? work to do for those flags. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java ??? L94: ??? public static String ADeleteStaticFoo = ??????? This case is deleting both "staticFoo" and "finalFoo". ??????? Is that what you really want? If so, then the test case ??????? is misnamed. ??? L119???? public static String BAddStaticBar = ??????? This case is added "staticBar" and "finalBar". Is that what ??????? you really want? If so, then the test case is misnamed. ??? Still a really cool test here! Thumbs up. Your call on whether to tweak the test. Dan > > > Summary: > ? David, in review for > https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: > ?? 1. I would have suggested to add "(Deprecated)" to the description > of the new flag in globals.hpp > ?? 2. The new flag should have been added to the deprecated VM options > tests. > ?? 3. The new test should run in both a positive and negative mode so > that it also checks that the new flag works. > > ? The webrev above implements this suggestion. > > > Testing: > ? In progress: Submit mach5 run for the updated tests. > > > Thanks, > Serguei > > > > From serguei.spitsyn at oracle.com Thu Apr 25 20:19:46 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 13:19:46 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu Apr 25 20:49:44 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 25 Apr 2019 16:49:44 -0400 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> Message-ID: <754312bc-1859-a59f-7214-310d82d33989@oracle.com> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot fore reviewing this! > > On 4/25/19 12:40, Daniel D. Daugherty wrote: >> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>> >> >> src/hotspot/share/runtime/globals.hpp >> ??? No comments. >> >> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >> ??? L42: ??????? // deprecated class redefinition flags: >> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >> ??? L44: >> ??? L45: ??????? // deprecated non-alias flags: >> ??????? I think your new flag entry should have been added to the >> ??????? "deprecated non-alias flags" section. You don't need to >> ??????? call out that this is a "class redefinition" flag. >> >> ??????? The reason for the "// deprecated alias flags (see also >> aliased_jvm_flags):" >> ??????? section (below what you changed) is because there is more >> ??????? work to do for those flags. > > Okay, I'm not very familiar with this test, will check how to change it. Check with David H. > >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> ??? L94: ??? public static String ADeleteStaticFoo = >> ??????? This case is deleting both "staticFoo" and "finalFoo". >> ??????? Is that what you really want? If so, then the test case >> ??????? is misnamed. > > I see your confusion here. > The ADeleteStaticFoo is used after the ADeleteFinalFoo. > So, the "finalFoo" has been already deleted before. > Then the ADeleteStaticFoo only deletes the "staticFoo". > > The same was not the case for ADeleteFinalFoo. > It is because the redefinitions with ADeleteFoo and ADeletePublicFoo > are expected to be rejected with UOE. > >> >> ??? L119???? public static String BAddStaticBar = >> ??????? This case is added "staticBar" and "finalBar". Is that what >> ??????? you really want? If so, then the test case is misnamed. > > This one is similar to the above. > The "finalBar" has already been added bythe BAddFinalBar redefinition. > > Please, let me know if you are Okay with it as it is or prefer to add > a comment with clarification. Short comments would be helpful here. > >> >> ??? Still a really cool test here! > > The test was initially written by Coleen (thanks, Coleen!) Yup! > I've spoiled it a little bit though. :) > >> >> Thumbs up. Your call on whether to tweak the test. > > I'll send a VMDeprecatedOptions related update later. Check with David H. Dan > > > Thanks! > Serguei >> >> Dan >> >> >>> >>> >>> Summary: >>> ? David, in review for >>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>> ?? 1. I would have suggested to add "(Deprecated)" to the >>> description of the new flag in globals.hpp >>> ?? 2. The new flag should have been added to the deprecated VM >>> options tests. >>> ?? 3. The new test should run in both a positive and negative mode >>> so that it also checks that the new flag works. >>> >>> ? The webrev above implements this suggestion. >>> >>> >>> Testing: >>> ? In progress: Submit mach5 run for the updated tests. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Thu Apr 25 21:18:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 25 Apr 2019 17:18:24 -0400 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> Message-ID: <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot fore reviewing this! > > On 4/25/19 12:40, Daniel D. Daugherty wrote: >> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>> >> >> src/hotspot/share/runtime/globals.hpp >> ??? No comments. >> >> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >> ??? L42: ??????? // deprecated class redefinition flags: >> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >> ??? L44: >> ??? L45: ??????? // deprecated non-alias flags: >> ??????? I think your new flag entry should have been added to the >> ??????? "deprecated non-alias flags" section. You don't need to >> ??????? call out that this is a "class redefinition" flag. >> >> ??????? The reason for the "// deprecated alias flags (see also >> aliased_jvm_flags):" >> ??????? section (below what you changed) is because there is more >> ??????? work to do for those flags. > > Okay, I'm not very familiar with this test, will check how to change it. > >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> >> ??? L94: ??? public static String ADeleteStaticFoo = >> ??????? This case is deleting both "staticFoo" and "finalFoo". >> ??????? Is that what you really want? If so, then the test case >> ??????? is misnamed. > > I see your confusion here. > The ADeleteStaticFoo is used after the ADeleteFinalFoo. > So, the "finalFoo" has been already deleted before. > Then the ADeleteStaticFoo only deletes the "staticFoo". > > The same was not the case for ADeleteFinalFoo. > It is because the redefinitions with ADeleteFoo and ADeletePublicFoo > are expected to be rejected with UOE. > >> >> ??? L119???? public static String BAddStaticBar = >> ??????? This case is added "staticBar" and "finalBar". Is that what >> ??????? you really want? If so, then the test case is misnamed. > > This one is similar to the above. > The "finalBar" has already been added bythe BAddFinalBar redefinition. > > Please, let me know if you are Okay with it as it is or prefer to add > a comment with clarification. > >> >> ??? Still a really cool test here! > > The test was initially written by Coleen (thanks, Coleen!) > I've spoiled it a little bit though. :) Hi Serguei,? You added a lot to it, which is taking me a while to understand. Why did you make class A inherit from Runnable? Can you maintain order of the function declarations? 78 public static String ADeletePublicFoo = finalFoo should be before staticFoo in this one. Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, finalFoo has already been deleted so you didn't want to also test adding it back. Thank you for enhancing the test.? I guess it's good that it tests the new option. Coleen > >> >> Thumbs up. Your call on whether to tweak the test. > > I'll send a VMDeprecatedOptions related update later. > > > Thanks! > Serguei >> >> Dan >> >> >>> >>> >>> Summary: >>> ? David, in review for >>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>> ?? 1. I would have suggested to add "(Deprecated)" to the >>> description of the new flag in globals.hpp >>> ?? 2. The new flag should have been added to the deprecated VM >>> options tests. >>> ?? 3. The new test should run in both a positive and negative mode >>> so that it also checks that the new flag works. >>> >>> ? The webrev above implements this suggestion. >>> >>> >>> Testing: >>> ? In progress: Submit mach5 run for the updated tests. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Apr 25 21:41:00 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 14:41:00 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> Message-ID: Hi Coleen, Thank you a lot for looking at this! On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: > > > On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> Thank you a lot fore reviewing this! >> >> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>> >>> >>> src/hotspot/share/runtime/globals.hpp >>> ??? No comments. >>> >>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>> ??? L42: ??????? // deprecated class redefinition flags: >>> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >>> ??? L44: >>> ??? L45: ??????? // deprecated non-alias flags: >>> ??????? I think your new flag entry should have been added to the >>> ??????? "deprecated non-alias flags" section. You don't need to >>> ??????? call out that this is a "class redefinition" flag. >>> >>> ??????? The reason for the "// deprecated alias flags (see also >>> aliased_jvm_flags):" >>> ??????? section (below what you changed) is because there is more >>> ??????? work to do for those flags. >> >> Okay, I'm not very familiar with this test, will check how to change it. >> >>> >>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>> >>> ??? L94: ??? public static String ADeleteStaticFoo = >>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>> ??????? Is that what you really want? If so, then the test case >>> ??????? is misnamed. >> >> I see your confusion here. >> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >> So, the "finalFoo" has been already deleted before. >> Then the ADeleteStaticFoo only deletes the "staticFoo". >> >> The same was not the case for ADeleteFinalFoo. >> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >> are expected to be rejected with UOE. >> >>> >>> ??? L119???? public static String BAddStaticBar = >>> ??????? This case is added "staticBar" and "finalBar". Is that what >>> ??????? you really want? If so, then the test case is misnamed. >> >> This one is similar to the above. >> The "finalBar" has already been added bythe BAddFinalBar redefinition. >> >> Please, let me know if you are Okay with it as it is or prefer to add >> a comment with clarification. >> >>> >>> ??? Still a really cool test here! >> >> The test was initially written by Coleen (thanks, Coleen!) >> I've spoiled it a little bit though. :) > > Hi Serguei,? You added a lot to it, which is taking me a while to > understand. > > Why did you make class A inherit from Runnable? In fact, nothing foxy. It implements Runnable, not inherits. :) There were two steps. First was to decide if we there is a point to call methods in the redefined classes A and B. You did it with the in the original test version but you made publicFoo to call others. So, I decided that it is useful to make sure the methods are executed well after redefinition. Then I decided to use another class B for added methods. Calling other methods from publicFoo did not work for me. I had to generalize it with run() method and then made classes A and B to implement Runnable to make it more clear. > Can you maintain order of the function declarations? > > 78 public static String ADeletePublicFoo = > > finalFoo should be before staticFoo in this one. Nice catch, thanks! Will fix it in the webrev update. > > Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, > finalFoo has already been deleted so you didn't want to also test > adding it back. Right. > > Thank you for enhancing the test.? I guess it's good that it tests the > new option. Thanks! Serguei > > Coleen > >> >>> >>> Thumbs up. Your call on whether to tweak the test. >> >> I'll send a VMDeprecatedOptions related update later. >> >> >> Thanks! >> Serguei >>> >>> Dan >>> >>> >>>> >>>> >>>> Summary: >>>> ? David, in review for >>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>> description of the new flag in globals.hpp >>>> ?? 2. The new flag should have been added to the deprecated VM >>>> options tests. >>>> ?? 3. The new test should run in both a positive and negative mode >>>> so that it also checks that the new flag works. >>>> >>>> ? The webrev above implements this suggestion. >>>> >>>> >>>> Testing: >>>> ? In progress: Submit mach5 run for the updated tests. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Apr 25 22:43:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 08:43:14 +1000 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: <5CC1A303.3040902@oracle.com> References: <5CC1A303.3040902@oracle.com> Message-ID: <867257f8-54bf-6b79-aa88-3e39a2dc97ea@oracle.com> Thanks Gary! David On 25/04/2019 10:07 pm, Gary Adams wrote: > Looks OK to me. > > On 4/25/19, 4:36 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 >> >> vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under >> JDK-8221503 which is now closed as a duplicate of JDK-8212117. So >> ProblemList.txt needs updating. >> >> Thanks, >> David >> ------ >> >> diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -159,7 +159,7 @@ >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> >> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all >> >> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all > From david.holmes at oracle.com Thu Apr 25 22:43:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 08:43:25 +1000 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: <1bb48a9c-849c-4691-84cb-26001c42f282@oracle.com> References: <1bb48a9c-849c-4691-84cb-26001c42f282@oracle.com> Message-ID: Thanks Dan! David On 26/04/2019 12:00 am, Daniel D. Daugherty wrote: > Thumbs up! > > Dan > > > On 4/25/19 4:36 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 >> >> vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under >> JDK-8221503 which is now closed as a duplicate of JDK-8212117. So >> ProblemList.txt needs updating. >> >> Thanks, >> David >> ------ >> >> diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -159,7 +159,7 @@ >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> >> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all >> >> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all > From david.holmes at oracle.com Thu Apr 25 22:43:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 08:43:40 +1000 Subject: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java In-Reply-To: <3a1c8f23-f79d-5360-ba0e-4eb7a698850f@oracle.com> References: <3a1c8f23-f79d-5360-ba0e-4eb7a698850f@oracle.com> Message-ID: <442c1f3a-37e6-779a-4a24-8435a2f57de3@oracle.com> Thanks Serguei! David On 26/04/2019 3:41 am, serguei.spitsyn at oracle.com wrote: > Hi David, > > Looks good. > Thank you for taking care about this! > > Thanks, > Serguei > > > On 4/25/19 01:36, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 >> >> vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under >> JDK-8221503 which is now closed as a duplicate of JDK-8212117. So >> ProblemList.txt needs updating. >> >> Thanks, >> David >> ------ >> >> diff -r b43cc3b9ef40 test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -159,7 +159,7 @@ >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> >> -vmTestbase/nsk/jdb/eval/eval001/eval001.java 8221503 generic-all >> +vmTestbase/nsk/jdb/eval/eval001/eval001.java 8212117 generic-all >> >> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all > From daniil.x.titov at oracle.com Thu Apr 25 23:34:01 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 25 Apr 2019 16:34:01 -0700 Subject: RFR: 8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" Message-ID: <798B2772-D304-4BF4-9894-D8335B172B74@oracle.com> Please review the change that fixes this test when it is run with Graal on. The test starts the debugee, creates multiple thread start requests, tells the debuggee to start a new thread, and listens for the thread start events received. If the number of the received thread start events doesn't match the number of created thread start requests the test fails. The problem here is that with Graal on, sometimes, the test receives events caused by the start of "HotSpotGraalManagement Bean Registration" thread. The fix ensures that a thread filter is added for all created thread start requests to ignore events caused by the threads not related to the test. Webrev: http://cr.openjdk.java.net/~dtitov/8222749/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222749 Thanks, Daniil From serguei.spitsyn at oracle.com Fri Apr 26 00:09:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 17:09:21 -0700 Subject: RFR: 8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" In-Reply-To: <798B2772-D304-4BF4-9894-D8335B172B74@oracle.com> References: <798B2772-D304-4BF4-9894-D8335B172B74@oracle.com> Message-ID: <8c57fcc1-dc9e-40af-ba48-e7909099db7f@oracle.com> Hi Daniil, Looks good. Thanks, Serguei On 4/25/19 4:34 PM, Daniil Titov wrote: > Please review the change that fixes this test when it is run with Graal on. > > The test starts the debugee, creates multiple thread start requests, tells the debuggee to start a new thread, and listens for the thread start events received. If the number of the received thread start events doesn't match the number of created thread start requests the test fails. The problem here is that with Graal on, sometimes, the test receives events caused by the start of "HotSpotGraalManagement Bean Registration" thread. > > The fix ensures that a thread filter is added for all created thread start requests to ignore events caused by the threads not related to the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222749/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222749 > > Thanks, > Daniil > > From jcbeyler at google.com Fri Apr 26 00:32:16 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 25 Apr 2019 17:32:16 -0700 Subject: RFR: 8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" In-Reply-To: <8c57fcc1-dc9e-40af-ba48-e7909099db7f@oracle.com> References: <798B2772-D304-4BF4-9894-D8335B172B74@oracle.com> <8c57fcc1-dc9e-40af-ba48-e7909099db7f@oracle.com> Message-ID: Hi Daniil, It looks good to me too :) Jc On Thu, Apr 25, 2019 at 5:21 PM wrote: > Hi Daniil, > > Looks good. > > Thanks, > Serguei > > On 4/25/19 4:34 PM, Daniil Titov wrote: > > Please review the change that fixes this test when it is run with Graal > on. > > > > The test starts the debugee, creates multiple thread start requests, > tells the debuggee to start a new thread, and listens for the thread start > events received. If the number of the received thread start events doesn't > match the number of created thread start requests the test fails. The > problem here is that with Graal on, sometimes, the test receives events > caused by the start of "HotSpotGraalManagement Bean Registration" thread. > > > > The fix ensures that a thread filter is added for all created thread > start requests to ignore events caused by the threads not related to the > test. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222749/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222749 > > > > Thanks, > > Daniil > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 26 00:59:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 17:59:34 -0700 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: References: Message-ID: Hi Ralf, The fix looks good to me. We agreed that Alex will also look at this. Thanks, Serguei On 4/17/19 1:30 AM, Schmelter, Ralf wrote: > Can you please review this change, which ensures the sun.jdwp.listenerAddress property value is created using the platform encoding. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ > bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 > > Best regards, > Ralf From alexey.menkov at oracle.com Fri Apr 26 01:10:15 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 25 Apr 2019 18:10:15 -0700 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: References: Message-ID: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> Hi Ralf, You added libjava for Windows, but not for other platforms. Doesn't it need LIBS_unix := -ljava ? --alex On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: > Hi Ralf, > > The fix looks good to me. > We agreed that Alex will also look at this. > > Thanks, > Serguei > > On 4/17/19 1:30 AM, Schmelter, Ralf wrote: >> Can you please review this change, which ensures the >> sun.jdwp.listenerAddress property value is created using the platform >> encoding. >> >> webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ >> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 >> >> Best regards, >> Ralf > From daniil.x.titov at oracle.com Fri Apr 26 01:33:55 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 25 Apr 2019 18:33:55 -0700 Subject: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed Message-ID: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> Please review the change that fixes an intermittent failure of the test when running with Graal on. The test creates exception requests for different kinds of exceptions and errors, starts the debuggee that throws an exception, and listens for exception events. If the number of received exception events is not equal to 1 the test fails. For the case when the exception request is created for java.lang.Error class the test intermittently fails if Graal is on. It happens because, sometimes, in addition to StackOverflowError thrown by the test itself, jdk.vm.ci.common.JVMCIError is thrown from method getField() in class jdk.vm.ci.hotspot .HotSpotVMConfigAccess at line 252 (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java) 240 private VMField getField(String name, String cppType, boolean required) { 241 VMField entry = store.vmFields.get(name); 242 if (entry == null) { 243 if (!required) { 244 return null; 245 } 246 store.printConfig(); 247 throw new JVMCIError("expected VM field not found in " + store + ": " + name); 248 } 249 250 // Make sure the native type is still the type we expect. 251 if (cppType != null && !cppType.equals(entry.type)) { 252 throw new JVMCIError("expected type " + cppType + " but VM field " + name + " is of type " + entry.type); 253 } 254 return entry; 255 } that in one case is caught at line 412 in src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java 404 public final int pendingFailedSpeculationOffset; 405 { 406 String name = "JavaThread::_pending_failed_speculation"; 407 int offset = -1; 408 try { 409 offset = getFieldOffset(name, Integer.class, "jlong"); 410 } catch (JVMCIError e) { 411 try { 412 offset = getFieldOffset(name, Integer.class, "long"); 413 } catch (JVMCIError e2) { 414 } 415 } 416 if (offset == -1) { 417 throw new JVMCIError("cannot get offset of field " + name + " with type long or jlong"); 418 } 419 pendingFailedSpeculationOffset = offset; 420 } and in other case at line 229 in the same class (src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java) 221 public final int classMirrorOffset; 222 { 223 String name = "Klass::_java_mirror"; 224 int offset = -1; 225 boolean isHandle = false; 226 try { 227 offset = getFieldOffset(name, Integer.class, "oop"); 228 } catch (JVMCIError e) { 229 230 } 231 if (offset == -1) { 232 try { 233 offset = getFieldOffset(name, Integer.class, "jobject"); 234 isHandle = true; 235 } catch (JVMCIError e) { 236 try { 237 // JDK-8186777 238 offset = getFieldOffset(name, Integer.class, "OopHandle"); 239 isHandle = true; 240 } catch (JVMCIError e2) { 241 } 242 } 243 } 244 if (offset == -1) { 245 throw new JVMCIError("cannot get offset of field " + name + " with type oop, jobject or OopHandle"); 246 } 247 classMirrorOffset = offset; 248 classMirrorIsHandle = isHandle; 249 } That results in the number of received exception events exceeds 1 and the test fails. To ignore these unexpected events the fix adds "jdk.vm.ci.hotspot.*" class exclusion filter when it creates an exception request. Webrev: http://cr.openjdk.java.net/~dtitov/8222821/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222821 Thanks! -Daniil From dean.long at oracle.com Fri Apr 26 01:42:32 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 25 Apr 2019 18:42:32 -0700 Subject: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed In-Reply-To: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> References: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> Message-ID: <1f247f0c-7581-9125-8fac-55116795dbd4@oracle.com> Looks good. dl On 4/25/19 6:33 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test when running with Graal on. > > The test creates exception requests for different kinds of exceptions and errors, starts the debuggee that throws an exception, and listens for exception events. If the number of received exception events is not equal to 1 the test fails. For the case when the exception request is created for java.lang.Error class the test intermittently fails if Graal is on. It happens because, sometimes, in addition to StackOverflowError thrown by the test itself, jdk.vm.ci.common.JVMCIError is thrown from method getField() in class jdk.vm.ci.hotspot .HotSpotVMConfigAccess at line 252 (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java) > > 240 private VMField getField(String name, String cppType, boolean required) { > 241 VMField entry = store.vmFields.get(name); > 242 if (entry == null) { > 243 if (!required) { > 244 return null; > 245 } > 246 store.printConfig(); > 247 throw new JVMCIError("expected VM field not found in " + store + ": " + name); > 248 } > 249 > 250 // Make sure the native type is still the type we expect. > 251 if (cppType != null && !cppType.equals(entry.type)) { > 252 throw new JVMCIError("expected type " + cppType + " but VM field " + name + " is of type " + entry.type); > 253 } > 254 return entry; > 255 } > > that in one case is caught at line 412 in src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > 404 public final int pendingFailedSpeculationOffset; > 405 { > 406 String name = "JavaThread::_pending_failed_speculation"; > 407 int offset = -1; > 408 try { > 409 offset = getFieldOffset(name, Integer.class, "jlong"); > 410 } catch (JVMCIError e) { > 411 try { > 412 offset = getFieldOffset(name, Integer.class, "long"); > 413 } catch (JVMCIError e2) { > 414 } > 415 } > 416 if (offset == -1) { > 417 throw new JVMCIError("cannot get offset of field " + name + " with type long or jlong"); > 418 } > 419 pendingFailedSpeculationOffset = offset; > 420 } > > and in other case at line 229 in the same class (src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java) > > 221 public final int classMirrorOffset; > 222 { > 223 String name = "Klass::_java_mirror"; > 224 int offset = -1; > 225 boolean isHandle = false; > 226 try { > 227 offset = getFieldOffset(name, Integer.class, "oop"); > 228 } catch (JVMCIError e) { > 229 > 230 } > 231 if (offset == -1) { > 232 try { > 233 offset = getFieldOffset(name, Integer.class, "jobject"); > 234 isHandle = true; > 235 } catch (JVMCIError e) { > 236 try { > 237 // JDK-8186777 > 238 offset = getFieldOffset(name, Integer.class, "OopHandle"); > 239 isHandle = true; > 240 } catch (JVMCIError e2) { > 241 } > 242 } > 243 } > 244 if (offset == -1) { > 245 throw new JVMCIError("cannot get offset of field " + name + " with type oop, jobject or OopHandle"); > 246 } > 247 classMirrorOffset = offset; > 248 classMirrorIsHandle = isHandle; > 249 } > > That results in the number of received exception events exceeds 1 and the test fails. > > To ignore these unexpected events the fix adds "jdk.vm.ci.hotspot.*" class exclusion filter when it creates an exception request. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222821/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222821 > > Thanks! > -Daniil > > > From jcbeyler at google.com Fri Apr 26 02:37:31 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 25 Apr 2019 19:37:31 -0700 Subject: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed In-Reply-To: <1f247f0c-7581-9125-8fac-55116795dbd4@oracle.com> References: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> <1f247f0c-7581-9125-8fac-55116795dbd4@oracle.com> Message-ID: Hi Daniil, Looks good to me too, (thanks for the detailed explanation about the test failure btw :-)), Jc On Thu, Apr 25, 2019 at 6:43 PM wrote: > Looks good. > > dl > > On 4/25/19 6:33 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent failure of the test > when running with Graal on. > > > > The test creates exception requests for different kinds of exceptions > and errors, starts the debuggee that throws an exception, and listens for > exception events. If the number of received exception events is not equal > to 1 the test fails. For the case when the exception request is created for > java.lang.Error class the test intermittently fails if Graal is on. It > happens because, sometimes, in addition to StackOverflowError thrown by the > test itself, jdk.vm.ci.common.JVMCIError is thrown from method getField() > in class jdk.vm.ci.hotspot .HotSpotVMConfigAccess at line 252 (src/ > jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java > ) > > > > 240 private VMField getField(String name, String cppType, boolean > required) { > > 241 VMField entry = store.vmFields.get(name); > > 242 if (entry == null) { > > 243 if (!required) { > > 244 return null; > > 245 } > > 246 store.printConfig(); > > 247 throw new JVMCIError("expected VM field not > found in " + store + ": " + name); > > 248 } > > 249 > > 250 // Make sure the native type is still the type we > expect. > > 251 if (cppType != null && > !cppType.equals(entry.type)) { > > 252 throw new JVMCIError("expected type " + > cppType + " but VM field " + name + " is of type " + entry.type); > > 253 } > > 254 return entry; > > 255 } > > > > that in one case is caught at line 412 in > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > > > 404 public final int pendingFailedSpeculationOffset; > > 405 { > > 406 String name = > "JavaThread::_pending_failed_speculation"; > > 407 int offset = -1; > > 408 try { > > 409 offset = getFieldOffset(name, Integer.class, > "jlong"); > > 410 } catch (JVMCIError e) { > > 411 try { > > 412 offset = getFieldOffset(name, > Integer.class, "long"); > > 413 } catch (JVMCIError e2) { > > 414 } > > 415 } > > 416 if (offset == -1) { > > 417 throw new JVMCIError("cannot get offset of > field " + name + " with type long or jlong"); > > 418 } > > 419 pendingFailedSpeculationOffset = offset; > > 420 } > > > > and in other case at line 229 in the same class > (src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java) > > > > 221 public final int classMirrorOffset; > > 222 { > > 223 String name = "Klass::_java_mirror"; > > 224 int offset = -1; > > 225 boolean isHandle = false; > > 226 try { > > 227 offset = getFieldOffset(name, Integer.class, > "oop"); > > 228 } catch (JVMCIError e) { > > 229 > > 230 } > > 231 if (offset == -1) { > > 232 try { > > 233 offset = getFieldOffset(name, > Integer.class, "jobject"); > > 234 isHandle = true; > > 235 } catch (JVMCIError e) { > > 236 try { > > 237 // JDK-8186777 > > 238 offset = getFieldOffset(name, > Integer.class, "OopHandle"); > > 239 isHandle = true; > > 240 } catch (JVMCIError e2) { > > 241 } > > 242 } > > 243 } > > 244 if (offset == -1) { > > 245 throw new JVMCIError("cannot get offset of > field " + name + " with type oop, jobject or OopHandle"); > > 246 } > > 247 classMirrorOffset = offset; > > 248 classMirrorIsHandle = isHandle; > > 249 } > > > > That results in the number of received exception events exceeds 1 and > the test fails. > > > > To ignore these unexpected events the fix adds "jdk.vm.ci.hotspot.*" > class exclusion filter when it creates an exception request. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222821/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222821 > > > > Thanks! > > -Daniil > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 26 02:57:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 19:57:37 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> Message-ID: Hi Coleen and Dan, Updated webrev is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.2/ This implements the suggestions: ?VMDeprecatedOptions.java: ? - moved the option to the deprecated non-alias flags section ?TestAddDeleteMethods.java: ? - removed confusion in redefinition string names and added comments recommended by Dan ? - always list methods in order: foo, publicFoo, finalFoo, staticFoo Thanks, Serguei On 4/25/19 2:41 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Thank you a lot for looking at this! > > > On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Dan, >>> >>> Thank you a lot fore reviewing this! >>> >>> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>>> >>>> >>>> src/hotspot/share/runtime/globals.hpp >>>> ??? No comments. >>>> >>>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>>> ??? L42: ??????? // deprecated class redefinition flags: >>>> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >>>> ??? L44: >>>> ??? L45: ??????? // deprecated non-alias flags: >>>> ??????? I think your new flag entry should have been added to the >>>> ??????? "deprecated non-alias flags" section. You don't need to >>>> ??????? call out that this is a "class redefinition" flag. >>>> >>>> ??????? The reason for the "// deprecated alias flags (see also >>>> aliased_jvm_flags):" >>>> ??????? section (below what you changed) is because there is more >>>> ??????? work to do for those flags. >>> >>> Okay, I'm not very familiar with this test, will check how to change it. >>> >>>> >>>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>>> >>>> ??? L94: ??? public static String ADeleteStaticFoo = >>>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>>> ??????? Is that what you really want? If so, then the test case >>>> ??????? is misnamed. >>> >>> I see your confusion here. >>> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >>> So, the "finalFoo" has been already deleted before. >>> Then the ADeleteStaticFoo only deletes the "staticFoo". >>> >>> The same was not the case for ADeleteFinalFoo. >>> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >>> are expected to be rejected with UOE. >>> >>>> >>>> ??? L119???? public static String BAddStaticBar = >>>> ??????? This case is added "staticBar" and "finalBar". Is that what >>>> ??????? you really want? If so, then the test case is misnamed. >>> >>> This one is similar to the above. >>> The "finalBar" has already been added bythe BAddFinalBar redefinition. >>> >>> Please, let me know if you are Okay with it as it is or prefer to >>> add a comment with clarification. >>> >>>> >>>> ??? Still a really cool test here! >>> >>> The test was initially written by Coleen (thanks, Coleen!) >>> I've spoiled it a little bit though. :) >> >> Hi Serguei,? You added a lot to it, which is taking me a while to >> understand. >> >> Why did you make class A inherit from Runnable? > > In fact, nothing foxy. > It implements Runnable, not inherits. :) > There were two steps. > First was to decide if we there is a point to call methods in the > redefined classes A and B. > You did it with the in the original test version but you made > publicFoo to call others. > So, I decided that it is useful to make sure the methods are executed > well after redefinition. > Then I decided to use another class B for added methods. > Calling other methods from publicFoo did not work for me. > I had to generalize it with run() method and then made > classes A and B to implement Runnable to make it more clear. > > >> Can you maintain order of the function declarations? >> >> 78 public static String ADeletePublicFoo = >> >> finalFoo should be before staticFoo in this one. > Nice catch, thanks! > Will fix it in the webrev update. > >> >> Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, >> finalFoo has already been deleted so you didn't want to also test >> adding it back. > > Right. > >> >> Thank you for enhancing the test.? I guess it's good that it tests >> the new option. > > Thanks! > Serguei > >> >> Coleen >> >>> >>>> >>>> Thumbs up. Your call on whether to tweak the test. >>> >>> I'll send a VMDeprecatedOptions related update later. >>> >>> >>> Thanks! >>> Serguei >>>> >>>> Dan >>>> >>>> >>>>> >>>>> >>>>> Summary: >>>>> ? David, in review for >>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>>> description of the new flag in globals.hpp >>>>> ?? 2. The new flag should have been added to the deprecated VM >>>>> options tests. >>>>> ?? 3. The new test should run in both a positive and negative mode >>>>> so that it also checks that the new flag works. >>>>> >>>>> ? The webrev above implements this suggestion. >>>>> >>>>> >>>>> Testing: >>>>> ? In progress: Submit mach5 run for the updated tests. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Apr 26 05:54:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Apr 2019 15:54:47 +1000 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> Message-ID: <581993b3-4644-602e-c4b5-2bd7ae2e2e54@oracle.com> Hi Serguei, Thanks for making these additional changes. On 26/04/2019 12:57 pm, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > Updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.2/ > > This implements the suggestions: > ?VMDeprecatedOptions.java: > ? - moved the option to the deprecated non-alias flags section Yep that's fine. > ?TestAddDeleteMethods.java: > ? - removed confusion in redefinition string names and added comments > recommended by Dan > ? - always list methods in order: foo, publicFoo, finalFoo, staticFoo One nit: 39 import java.lang.Runnable; java.lang.* is implicitly imported so we don't list any imports for java.lang types. Thanks, David ----- > Thanks, > Serguei > > > On 4/25/19 2:41 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you a lot for looking at this! >> >> >> On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Dan, >>>> >>>> Thank you a lot fore reviewing this! >>>> >>>> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>>>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>>>> >>>>> >>>>> src/hotspot/share/runtime/globals.hpp >>>>> ??? No comments. >>>>> >>>>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>>>> ??? L42: ??????? // deprecated class redefinition flags: >>>>> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >>>>> ??? L44: >>>>> ??? L45: ??????? // deprecated non-alias flags: >>>>> ??????? I think your new flag entry should have been added to the >>>>> ??????? "deprecated non-alias flags" section. You don't need to >>>>> ??????? call out that this is a "class redefinition" flag. >>>>> >>>>> ??????? The reason for the "// deprecated alias flags (see also >>>>> aliased_jvm_flags):" >>>>> ??????? section (below what you changed) is because there is more >>>>> ??????? work to do for those flags. >>>> >>>> Okay, I'm not very familiar with this test, will check how to change it. >>>> >>>>> >>>>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>>>> >>>>> ??? L94: ??? public static String ADeleteStaticFoo = >>>>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>>>> ??????? Is that what you really want? If so, then the test case >>>>> ??????? is misnamed. >>>> >>>> I see your confusion here. >>>> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >>>> So, the "finalFoo" has been already deleted before. >>>> Then the ADeleteStaticFoo only deletes the "staticFoo". >>>> >>>> The same was not the case for ADeleteFinalFoo. >>>> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >>>> are expected to be rejected with UOE. >>>> >>>>> >>>>> ??? L119???? public static String BAddStaticBar = >>>>> ??????? This case is added "staticBar" and "finalBar". Is that what >>>>> ??????? you really want? If so, then the test case is misnamed. >>>> >>>> This one is similar to the above. >>>> The "finalBar" has already been added bythe BAddFinalBar redefinition. >>>> >>>> Please, let me know if you are Okay with it as it is or prefer to >>>> add a comment with clarification. >>>> >>>>> >>>>> ??? Still a really cool test here! >>>> >>>> The test was initially written by Coleen (thanks, Coleen!) >>>> I've spoiled it a little bit though. :) >>> >>> Hi Serguei,? You added a lot to it, which is taking me a while to >>> understand. >>> >>> Why did you make class A inherit from Runnable? >> >> In fact, nothing foxy. >> It implements Runnable, not inherits. :) >> There were two steps. >> First was to decide if we there is a point to call methods in the >> redefined classes A and B. >> You did it with the in the original test version but you made >> publicFoo to call others. >> So, I decided that it is useful to make sure the methods are executed >> well after redefinition. >> Then I decided to use another class B for added methods. >> Calling other methods from publicFoo did not work for me. >> I had to generalize it with run() method and then made >> classes A and B to implement Runnable to make it more clear. >> >> >>> Can you maintain order of the function declarations? >>> >>> 78 public static String ADeletePublicFoo = >>> >>> finalFoo should be before staticFoo in this one. >> Nice catch, thanks! >> Will fix it in the webrev update. >> >>> >>> Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, >>> finalFoo has already been deleted so you didn't want to also test >>> adding it back. >> >> Right. >> >>> >>> Thank you for enhancing the test.? I guess it's good that it tests >>> the new option. >> >> Thanks! >> Serguei >> >>> >>> Coleen >>> >>>> >>>>> >>>>> Thumbs up. Your call on whether to tweak the test. >>>> >>>> I'll send a VMDeprecatedOptions related update later. >>>> >>>> >>>> Thanks! >>>> Serguei >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> ? David, in review for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>>>> description of the new flag in globals.hpp >>>>>> ?? 2. The new flag should have been added to the deprecated VM >>>>>> options tests. >>>>>> ?? 3. The new test should run in both a positive and negative mode >>>>>> so that it also checks that the new flag works. >>>>>> >>>>>> ? The webrev above implements this suggestion. >>>>>> >>>>>> >>>>>> Testing: >>>>>> ? In progress: Submit mach5 run for the updated tests. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Fri Apr 26 05:57:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Apr 2019 22:57:27 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: <581993b3-4644-602e-c4b5-2bd7ae2e2e54@oracle.com> References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> <581993b3-4644-602e-c4b5-2bd7ae2e2e54@oracle.com> Message-ID: <56d88919-21d6-eed9-4d4d-4f345d55705f@oracle.com> Hi David, Thank you for the review! I'll remove this import. Thanks, Serguei On 4/25/19 22:54, David Holmes wrote: > Hi Serguei, > > Thanks for making these additional changes. > > On 26/04/2019 12:57 pm, serguei.spitsyn at oracle.com wrote: >> Hi Coleen and Dan, >> >> Updated webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.2/ >> >> >> This implements the suggestions: >> ??VMDeprecatedOptions.java: >> ?? - moved the option to the deprecated non-alias flags section > > Yep that's fine. > >> ??TestAddDeleteMethods.java: >> ?? - removed confusion in redefinition string names and added >> comments recommended by Dan >> ?? - always list methods in order: foo, publicFoo, finalFoo, staticFoo > > One nit: > > ? 39 import java.lang.Runnable; > > java.lang.* is implicitly imported so we don't list any imports for > java.lang types. > > Thanks, > David > ----- > >> Thanks, >> Serguei >> >> >> On 4/25/19 2:41 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Thank you a lot for looking at this! >>> >>> >>> On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dan, >>>>> >>>>> Thank you a lot fore reviewing this! >>>>> >>>>> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>>>>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review fix for: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>>>>> >>>>>> >>>>>> src/hotspot/share/runtime/globals.hpp >>>>>> ??? No comments. >>>>>> >>>>>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>>>>> ??? L42: ??????? // deprecated class redefinition flags: >>>>>> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >>>>>> ??? L44: >>>>>> ??? L45: ??????? // deprecated non-alias flags: >>>>>> ??????? I think your new flag entry should have been added to the >>>>>> ??????? "deprecated non-alias flags" section. You don't need to >>>>>> ??????? call out that this is a "class redefinition" flag. >>>>>> >>>>>> ??????? The reason for the "// deprecated alias flags (see also >>>>>> aliased_jvm_flags):" >>>>>> ??????? section (below what you changed) is because there is more >>>>>> ??????? work to do for those flags. >>>>> >>>>> Okay, I'm not very familiar with this test, will check how to >>>>> change it. >>>>> >>>>>> >>>>>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>>>>> >>>>>> ??? L94: ??? public static String ADeleteStaticFoo = >>>>>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>>>>> ??????? Is that what you really want? If so, then the test case >>>>>> ??????? is misnamed. >>>>> >>>>> I see your confusion here. >>>>> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >>>>> So, the "finalFoo" has been already deleted before. >>>>> Then the ADeleteStaticFoo only deletes the "staticFoo". >>>>> >>>>> The same was not the case for ADeleteFinalFoo. >>>>> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >>>>> are expected to be rejected with UOE. >>>>> >>>>>> >>>>>> ??? L119???? public static String BAddStaticBar = >>>>>> ??????? This case is added "staticBar" and "finalBar". Is that what >>>>>> ??????? you really want? If so, then the test case is misnamed. >>>>> >>>>> This one is similar to the above. >>>>> The "finalBar" has already been added bythe BAddFinalBar >>>>> redefinition. >>>>> >>>>> Please, let me know if you are Okay with it as it is or prefer to >>>>> add a comment with clarification. >>>>> >>>>>> >>>>>> ??? Still a really cool test here! >>>>> >>>>> The test was initially written by Coleen (thanks, Coleen!) >>>>> I've spoiled it a little bit though. :) >>>> >>>> Hi Serguei,? You added a lot to it, which is taking me a while to >>>> understand. >>>> >>>> Why did you make class A inherit from Runnable? >>> >>> In fact, nothing foxy. >>> It implements Runnable, not inherits. :) >>> There were two steps. >>> First was to decide if we there is a point to call methods in the >>> redefined classes A and B. >>> You did it with the in the original test version but you made >>> publicFoo to call others. >>> So, I decided that it is useful to make sure the methods are >>> executed well after redefinition. >>> Then I decided to use another class B for added methods. >>> Calling other methods from publicFoo did not work for me. >>> I had to generalize it with run() method and then made >>> classes A and B to implement Runnable to make it more clear. >>> >>> >>>> Can you maintain order of the function declarations? >>>> >>>> ?? 78???? public static String ADeletePublicFoo = >>>> >>>> finalFoo should be before staticFoo in this one. >>> Nice catch, thanks! >>> Will fix it in the webrev update. >>> >>>> >>>> Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, >>>> finalFoo has already been deleted so you didn't want to also test >>>> adding it back. >>> >>> Right. >>> >>>> >>>> Thank you for enhancing the test.? I guess it's good that it tests >>>> the new option. >>> >>> Thanks! >>> Serguei >>> >>>> >>>> Coleen >>>> >>>>> >>>>>> >>>>>> Thumbs up. Your call on whether to tweak the test. >>>>> >>>>> I'll send a VMDeprecatedOptions related update later. >>>>> >>>>> >>>>> Thanks! >>>>> Serguei >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> ? David, in review for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>>>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>>>>> description of the new flag in globals.hpp >>>>>>> ?? 2. The new flag should have been added to the deprecated VM >>>>>>> options tests. >>>>>>> ?? 3. The new test should run in both a positive and negative >>>>>>> mode so that it also checks that the new flag works. >>>>>>> >>>>>>> ? The webrev above implements this suggestion. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> ? In progress: Submit mach5 run for the updated tests. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From christoph.langer at sap.com Fri Apr 26 07:36:16 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 07:36:16 +0000 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> References: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> Message-ID: Hi Alex, for other platforms (toolchains), except Windows, -ljava is part of BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here: http://hg.openjdk.java.net/jdk/jdk/file/9ebb614d293d/make/autoconf/libraries.m4#l114 Although I don't know the reasoning for that, the patch seems correct to me. I guess it can be pushed then? Best regards Christoph > -----Original Message----- > From: serviceability-dev On > Behalf Of Alex Menkov > Sent: Freitag, 26. April 2019 03:10 > To: serguei.spitsyn at oracle.com; Schmelter, Ralf ; > serviceability-dev at openjdk.java.net > Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses > wrong encoding > > Hi Ralf, > > You added libjava for Windows, but not for other platforms. > Doesn't it need > LIBS_unix := -ljava > ? > > --alex > > On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: > > Hi Ralf, > > > > The fix looks good to me. > > We agreed that Alex will also look at this. > > > > Thanks, > > Serguei > > > > On 4/17/19 1:30 AM, Schmelter, Ralf wrote: > >> Can you please review this change, which ensures the > >> sun.jdwp.listenerAddress property value is created using the platform > >> encoding. > >> > >> webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ > >> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 > >> > >> Best regards, > >> Ralf > > From gary.adams at oracle.com Fri Apr 26 12:14:39 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 26 Apr 2019 08:14:39 -0400 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: References: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> Message-ID: <5CC2F62F.3080004@oracle.com> It'd be good to have someone on build-dev review this change. On 4/26/19, 3:36 AM, Langer, Christoph wrote: > Hi Alex, > > for other platforms (toolchains), except Windows, -ljava is part of BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here: http://hg.openjdk.java.net/jdk/jdk/file/9ebb614d293d/make/autoconf/libraries.m4#l114 > > Although I don't know the reasoning for that, the patch seems correct to me. > > I guess it can be pushed then? > > Best regards > Christoph > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of Alex Menkov >> Sent: Freitag, 26. April 2019 03:10 >> To: serguei.spitsyn at oracle.com; Schmelter, Ralf; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses >> wrong encoding >> >> Hi Ralf, >> >> You added libjava for Windows, but not for other platforms. >> Doesn't it need >> LIBS_unix := -ljava >> ? >> >> --alex >> >> On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: >>> Hi Ralf, >>> >>> The fix looks good to me. >>> We agreed that Alex will also look at this. >>> >>> Thanks, >>> Serguei >>> >>> On 4/17/19 1:30 AM, Schmelter, Ralf wrote: >>>> Can you please review this change, which ensures the >>>> sun.jdwp.listenerAddress property value is created using the platform >>>> encoding. >>>> >>>> webrev: >> http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ >>>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 >>>> >>>> Best regards, >>>> Ralf From christoph.langer at sap.com Fri Apr 26 12:21:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Apr 2019 12:21:08 +0000 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: <5CC2F62F.3080004@oracle.com> References: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> <5CC2F62F.3080004@oracle.com> Message-ID: Hi Gary, fair point. cc-ing build-dev. Can you please check this change. Maybe you can comment on the background why JDKLIB_LIBS does not include -ljava, too? Thanks Christoph > -----Original Message----- > From: Gary Adams > Sent: Freitag, 26. April 2019 14:15 > To: Langer, Christoph > Cc: Alex Menkov ; > serguei.spitsyn at oracle.com; Schmelter, Ralf ; > serviceability-dev at openjdk.java.net > Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses > wrong encoding > > It'd be good to have someone on build-dev review this change. > > On 4/26/19, 3:36 AM, Langer, Christoph wrote: > > Hi Alex, > > > > for other platforms (toolchains), except Windows, -ljava is part of > BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here: > http://hg.openjdk.java.net/jdk/jdk/file/9ebb614d293d/make/autoconf/libra > ries.m4#l114 > > > > Although I don't know the reasoning for that, the patch seems correct to > me. > > > > I guess it can be pushed then? > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: serviceability-dev > On > >> Behalf Of Alex Menkov > >> Sent: Freitag, 26. April 2019 03:10 > >> To: serguei.spitsyn at oracle.com; Schmelter, > Ralf; > >> serviceability-dev at openjdk.java.net > >> Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property > uses > >> wrong encoding > >> > >> Hi Ralf, > >> > >> You added libjava for Windows, but not for other platforms. > >> Doesn't it need > >> LIBS_unix := -ljava > >> ? > >> > >> --alex > >> > >> On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: > >>> Hi Ralf, > >>> > >>> The fix looks good to me. > >>> We agreed that Alex will also look at this. > >>> > >>> Thanks, > >>> Serguei > >>> > >>> On 4/17/19 1:30 AM, Schmelter, Ralf wrote: > >>>> Can you please review this change, which ensures the > >>>> sun.jdwp.listenerAddress property value is created using the platform > >>>> encoding. > >>>> > >>>> webrev: > >> http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ > >>>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 > >>>> > >>>> Best regards, > >>>> Ralf From erik.joelsson at oracle.com Fri Apr 26 13:35:17 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Apr 2019 06:35:17 -0700 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: References: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> <5CC2F62F.3080004@oracle.com> Message-ID: <04164ea3-14d3-d8d3-996f-8c53942a070b@oracle.com> Hello, Change looks good. As to why java.lib is not added to JDKLIB_LIBS like -ljava is on other platforms, I don't know, but it's hardly the responsibility of this change to figure that out. /Erik On 2019-04-26 05:21, Langer, Christoph wrote: > Hi Gary, > > fair point. > > cc-ing build-dev. Can you please check this change. Maybe you can comment on the background why JDKLIB_LIBS does not include -ljava, too? > > Thanks > Christoph > >> -----Original Message----- >> From: Gary Adams >> Sent: Freitag, 26. April 2019 14:15 >> To: Langer, Christoph >> Cc: Alex Menkov ; >> serguei.spitsyn at oracle.com; Schmelter, Ralf ; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses >> wrong encoding >> >> It'd be good to have someone on build-dev review this change. >> >> On 4/26/19, 3:36 AM, Langer, Christoph wrote: >>> Hi Alex, >>> >>> for other platforms (toolchains), except Windows, -ljava is part of >> BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here: >> http://hg.openjdk.java.net/jdk/jdk/file/9ebb614d293d/make/autoconf/libra >> ries.m4#l114 >>> Although I don't know the reasoning for that, the patch seems correct to >> me. >>> I guess it can be pushed then? >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: serviceability-dev >> On >>>> Behalf Of Alex Menkov >>>> Sent: Freitag, 26. April 2019 03:10 >>>> To: serguei.spitsyn at oracle.com; Schmelter, >> Ralf; >>>> serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property >> uses >>>> wrong encoding >>>> >>>> Hi Ralf, >>>> >>>> You added libjava for Windows, but not for other platforms. >>>> Doesn't it need >>>> LIBS_unix := -ljava >>>> ? >>>> >>>> --alex >>>> >>>> On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: >>>>> Hi Ralf, >>>>> >>>>> The fix looks good to me. >>>>> We agreed that Alex will also look at this. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 4/17/19 1:30 AM, Schmelter, Ralf wrote: >>>>>> Can you please review this change, which ensures the >>>>>> sun.jdwp.listenerAddress property value is created using the platform >>>>>> encoding. >>>>>> >>>>>> webrev: >>>> http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ >>>>>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 >>>>>> >>>>>> Best regards, >>>>>> Ralf From daniel.daugherty at oracle.com Fri Apr 26 15:27:06 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Apr 2019 11:27:06 -0400 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> Message-ID: <271c69c9-6a38-50b5-f567-688f164ad4a9@oracle.com> On 4/25/19 10:57 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen and Dan, > > Updated webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.2/ src/hotspot/share/runtime/globals.hpp ??? No comments. test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ??? No comments. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java ??? L100: ??? // So, this redefinition will add it back which is expected to work. ??????? There's a space at the end of this comment line. jcheck may complain. ??? L132: ??? // So, this redefinition will deleate it back which is expected to work. ??????? Typo: s/deleate it back/delete it/ ??????? There's a space at the end of this comment line. jcheck may complain. Thumbs up. Dan > > This implements the suggestions: > ?VMDeprecatedOptions.java: > ? - moved the option to the deprecated non-alias flags section > > ?TestAddDeleteMethods.java: > ? - removed confusion in redefinition string names and added comments > recommended by Dan > ? - always list methods in order: foo, publicFoo, finalFoo, staticFoo > > Thanks, > Serguei > > > On 4/25/19 2:41 PM, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Thank you a lot for looking at this! >> >> >> On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Dan, >>>> >>>> Thank you a lot fore reviewing this! >>>> >>>> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>>>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>>>> >>>>> >>>>> src/hotspot/share/runtime/globals.hpp >>>>> ??? No comments. >>>>> >>>>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>>>> ??? L42: ??????? // deprecated class redefinition flags: >>>>> ??? L43: ??????? {"AllowRedefinitionToAddDeleteMethods", "true"}, >>>>> ??? L44: >>>>> ??? L45: ??????? // deprecated non-alias flags: >>>>> ??????? I think your new flag entry should have been added to the >>>>> ??????? "deprecated non-alias flags" section. You don't need to >>>>> ??????? call out that this is a "class redefinition" flag. >>>>> >>>>> ??????? The reason for the "// deprecated alias flags (see also >>>>> aliased_jvm_flags):" >>>>> ??????? section (below what you changed) is because there is more >>>>> ??????? work to do for those flags. >>>> >>>> Okay, I'm not very familiar with this test, will check how to >>>> change it. >>>> >>>>> >>>>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>>>> >>>>> ??? L94: ??? public static String ADeleteStaticFoo = >>>>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>>>> ??????? Is that what you really want? If so, then the test case >>>>> ??????? is misnamed. >>>> >>>> I see your confusion here. >>>> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >>>> So, the "finalFoo" has been already deleted before. >>>> Then the ADeleteStaticFoo only deletes the "staticFoo". >>>> >>>> The same was not the case for ADeleteFinalFoo. >>>> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >>>> are expected to be rejected with UOE. >>>> >>>>> >>>>> ??? L119???? public static String BAddStaticBar = >>>>> ??????? This case is added "staticBar" and "finalBar". Is that what >>>>> ??????? you really want? If so, then the test case is misnamed. >>>> >>>> This one is similar to the above. >>>> The "finalBar" has already been added bythe BAddFinalBar redefinition. >>>> >>>> Please, let me know if you are Okay with it as it is or prefer to >>>> add a comment with clarification. >>>> >>>>> >>>>> ??? Still a really cool test here! >>>> >>>> The test was initially written by Coleen (thanks, Coleen!) >>>> I've spoiled it a little bit though. :) >>> >>> Hi Serguei,? You added a lot to it, which is taking me a while to >>> understand. >>> >>> Why did you make class A inherit from Runnable? >> >> In fact, nothing foxy. >> It implements Runnable, not inherits. :) >> There were two steps. >> First was to decide if we there is a point to call methods in the >> redefined classes A and B. >> You did it with the in the original test version but you made >> publicFoo to call others. >> So, I decided that it is useful to make sure the methods are executed >> well after redefinition. >> Then I decided to use another class B for added methods. >> Calling other methods from publicFoo did not work for me. >> I had to generalize it with run() method and then made >> classes A and B to implement Runnable to make it more clear. >> >> >>> Can you maintain order of the function declarations? >>> >>> 78 public static String ADeletePublicFoo = >>> >>> finalFoo should be before staticFoo in this one. >> Nice catch, thanks! >> Will fix it in the webrev update. >> >>> >>> Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, >>> finalFoo has already been deleted so you didn't want to also test >>> adding it back. >> >> Right. >> >>> >>> Thank you for enhancing the test.? I guess it's good that it tests >>> the new option. >> >> Thanks! >> Serguei >> >>> >>> Coleen >>> >>>> >>>>> >>>>> Thumbs up. Your call on whether to tweak the test. >>>> >>>> I'll send a VMDeprecatedOptions related update later. >>>> >>>> >>>> Thanks! >>>> Serguei >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> ? David, in review for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>>>> description of the new flag in globals.hpp >>>>>> ?? 2. The new flag should have been added to the deprecated VM >>>>>> options tests. >>>>>> ?? 3. The new test should run in both a positive and negative >>>>>> mode so that it also checks that the new flag works. >>>>>> >>>>>> ? The webrev above implements this suggestion. >>>>>> >>>>>> >>>>>> Testing: >>>>>> ? In progress: Submit mach5 run for the updated tests. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Apr 26 16:57:45 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 26 Apr 2019 09:57:45 -0700 Subject: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding In-Reply-To: References: <532f7547-2769-ed86-d061-3a19eaf171a3@oracle.com> Message-ID: Thanks for the explanation. Looks good to me. --alex On 04/26/2019 00:36, Langer, Christoph wrote: > Hi Alex, > > for other platforms (toolchains), except Windows, -ljava is part of BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here: http://hg.openjdk.java.net/jdk/jdk/file/9ebb614d293d/make/autoconf/libraries.m4#l114 > > Although I don't know the reasoning for that, the patch seems correct to me. > > I guess it can be pushed then? > > Best regards > Christoph > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of Alex Menkov >> Sent: Freitag, 26. April 2019 03:10 >> To: serguei.spitsyn at oracle.com; Schmelter, Ralf ; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses >> wrong encoding >> >> Hi Ralf, >> >> You added libjava for Windows, but not for other platforms. >> Doesn't it need >> LIBS_unix := -ljava >> ? >> >> --alex >> >> On 04/25/2019 17:59, serguei.spitsyn at oracle.com wrote: >>> Hi Ralf, >>> >>> The fix looks good to me. >>> We agreed that Alex will also look at this. >>> >>> Thanks, >>> Serguei >>> >>> On 4/17/19 1:30 AM, Schmelter, Ralf wrote: >>>> Can you please review this change, which ensures the >>>> sun.jdwp.listenerAddress property value is created using the platform >>>> encoding. >>>> >>>> webrev: >> http://cr.openjdk.java.net/~rschmelter/webrevs/8222529/webrev.0/ >>>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8222529 >>>> >>>> Best regards, >>>> Ralf >>> From daniil.x.titov at oracle.com Fri Apr 26 17:06:46 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 26 Apr 2019 10:06:46 -0700 Subject: 8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" In-Reply-To: References: <798B2772-D304-4BF4-9894-D8335B172B74@oracle.com> <8c57fcc1-dc9e-40af-ba48-e7909099db7f@oracle.com> Message-ID: Thank you, Serguei and JC, for reviewing this change! Best regards, Daniil From: Jean Christophe Beyler Date: Thursday, April 25, 2019 at 5:32 PM To: Serguei Spitsyn Cc: Daniil Titov , OpenJDK Serviceability Subject: Re: RFR: 8222749: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "eventSet1.size() != 3 :: 2" Hi Daniil, It looks good to me too :) Jc On Thu, Apr 25, 2019 at 5:21 PM wrote: Hi Daniil, Looks good. Thanks, Serguei On 4/25/19 4:34 PM, Daniil Titov wrote: > Please review the change that fixes this test when it is run with Graal on. > > The test starts the debugee, creates multiple thread start requests, tells the debuggee to start a new thread, and listens for the thread start events received. If the number of the received thread start events doesn't match the number of created thread start requests the test fails. The problem here is that with Graal on, sometimes, the test receives events caused by the start of "HotSpotGraalManagement Bean Registration" thread. > > The fix ensures that a thread filter is added for all created thread start requests to ignore events caused by the threads not related to the test. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222749/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222749 > > Thanks, > Daniil > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 26 18:31:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Apr 2019 11:31:05 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: <271c69c9-6a38-50b5-f567-688f164ad4a9@oracle.com> References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> <271c69c9-6a38-50b5-f567-688f164ad4a9@oracle.com> Message-ID: <24650188-189e-c98e-db86-9ecc31e94e52@oracle.com> An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Fri Apr 26 18:39:27 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 26 Apr 2019 14:39:27 -0400 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: <24650188-189e-c98e-db86-9ecc31e94e52@oracle.com> References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> <271c69c9-6a38-50b5-f567-688f164ad4a9@oracle.com> <24650188-189e-c98e-db86-9ecc31e94e52@oracle.com> Message-ID: Looks good to me. Coleen On 4/26/19 2:31 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you for re-review! > I'll fix the spaces at the end, thanks. > > Thanks, > Serguei > > On 4/26/19 08:27, Daniel D. Daugherty wrote: >> On 4/25/19 10:57 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen and Dan, >>> >>> Updated webrev is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.2/ >> >> src/hotspot/share/runtime/globals.hpp >> ??? No comments. >> >> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >> ??? No comments. >> >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >> ??? L100: ??? // So, this redefinition will add it back which is >> expected to work. >> ??????? There's a space at the end of this comment line. jcheck may >> complain. >> >> ??? L132: ??? // So, this redefinition will deleate it back which is >> expected to work. >> ??????? Typo: s/deleate it back/delete it/ >> >> ??????? There's a space at the end of this comment line. jcheck may >> complain. >> >> Thumbs up. >> >> Dan >> >> >> >>> >>> This implements the suggestions: >>> ?VMDeprecatedOptions.java: >>> ? - moved the option to the deprecated non-alias flags section >>> >>> ?TestAddDeleteMethods.java: >>> ? - removed confusion in redefinition string names and added >>> comments recommended by Dan >>> ? - always list methods in order: foo, publicFoo, finalFoo, staticFoo >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/25/19 2:41 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Coleen, >>>> >>>> Thank you a lot for looking at this! >>>> >>>> >>>> On 4/25/19 2:18 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 4/25/19 4:19 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dan, >>>>>> >>>>>> Thank you a lot fore reviewing this! >>>>>> >>>>>> On 4/25/19 12:40, Daniel D. Daugherty wrote: >>>>>>> On 4/24/19 6:18 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review fix for: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8222934-jvmti-depr-option.1/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/globals.hpp >>>>>>> ??? No comments. >>>>>>> >>>>>>> test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java >>>>>>> ??? L42: ??????? // deprecated class redefinition flags: >>>>>>> ??? L43: {"AllowRedefinitionToAddDeleteMethods", "true"}, >>>>>>> ??? L44: >>>>>>> ??? L45: ??????? // deprecated non-alias flags: >>>>>>> ??????? I think your new flag entry should have been added to the >>>>>>> ??????? "deprecated non-alias flags" section. You don't need to >>>>>>> ??????? call out that this is a "class redefinition" flag. >>>>>>> >>>>>>> ??????? The reason for the "// deprecated alias flags (see also >>>>>>> aliased_jvm_flags):" >>>>>>> ??????? section (below what you changed) is because there is more >>>>>>> ??????? work to do for those flags. >>>>>> >>>>>> Okay, I'm not very familiar with this test, will check how to >>>>>> change it. >>>>>> >>>>>>> >>>>>>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java >>>>>>> >>>>>>> ??? L94: ??? public static String ADeleteStaticFoo = >>>>>>> ??????? This case is deleting both "staticFoo" and "finalFoo". >>>>>>> ??????? Is that what you really want? If so, then the test case >>>>>>> ??????? is misnamed. >>>>>> >>>>>> I see your confusion here. >>>>>> The ADeleteStaticFoo is used after the ADeleteFinalFoo. >>>>>> So, the "finalFoo" has been already deleted before. >>>>>> Then the ADeleteStaticFoo only deletes the "staticFoo". >>>>>> >>>>>> The same was not the case for ADeleteFinalFoo. >>>>>> It is because the redefinitions with ADeleteFoo and ADeletePublicFoo >>>>>> are expected to be rejected with UOE. >>>>>> >>>>>>> >>>>>>> ??? L119???? public static String BAddStaticBar = >>>>>>> ??????? This case is added "staticBar" and "finalBar". Is that what >>>>>>> ??????? you really want? If so, then the test case is misnamed. >>>>>> >>>>>> This one is similar to the above. >>>>>> The "finalBar" has already been added bythe BAddFinalBar >>>>>> redefinition. >>>>>> >>>>>> Please, let me know if you are Okay with it as it is or prefer to >>>>>> add a comment with clarification. >>>>>> >>>>>>> >>>>>>> ??? Still a really cool test here! >>>>>> >>>>>> The test was initially written by Coleen (thanks, Coleen!) >>>>>> I've spoiled it a little bit though. :) >>>>> >>>>> Hi Serguei,? You added a lot to it, which is taking me a while to >>>>> understand. >>>>> >>>>> Why did you make class A inherit from Runnable? >>>> >>>> In fact, nothing foxy. >>>> It implements Runnable, not inherits. :) >>>> There were two steps. >>>> First was to decide if we there is a point to call methods in the >>>> redefined classes A and B. >>>> You did it with the in the original test version but you made >>>> publicFoo to call others. >>>> So, I decided that it is useful to make sure the methods are >>>> executed well after redefinition. >>>> Then I decided to use another class B for added methods. >>>> Calling other methods from publicFoo did not work for me. >>>> I had to generalize it with run() method and then made >>>> classes A and B to implement Runnable to make it more clear. >>>> >>>> >>>>> Can you maintain order of the function declarations? >>>>> >>>>> 78 public static String ADeletePublicFoo = >>>>> >>>>> finalFoo should be before staticFoo in this one. >>>> Nice catch, thanks! >>>> Will fix it in the webrev update. >>>> >>>>> >>>>> Oh, now I see what Dan is talking about.? In ADeleteStaticFoo, >>>>> finalFoo has already been deleted so you didn't want to also test >>>>> adding it back. >>>> >>>> Right. >>>> >>>>> >>>>> Thank you for enhancing the test.? I guess it's good that it tests >>>>> the new option. >>>> >>>> Thanks! >>>> Serguei >>>> >>>>> >>>>> Coleen >>>>> >>>>>> >>>>>>> >>>>>>> Thumbs up. Your call on whether to tweak the test. >>>>>> >>>>>> I'll send a VMDeprecatedOptions related update later. >>>>>> >>>>>> >>>>>> Thanks! >>>>>> Serguei >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> ? David, in review for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222934 suggested: >>>>>>>> ?? 1. I would have suggested to add "(Deprecated)" to the >>>>>>>> description of the new flag in globals.hpp >>>>>>>> ?? 2. The new flag should have been added to the deprecated VM >>>>>>>> options tests. >>>>>>>> ?? 3. The new test should run in both a positive and negative >>>>>>>> mode so that it also checks that the new flag works. >>>>>>>> >>>>>>>> ? The webrev above implements this suggestion. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> ? In progress: Submit mach5 run for the updated tests. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Apr 26 18:40:17 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Apr 2019 11:40:17 -0700 Subject: RFS(S): 8222934: mark new VM option AllowRedefinitionToAddOrDeleteMethods as deprecated In-Reply-To: References: <9de5a830-6f6e-ba37-8bc0-81f8ffce3c48@oracle.com> <2531112b-7ec4-1190-0fc5-f88af38b418b@oracle.com> <271c69c9-6a38-50b5-f567-688f164ad4a9@oracle.com> <24650188-189e-c98e-db86-9ecc31e94e52@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Apr 26 23:19:24 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 26 Apr 2019 16:19:24 -0700 Subject: RFR (M) Message-ID: Hi all, Since JDK-8213501 finally merged (sorry it took so long), I am able to continue this work. Here is the work that puts back the messages for any calls that were moved around due to JDK-8212884. Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 All modified tests pass on my local dev machine. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Apr 27 00:45:46 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Apr 2019 17:45:46 -0700 Subject: RFR (M) In-Reply-To: References: Message-ID: Hi Jc, I hope, you will resend this RFR with full subject line. Thanks, Serguei On 4/26/19 4:19 PM, Jean Christophe Beyler wrote: > Hi all, > > Since?JDK-8213501 finally merged (sorry it took so long), I am able to > continue this work. Here is the work that puts back the messages for > any calls that were moved around due to?JDK-8212884. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 > > All modified tests pass on my local dev machine. > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Apr 27 00:52:06 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 26 Apr 2019 17:52:06 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests Message-ID: Hi all, (Re-sending with subject line complete :-)) Since JDK-8213501 finally merged (sorry it took so long), I am able to continue this work. Here is the work that puts back the messages for any calls that were moved around due to JDK-8212884. Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 All modified tests pass on my local dev machine. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat Apr 27 01:51:45 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Apr 2019 18:51:45 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: Message-ID: Hi Jc, It looks good to me. A couple of comments/questions. In most files the changes look similar like below: -Java_nsk_jvmti_scenarios_bcinstr_BI01_bi01t002_setNewByteCode(JNIEnv *jni_env, +Java_nsk_jvmti_scenarios_bcinstr_BI01_bi01t002_setNewByteCode(JNIEnv *jni, jobject o, jint ind, jbyteArray byteCode) { + ExceptionCheckingJniEnvPtr jni_env(jni); But in this file, renaming is in opposite direction: -agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg) { +agentProc(jvmtiEnv* jvmti, JNIEnv* jni_env, void* arg) { + ExceptionCheckingJniEnvPtr jni(jni_env); In general, I have a little concern about use of jni_env forExceptionCheckingJniEnvPtr. Could it be less confusing to use something like ec_jni or ec_jni_env? So that it will be clear that it is not normal(JNIEnv *). Thanks, Serguei On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: > Hi all, > > (Re-sending with subject line complete :-)) > > Since?JDK-8213501 finally merged (sorry it took so long), I am able to > continue this work. Here is the work that puts back the messages for > any calls that were moved around due to?JDK-8212884. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 > > All modified tests pass on my local dev machine. > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Apr 27 02:29:43 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 26 Apr 2019 19:29:43 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: Message-ID: Hi Serguei, Thanks for the comments as always. Originally, I did it this way (where I strive to not change the name of the variables in the method) so that I changed minimally the lines of the methods. But since I add a parameter, I change them regardless so I could go both ways. Having done this a few times now, I see it right away due to the TRACE_JNI_CALL added to the call, so there is no confusion for me. But if you prefer, I can rename all the instances to ec_jni_env. Would you like me to change in this same webrev all the ones from previous webrevs or just the ones of this one and I'll do another webrev to make the other ones consistent? Thanks, Jc On Fri, Apr 26, 2019 at 6:51 PM wrote: > Hi Jc, > > It looks good to me. > A couple of comments/questions. > > In most files the changes look similar like below: > > -Java_nsk_jvmti_scenarios_bcinstr_BI01_bi01t002_setNewByteCode(JNIEnv *jni_env,+Java_nsk_jvmti_scenarios_bcinstr_BI01_bi01t002_setNewByteCode(JNIEnv *jni, > jobject o, jint ind, jbyteArray byteCode) { > + ExceptionCheckingJniEnvPtr jni_env(jni); > > > But in this file, renaming is in opposite direction: > > -agentProc(jvmtiEnv* jvmti, JNIEnv* jni, void* arg) {+agentProc(jvmtiEnv* jvmti, JNIEnv* jni_env, void* arg) { > + ExceptionCheckingJniEnvPtr jni(jni_env); > > > In general, I have a little concern about use of jni_env for ExceptionCheckingJniEnvPtr. > Could it be less confusing to use something like ec_jni or ec_jni_env? > So that it will be clear that it is not normal (JNIEnv *). > > Thanks, > Serguei > > > On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: > > Hi all, > > (Re-sending with subject line complete :-)) > > Since JDK-8213501 finally merged (sorry it took so long), I am able to > continue this work. Here is the work that puts back the messages for any > calls that were moved around due to JDK-8212884. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 > > All modified tests pass on my local dev machine. > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Apr 27 03:18:47 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 26 Apr 2019 20:18:47 -0700 Subject: Providing users with thread type In-Reply-To: References: <7a95c5be-0058-a96f-3102-ecbb778bdc73@oracle.com> <9dad7c09-8cf9-e47f-65cc-42a465e38b77@oracle.com> <355b27ce-d590-fbbd-0e7a-e61085b075a6@oracle.com> <1e3359e6-f4c9-7dd9-dbd9-6136fdaaa63b@oracle.com> Message-ID: Ok I figured out what was going on. It's not as weird as I thought it would be: this is seemingly something "new" because it is true for recent JDKs but not for JDK8 that I was using for my tests. It still feels a bit wrong and a bit brittle, but if we don't think we would like to expose something explicitly, then this is already a starting point I believe, I'll continue testing and see if I can get it working entirely in my JDK11 agent version. Thanks all for your input, Jc On Sat, Apr 20, 2019 at 11:25 PM Thomas St?fe wrote: > > > On Sun, Apr 21, 2019 at 3:01 AM Jean Christophe Beyler < > jcbeyler at google.com> wrote: > >> Ahh there lies the problem of understanding then :) >> >> We can provide that for our users that can use a non-vanilla OpenJDK. >> Vanilla OpenJDK cannot use that kind of thing since there is no "C" style >> symbol you could dlsym to. I don't think there is a good mechanism to >> currently piece the information together using a vanilla OpenJDK. >> >> So this conversation is about providing a mechanism for all OpenJDK agent >> writers to figure this out, even if they had to jump through hoops. The >> pthread_getname_np would have been a good one presumably but it seems that >> a lot of systems just rename the native threads for some reason... >> > > I would like to understand this better. From user code, the way to rename > a thread is to call pthread_setname_np on it, for which you need the > pthread_t of the thread, and how would user code get that for a VM internal > thread that never yields control to the outside world? Or do you think this > renaming is done at kernel/libC level? > > Might also be that we have an error somewhere and do not always set the > thread name. AFAIK we do not have tests for that, so that could bitrot. > > ..Thomas > > >> >> Hence I was offering to either extend AsyncGetCallTrace method (or create >> a side-one) or extend the JVMPI_CallTrace structure. Either of these would >> allow profilers to gather this information on future vanilla OpenJDKs. If >> that makes sense, >> Jc >> >> On Sat, Apr 20, 2019 at 6:14 PM David Holmes >> wrote: >> >>> Hi Jc, >>> >>> On 21/04/2019 8:15 am, Jean Christophe Beyler wrote: >>> > Hi David, >>> > >>> > Hopefully this gives more details :) >>> > >>> > Basically, in the Java agent, we set up a SIGPROF handler and we get a >>> > handler call at a set frequency rate (generally the profiling is for >>> 30 >>> > seconds). The thread that is doing the signal handler can be a thread >>> > from the JVM and as we have said in this thread, internal VM threads >>> > can't get a JNIEnv or are visible to JVMTI anyway so we can't really >>> get >>> > the name. >>> >>> And yet ... >>> >>> > Our current implementation, when faced with a thread like that, calls >>> a >>> > method like above that we added in the JVM to provide information >>> about >>> > what type of work was being done so that when we provide our profiles, >>> > we can give that information to the user. >>> >>> ... they can call this method you added to the JVM? How do they do that? >>> And if they can do that why can't they get the name the same way? Or >>> call any existing query methods to piece together the information? >>> >>> Cheers, >>> David >>> >>> > However for agents that cannot use the modified JVM, we cannot provide >>> > this information it seems and basically we have to fallback to getting >>> > the PC and just attributing it to libjvm.so (see an example here >>> > >>> https://github.com/GoogleCloudPlatform/cloud-profiler-java/blob/master/src/profiler.cc#L127 >>> ) >>> > >>> > So basically, in cases where we are in a signal handler, where we are >>> > asynchronous and cannot do a lot, getting a side method to just say : >>> > "hey is this a compiler thread, is this a GC thread, etc." would >>> > actually be helpful information during profiling instead of the >>> general >>> > "well this many threads were in libjvm.so but we don't know what was >>> > going on". >>> > >>> > I've thought about using some other information such as >>> > CompilationMXBean to try to assess what is going on during profiling >>> but >>> > it seems hard to correctly attribute that back into the actual >>> profiles >>> > and untangle the libjvm.so buccket. >>> > >>> > Hopefully this makes sense, >>> > Jc >>> > >>> > On Sat, Apr 20, 2019 at 12:20 AM David Holmes >> > > wrote: >>> > >>> > On 20/04/2019 10:29 am, Jean Christophe Beyler wrote: >>> > > Hi David, >>> > > >>> > > On Fri, Apr 19, 2019 at 6:49 PM David Holmes >>> > >>> > > >> > >> wrote: >>> > > >>> > > Hi Jc, >>> > > >>> > > On 20/04/2019 12:30 am, Jean Christophe Beyler wrote: >>> > > > Problem is that if I don't have a jthread, I can't get >>> the >>> > name it >>> > > > seems. Perhaps it could help if I gave more information: >>> > > > >>> > > > - In our JVM profiling mechanism, we have a SIGPROF (and >>> maybe >>> > > that's a >>> > > > wrong approach :-)) that gets cycled across threads >>> (some Java >>> > > threads, >>> > > > some are the other threads) >>> > > > - It is the other threads that I'm interested here to >>> > be able to >>> > > > distinguish what they are in terms of of profiles >>> > > > >>> > > > Is there any way we could provide that (not in JVMTI >>> then)? >>> > > > - The only way I could imagine perhaps doing this >>> would be >>> > > perhaps >>> > > > to have a set of other tools at the same time running >>> > (either using >>> > > > beans before/after or JFR) but this seems crude as well >>> > (better than >>> > > > nothing though) >>> > > > - I wish there was a way to just be able to get a >>> type >>> > for those >>> > > > internal frames while doing the actual SIGPROF handling >>> > > > >>> > > > FWIW, the method we expose basically is like this: >>> > > > Thread* current_thread = >>> > > ThreadLocalStorage::get_thread_async_safe(); >>> > > >>> > > We have Thread::current_or_null_safe() for that. >>> > > >>> > > >>> > > A decade old code might have rotted a bit (or been wrong from >>> the >>> > > start), I'll change this internal code :) >>> > > >>> > > >>> > > > if (current_thread == NULL) { >>> > > > return -1; >>> > > > } else if (current_thread->is_Compiler_thread()) { >>> > > > return _activity_compile; >>> > > > } else if (current_thread->is_Java_thread()) { >>> > > > return -1; >>> > > > } else if (current_thread->is_GC_task_thread()) { >>> > > > return _activity_gc; >>> > > > } else if (current_thread->is_VM_thread()) { >>> > > > VMThread* vm_thread = (VMThread*) current_thread; >>> > > > VM_Operation* vm_op = vm_thread->vm_operation(); >>> > > > if (vm_op != NULL) { >>> > > > switch (vm_op->type()) { >>> > > > case VM_Operation::VMOp_GC_HeapInspection: >>> > > > case VM_Operation::VMOp_GenCollectFull: >>> > > > case >>> VM_Operation::VMOp_GenCollectFullConcurrent: >>> > > > case >>> VM_Operation::VMOp_GenCollectForAllocation: >>> > > > case >>> VM_Operation::VMOp_ParallelGCFailedAllocation: >>> > > > case VM_Operation::VMOp_ParallelGCSystemGC: >>> > > > case VM_Operation::VMOp_CGC_Operation: >>> > > > case VM_Operation::VMOp_CMS_Initial_Mark: >>> > > > case VM_Operation::VMOp_CMS_Final_Remark: >>> > > > case VM_Operation::VMOp_G1CollectFull: >>> > > > case >>> VM_Operation::VMOp_G1CollectForAllocation: >>> > > > case VM_Operation::VMOp_G1IncCollectionPause: >>> > > > return _activity_gc; >>> > > > default: >>> > > > break; >>> > > > } >>> > > > } >>> > > > } >>> > > > return _activity_other_vm; >>> > > > } >>> > > >>> > > So it's not really the thread "type" but the logical >>> > "activity". For >>> > > "type" you'd just need a query version of >>> > Thread::print_on_error (more >>> > > or less). >>> > > >>> > > >>> > > Not at all sure where you could put this - nor clear why you >>> > need to >>> > > put >>> > > it somewhere: isn't this just something executed by your >>> SIGPROF >>> > > handler? >>> > > >>> > > >>> > > Well problem is that I'm not in the JVM at the sigprof handler >>> > level. >>> > > I'm actually in the agent, >>> > >>> > Not sure what you mean. I'm assuming you're sending a SIGPROF to >>> each >>> > thread and using the handler for profiling - no? Otherwise please >>> > clarify what is happening in each thread. >>> > >>> > > so basically from the agent's point of view, >>> > > I don't really know what "Activity" I just stopped but would >>> love to >>> > > know. We added internally this change to figure it out but I'd >>> > like to >>> > > get it in the open-source so that all could use it and not just >>> us >>> > >>> > A "char* Thread::get_thread_type()" API might be useful (as I said >>> a >>> > query version of print_on_error(). But otherwise this seems >>> something >>> > peculiar to your agent so simply composing existing API calls - as >>> you >>> > outline - seems the appropriate way to deal with this. >>> > >>> > Seems to me the VMThread is the problem here because you want to >>> try >>> > and >>> > attribute the VM_operation to different "buckets". But given the >>> > bulk of >>> > the work is actually done by other threads (e.g. GC), and going >>> forward >>> > less and less will be done by the VMThread itself (e.g. async >>> monitor >>> > deflation), is it really worth trying to classify this at a finer >>> level >>> > than just "in the VM"? >>> > >>> > Cheers, >>> > David >>> > >>> > > internally. Basically, like I said ,when using open-source >>> > profilers, >>> > > this would help divide up the "libjvm.so" bucket that a lot of >>> > profilers >>> > > are getting. >>> > > Thanks for your insight as always, >>> > > Jc >>> > > >>> > > >>> > > >>> > > David >>> > > >>> > > > It's crude but we believe it is effective to at least >>> > "bucketize" >>> > > the >>> > > > internals while doing our profiling. >>> > > > >>> > > > Thanks for your input, >>> > > > Jc >>> > > > >>> > > > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman >>> > > >>> > > >>> > > > >> > >>> > > >> > >>> wrote: >>> > > > >>> > > > On 19/04/2019 00:12, David Holmes wrote: >>> > > > > >>> > > > > I think it would be difficult to put something >>> like >>> > this >>> > > in JVM TI >>> > > > > given that the use of threads within the JVM are >>> > purely an >>> > > > > implementation detail and not standardized in any >>> > way. And >>> > > many of >>> > > > > those threads are hidden from JVM TI anyway. >>> > > > > >>> > > > > The names of threads are the normal way to see >>> what >>> > "type" >>> > > of thread >>> > > > > you're dealing with. >>> > > > Right, JVM TI only deals with "Java threads" (jthread >>> > object) and >>> > > > has no >>> > > > knowledge about other threads. It might be possible >>> to >>> > use its >>> > > > extension >>> > > > mechanism to provide information about other threads >>> > but it >>> > > wouldn't be >>> > > > interoperable with anything that use jtherad objects. >>> > > > >>> > > > -Alan >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > >>> > > > Thanks, >>> > > > Jc >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > > Thanks, >>> > > Jc >>> > >>> > >>> > >>> > -- >>> > >>> > Thanks, >>> > Jc >>> >> >> >> -- >> >> Thanks, >> Jc >> > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ceeaspb at gmail.com Sun Apr 28 21:32:40 2019 From: ceeaspb at gmail.com (Alex Bagehot) Date: Sun, 28 Apr 2019 22:32:40 +0100 Subject: Providing users with thread type In-Reply-To: References: Message-ID: Hi Jc, Have you seen at the work of async profiler? It may provide the kind of visibility into VM work that you are after. https://github.com/jvm-profiling-tools/async-profiler As it can be driven from Linux perf events rather than SIGPROF it is able to observe more of the system and therefore provides more insights. Thanks, Alex On Thu, Apr 18, 2019 at 3:19 PM Jean Christophe Beyler wrote: > Hi all, > > When doing profiling, often users have a hard time determining what is > happening inside libjvm.so. When doing profiling, the JVM seems like a > black box and it is hard to differentiate between a thread doing > GC/Compile/Actual VM work since all they get is profiles from libjvm.so but > not what are the various profiles doing. > > We have a small patch that provides a method to users to ask what is the > type of the current thread, which then provides one of those types > (GC/Compile/Actual VM work). > > I'd like to ask if this seems like a reasonable thing to do and should I > work on providing this via a JVMTI call. Something like > GetCurrentThreadType. > > What do you all think? Is this sane and possible to try to push forward? > > Thanks for your opinions, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.schmelter at sap.com Mon Apr 29 13:19:49 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 29 Apr 2019 13:19:49 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger Message-ID: Please review the patch which adds a jcmd to get the actual address the debugging backend is listening on. The this value was stored in the agent property sun.jdwp.listenerAddress and currently only used by the ProcessAttachingConnector. Additionally, the listen address is now displayed by the VM.start_java_debugging command, if a new session was started. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8223065 Best regards, Ralf From gary.adams at oracle.com Mon Apr 29 14:49:42 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 29 Apr 2019 10:49:42 -0400 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: <5CC70F06.1010205@oracle.com> In diagnosticCommand.cpp you'll want to use "res != 0" on lines 1084 and 1086 to avoid compiler warnings about ambiguous conversions to boolean. 1082 // The result should be a byte array or null 1083 typeArrayOop res = (typeArrayOop) result.get_jobject(); 1084 assert(!res || (TypeArrayKlass::cast(res->klass())->element_type() == T_BYTE), "Must be byte array"); 1085 1086 if (res&& (res->length()> 0)) { I see a SEGV in print_debug_listen_address running GetListenAddressTest with a linux-x64-debug build. Can you triage the bug and target the fixVersion for 13. Thanks On 4/29/19, 9:19 AM, Schmelter, Ralf wrote: > Please review the patch which adds a jcmd to get the actual address the debugging backend is listening on. > > The this value was stored in the agent property sun.jdwp.listenerAddress and currently only used by the ProcessAttachingConnector. > > Additionally, the listen address is now displayed by the VM.start_java_debugging command, if a new session was started. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.0/ > bugreport: https://bugs.openjdk.java.net/browse/JDK-8223065 > > Best regards, > Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.schmelter at sap.com Mon Apr 29 15:31:44 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 29 Apr 2019 15:31:44 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: <5CC70F06.1010205@oracle.com> References: <5CC70F06.1010205@oracle.com> Message-ID: Thanks for the review. I've update the webrev to use explicit NULL checks: https://bugs.openjdk.java.net/browse/JDK-8223065 And I now use the pointer to the first byte in the result to split the property value, since I might need the calculate the pointer past the last character (if the prop ends with ':'). I cannot see the SEGV, but I've scheduled the patch to be tested in our nightly build again, so maybe I can reproduce it there. Best regards, Ralf From chris.plummer at oracle.com Mon Apr 29 17:37:44 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 29 Apr 2019 10:37:44 -0700 Subject: RFR (M) In-Reply-To: References: Message-ID: <3a534b3a-fe5a-6574-61f3-d16b4167132b@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 29 17:38:40 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 29 Apr 2019 10:38:40 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: Message-ID: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 29 17:58:49 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 29 Apr 2019 10:58:49 -0700 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: <5CC70F06.1010205@oracle.com> Message-ID: <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> Hi Ralf, I think print_debug_listen_address() should have some exception checking added after the java calls. I'm a little unsure why you modified DebugOnCmdStartDCmd to use print_debug_listen_address(), but still have a fallback to print the specified transport and address. If anything I would have written a get_debug_listen_address() and used it to verify that the specified and actual addresses end up being the same (and then also make print_debug_listen_address() use this API). I'm also unsure of your ThreadToNativeFromVM change. This is not an area I understand well, so best to get someone else to ok it. You need to update copyright date to 2019. Can you write a test for this new dcmd. You can probably just extend OnJcmdTest.java. thanks, Chris On 4/29/19 8:31 AM, Schmelter, Ralf wrote: > Thanks for the review. > > I've update the webrev to use explicit NULL checks: https://bugs.openjdk.java.net/browse/JDK-8223065 > > And I now use the pointer to the first byte in the result to split the property value, since I might need the calculate the pointer past the last character (if the prop ends with ':'). > > I cannot see the SEGV, but I've scheduled the patch to be tested in our nightly build again, so maybe I can reproduce it there. > > Best regards, > Ralf From jcbeyler at google.com Mon Apr 29 21:58:41 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 29 Apr 2019 14:58:41 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> Message-ID: Hi Chris, Thanks for the review! It is the only issue I have with the system now and I had not found a good solution for: as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL at the end; so I put right before the end; that allows me to do this: +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. Do you have any better suggestion? Thanks! Jc On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer wrote: > Hi JC, > > In em01t002.cpp, is this correct? > > 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, > methodID, TRACE_JNI_CALL, className); > > Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into why > this test didn't fail as a result. > > Other than that the changes look good. > > thanks, > > Chris > > On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: > > Hi all, > > (Re-sending with subject line complete :-)) > > Since JDK-8213501 finally merged (sorry it took so long), I am able to > continue this work. Here is the work that puts back the messages for any > calls that were moved around due to JDK-8212884. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 > > All modified tests pass on my local dev machine. > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Apr 29 22:40:45 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 29 Apr 2019 15:40:45 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Apr 29 23:25:16 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 29 Apr 2019 16:25:16 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> Message-ID: Hi Chris, I agree it's not ideal, how about putting it first? 73 loadedClass = (jclass) jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); I find that less awkward than the VAR_ARGS, no? Or something like: 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, methodID, className); Where CallObjectMethodTraced is actually a define in the exception handling system that adds the line and filename... Which looks better? Thanks again, Jc On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer wrote: > Ok. I only half heatedly suggest the following > > 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, > methodID, VAR_ARGS(className)); > > And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. > > Chris > > On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: > > Hi Chris, > > Thanks for the review! It is the only issue I have with the system now and > I had not found a good solution for: > > as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL at > the end; so I put right before the end; that allows me to do this: > > > +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} > > Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. > > Do you have any better suggestion? > > Thanks! > > Jc > > > On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer > wrote: > >> Hi JC, >> >> In em01t002.cpp, is this correct? >> >> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >> methodID, TRACE_JNI_CALL, className); >> >> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into why >> this test didn't fail as a result. >> >> Other than that the changes look good. >> >> thanks, >> >> Chris >> >> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >> >> Hi all, >> >> (Re-sending with subject line complete :-)) >> >> Since JDK-8213501 finally merged (sorry it took so long), I am able to >> continue this work. Here is the work that puts back the messages for any >> calls that were moved around due to JDK-8212884. >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >> >> All modified tests pass on my local dev machine. >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 30 04:44:22 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 29 Apr 2019 21:44:22 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> Message-ID: <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 30 04:49:06 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 29 Apr 2019 21:49:06 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> Message-ID: Yes I would fix them all in the next webrev and then continue the porting. I 100% agree to which is less offensive. I find that 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, methodID, className); to be offensive as well. So perhaps the TRACED_VARARGS is best: 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, TRACED_VARARGS(className)); What do you think? On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer wrote: > Hi JC, > > On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: > > Hi Chris, > > I agree it's not ideal, how about putting it first? > > 73 loadedClass = (jclass) > jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); > > It's not consistent with other uses, or are you suggesting changing them > all? > > > I find that less awkward than the VAR_ARGS, no? > > Or something like: > 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, > methodID, className); > > Where CallObjectMethodTraced is actually a define in the exception > handling system that adds the line and filename... > > I don't like macroizing a method call in this manner (macros should be all > upper case, right?). Also it's inconsistent with the other tracing calls, > unless you plan on doing it to all of them. > > > Which looks better? > > Not sure. I wouldn't ask which is better. I'd ask which is less offensive. > :) > > thanks, > > Chris > > > Thanks again, > Jc > > On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer > wrote: > >> Ok. I only half heatedly suggest the following >> >> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >> methodID, VAR_ARGS(className)); >> >> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >> >> Chris >> >> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >> >> Hi Chris, >> >> Thanks for the review! It is the only issue I have with the system now >> and I had not found a good solution for: >> >> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL at >> the end; so I put right before the end; that allows me to do this: >> >> >> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >> >> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >> >> Do you have any better suggestion? >> >> Thanks! >> >> Jc >> >> >> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> In em01t002.cpp, is this correct? >>> >>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>> methodID, TRACE_JNI_CALL, className); >>> >>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into why >>> this test didn't fail as a result. >>> >>> Other than that the changes look good. >>> >>> thanks, >>> >>> Chris >>> >>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>> >>> Hi all, >>> >>> (Re-sending with subject line complete :-)) >>> >>> Since JDK-8213501 finally merged (sorry it took so long), I am able to >>> continue this work. Here is the work that puts back the messages for any >>> calls that were moved around due to JDK-8212884. >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>> >>> All modified tests pass on my local dev machine. >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Apr 30 07:22:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 17:22:58 +1000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> References: <5CC70F06.1010205@oracle.com> <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> Message-ID: <8dc062ac-8054-a917-8cb0-06a9617fe561@oracle.com> Responding to Chris's question below ... On 30/04/2019 3:58 am, Chris Plummer wrote: > Hi Ralf, > > I think print_debug_listen_address() should have some exception checking > added after the java calls. > > I'm a little unsure why you modified DebugOnCmdStartDCmd to use > print_debug_listen_address(), but still have a fallback to print the > specified transport and address. If anything I would have written a > get_debug_listen_address() and used it to verify that the specified and > actual addresses end up being the same (and then also make > print_debug_listen_address() use this API). > > I'm also unsure of your ThreadToNativeFromVM change. This is not an area > I understand well, so best to get someone else to ok it. I can see that the new code for print_debug_listen_address needs to be executed whilst still _thread_in_vm so the ThreadToNativeFromVM helper can't extend over that part. However, I would suggest that you otherwise keep it covering as much of the existing code as possible - specifically the chunk that calls os::find_agent_function. I would be concerned that the eventual calls to dlsym etc may potentially take some time and this would prevent safepoints from occurring as this thread is still "in VM". This might be overly conservative but it avoids any possibility of introducing a change in behaviour for the existing code. Cheers, David ----- > You need to update copyright date to 2019. > > Can you write a test for this new dcmd. You can probably just extend > OnJcmdTest.java. > > thanks, > > Chris > > On 4/29/19 8:31 AM, Schmelter, Ralf wrote: >> Thanks for the review. >> >> I've update the webrev to use explicit NULL checks: >> https://bugs.openjdk.java.net/browse/JDK-8223065 >> >> And I now use the pointer to the first byte in the result to split the >> property value, since I might need the calculate the pointer past the >> last character (if the prop ends with ':'). >> >> I cannot see the SEGV, but I've scheduled the patch to be tested in >> our nightly build again, so maybe I can reproduce it there. >> >> Best regards, >> Ralf > > From david.holmes at oracle.com Tue Apr 30 09:46:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 19:46:21 +1000 Subject: RFR(S) 8222935: Add forgotten files for ExceptionCheckingJniEnv In-Reply-To: References: Message-ID: <75e5b0de-976c-e11d-15dd-30b20241b91b@oracle.com> Hi Jc, The new tests are failing on Windows: https://bugs.openjdk.java.net/browse/JDK-8223146 Cheers, David On 25/04/2019 4:07 am, Jean Christophe Beyler wrote: > Hi all, > > When pushing my fix for?JDK-8213501, I did not push the added files > which were the new test for the whole system. > > These were reviewed via the JDK-8213501 > (http://cr.openjdk.java.net/~jcbeyler/8213501/webrev.08/) fix but I'm > just asking for a review again to add this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8222935/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222935 > > My apologies for this... This has been sent to the submit repo in parallel. > > Thanks, > Jc From ralf.schmelter at sap.com Tue Apr 30 11:30:14 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 30 Apr 2019 11:30:14 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> References: <5CC70F06.1010205@oracle.com> <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> Message-ID: Hi Chris. > I think print_debug_listen_address() should have some exception checking > added after the java calls. That is already done by the CHECK_false macro. It checks if an exception is occurred, and returns with false if this is the case. And depending on how the dcmd was called, this exception is then handled (e.g. if called via jcmd, the exception is printed and if called the jmm_ExecuteDiagnosticCommand method, the exception is delivered to the Java code). > I'm a little unsure why you modified DebugOnCmdStartDCmd to use > print_debug_listen_address(), but still have a fallback to print the > specified transport and address. Yeah, the fallback is really not needed, since the debugger is not listening in this case. I've removed it from the code. > If anything I would have written a > get_debug_listen_address() and used it to verify that the specified and > actual addresses end up being the same (and then also make > print_debug_listen_address() use this API). Because the requested address and the actual address the debugger is listening can be different. In the case of sockets, if you request localhost:0, the system will find an unused port, so the listening address will be the actual port on which we listen. > You need to update copyright date to 2019. Fixed. > Can you write a test for this new dcmd. You can probably just extend > OnJcmdTest.java. The GetListenAddressTest tests the new dcmd. I've updated the webrev (including David's suggestion): http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ Best regards, Ralf From ralf.schmelter at sap.com Tue Apr 30 11:33:34 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 30 Apr 2019 11:33:34 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: <8dc062ac-8054-a917-8cb0-06a9617fe561@oracle.com> References: <5CC70F06.1010205@oracle.com> <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> <8dc062ac-8054-a917-8cb0-06a9617fe561@oracle.com> Message-ID: Hi David, good catch. I've moved the vm->native transition back to the start of the method and instead do a native->vm transition before calling print_debug_listen_address() method. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ Best regards, Ralf From david.holmes at oracle.com Tue Apr 30 12:54:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Apr 2019 22:54:40 +1000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: <5CC70F06.1010205@oracle.com> <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> <8dc062ac-8054-a917-8cb0-06a9617fe561@oracle.com> Message-ID: <3c97e3b8-e54b-7cfc-737c-932b3afe57ba@oracle.com> Hi Ralf, On 30/04/2019 9:33 pm, Schmelter, Ralf wrote: > Hi David, > > good catch. I've moved the vm->native transition back to the start of the method and instead do a native->vm transition before calling print_debug_listen_address() method. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ Yep that works too. :) Not a review as I didn't look at the rest of the code. Cheers, David > Best regards, > Ralf > From jcbeyler at google.com Tue Apr 30 15:39:08 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 08:39:08 -0700 Subject: RFR (XS) 8223152 Put ExceptionCheckingJniEnv in the problem list for Windows Message-ID: Hi all, Until I figure out what is going on in the test failure on Windows, here is a small webrev to add it to the problem list: diff -r 7acebe4d65e2 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Thu Apr 18 13:58:31 2019 +0200 +++ b/test/hotspot/jtreg/ProblemList.txt Tue Apr 30 08:38:11 2019 -0700 @@ -195,4 +195,6 @@ vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 7199837 generic-all +vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001.java 8223152 windows-all + ############################################################################# Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 30 16:17:54 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Apr 2019 09:17:54 -0700 Subject: RFR (XS) 8223152 Put ExceptionCheckingJniEnv in the problem list for Windows In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 30 16:30:00 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 09:30:00 -0700 Subject: RFR (XS) 8223152 Put ExceptionCheckingJniEnv in the problem list for Windows In-Reply-To: References: Message-ID: Hi Serguei, Ok, I think I understand now: diff -r 7acebe4d65e2 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Thu Apr 18 13:58:31 2019 +0200 +++ b/test/hotspot/jtreg/ProblemList.txt Tue Apr 30 09:28:41 2019 -0700 @@ -195,4 +195,6 @@ vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java 7199837 generic-all +vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001.java 8223146 windows-all + ############################################################################# That number is for : https://bugs.openjdk.java.net/browse/JDK-8223146 But the RFR and title of the webrev / summary will be for: https://bugs.openjdk.java.net/browse/JDK-8223152 Correct? Jc On Tue, Apr 30, 2019 at 9:18 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > +vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001.java 8223152 > windows-all > > The real issue bug number has to be listed above. > So, new issue has to be filed to cover the problem. > Then a sub-task of it needs to be created to problem-list the bug. > > I can assist you if you need more help. > > Thanks, > Serguei > > > On 4/30/19 08:39, Jean Christophe Beyler wrote: > > Hi all, > > Until I figure out what is going on in the test failure on Windows, here > is a small webrev to add it to the problem list: > > diff -r 7acebe4d65e2 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Thu Apr 18 13:58:31 2019 > +0200 > +++ b/test/hotspot/jtreg/ProblemList.txt Tue Apr 30 08:38:11 2019 > -0700 > @@ -195,4 +195,6 @@ > > vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java > 7199837 generic-all > > +vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001.java 8223152 > windows-all > + > > ############################################################################# > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 30 16:51:23 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 30 Apr 2019 09:51:23 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> Message-ID: <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 30 17:05:35 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 10:05:35 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> Message-ID: I do have more of these coming and there are 86 CallXMethod cases where this will occur and 49 NewObject cases. So it would be good to figure out something that does not hurt our eyes too many times. I think I would go with the TRACED_VARARGS, it at least has the advantage of not being too bad. I would move toward doing: 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, TRACED_JNI_CALL(className)); To be consisted with the non-vararg cases, what do you think? Jc On Tue, Apr 30, 2019 at 9:51 AM Chris Plummer wrote: > The advantage of the TRACED_VARARGS approach (or leaving it as-is) is that > there are limited APIs and callsites affected (only 1 of each in this > review, but it's unclear to me if you have more of these changes coming). > > Chris > > On 4/29/19 9:49 PM, Jean Christophe Beyler wrote: > > Yes I would fix them all in the next webrev and then continue the porting. > I 100% agree to which is less offensive. I find that > > 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, > methodID, className); > > to be offensive as well. > > So perhaps the TRACED_VARARGS is best: > > > 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, > TRACED_VARARGS(className)); > > What do you think? > > > On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer > wrote: > >> Hi JC, >> >> On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: >> >> Hi Chris, >> >> I agree it's not ideal, how about putting it first? >> >> 73 loadedClass = (jclass) >> jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); >> >> It's not consistent with other uses, or are you suggesting changing them >> all? >> >> >> I find that less awkward than the VAR_ARGS, no? >> >> Or something like: >> 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, >> methodID, className); >> >> Where CallObjectMethodTraced is actually a define in the exception >> handling system that adds the line and filename... >> >> I don't like macroizing a method call in this manner (macros should be >> all upper case, right?). Also it's inconsistent with the other tracing >> calls, unless you plan on doing it to all of them. >> >> >> Which looks better? >> >> Not sure. I wouldn't ask which is better. I'd ask which is less >> offensive. :) >> >> thanks, >> >> Chris >> >> >> Thanks again, >> Jc >> >> On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer >> wrote: >> >>> Ok. I only half heatedly suggest the following >>> >>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>> methodID, VAR_ARGS(className)); >>> >>> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >>> >>> Chris >>> >>> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >>> >>> Hi Chris, >>> >>> Thanks for the review! It is the only issue I have with the system now >>> and I had not found a good solution for: >>> >>> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL at >>> the end; so I put right before the end; that allows me to do this: >>> >>> >>> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >>> >>> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >>> >>> Do you have any better suggestion? >>> >>> Thanks! >>> >>> Jc >>> >>> >>> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer >>> wrote: >>> >>>> Hi JC, >>>> >>>> In em01t002.cpp, is this correct? >>>> >>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>> methodID, TRACE_JNI_CALL, className); >>>> >>>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into why >>>> this test didn't fail as a result. >>>> >>>> Other than that the changes look good. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>>> >>>> Hi all, >>>> >>>> (Re-sending with subject line complete :-)) >>>> >>>> Since JDK-8213501 finally merged (sorry it took so long), I am able to >>>> continue this work. Here is the work that puts back the messages for any >>>> calls that were moved around due to JDK-8212884. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>>> >>>> All modified tests pass on my local dev machine. >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Apr 30 18:26:10 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Apr 2019 11:26:10 -0700 Subject: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed In-Reply-To: References: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> <1f247f0c-7581-9125-8fac-55116795dbd4@oracle.com> Message-ID: Hi Daniil, Looks good to me. Thanks, Serguei On 4/25/19 7:37 PM, Jean Christophe Beyler wrote: > Hi Daniil, > > Looks good to me too, (thanks for the detailed explanation about the > test failure btw :-)), > Jc > > On Thu, Apr 25, 2019 at 6:43 PM > wrote: > > Looks good. > > dl > > On 4/25/19 6:33 PM, Daniil Titov wrote: > > Please review the change that fixes an intermittent failure of > the test when running with Graal on. > > > > The test creates exception requests for different kinds of > exceptions and errors, starts the debuggee that throws an > exception, and listens for exception events. If the number of > received exception events is not equal to 1 the test fails. For > the case when the exception request is created for java.lang.Error > class? the test intermittently fails if Graal is on. It happens > because, sometimes, in addition to StackOverflowError thrown by > the test itself, jdk.vm.ci.common.JVMCIError is thrown from method > getField() in class jdk.vm.ci.hotspot .HotSpotVMConfigAccess at > line 252 > (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java > ) > > > > 240? ? ? ?private VMField getField(String name, String cppType, > boolean required) { > >? ? ?241? ? ? ? ? ? ? ?VMField entry = store.vmFields.get(name); > >? ? ?242? ? ? ? ? ? ? ?if (entry == null) { > >? ? ?243? ? ? ? ? ? ? ? ? ?if (!required) { > >? ? ?244? ? ? ? ? ? ? ? ? ? ? ?return null; > >? ? ?245? ? ? ? ? ? ? ? ? ?} > >? ? ?246? ? ? ? ? ? ? ? ? ?store.printConfig(); > >? ? ?247? ? ? ? ? ? ? ? ? ?throw new JVMCIError("expected VM > field not found in " + store + ": " + name); > >? ? ?248? ? ? ? ? ? ? ?} > >? ? ?249 > >? ? ?250? ? ? ? ? ? ? ?// Make sure the native type is still the > type we expect. > >? ? ?251? ? ? ? ? ? ? ?if (cppType != null && > !cppType.equals(entry.type)) { > >? ? ?252? ? ? ? ? ? ? ? ? ?throw new JVMCIError("expected type " > + cppType + " but VM field " + name + " is of type " + entry.type); > >? ? ?253? ? ? ? ? ? ? ?} > >? ? ?254? ? ? ? ? ? ? ?return entry; > >? ? ?255? ? ? ? ? ?} > > > > that in one case is caught at line 412 in > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > > >? ? ?404? ? ? ? ? ?public final int pendingFailedSpeculationOffset; > >? ? ?405? ? ? ? ? ?{ > >? ? ?406? ? ? ? ? ? ? ?String name = > "JavaThread::_pending_failed_speculation"; > >? ? ?407? ? ? ? ? ? ? ?int offset = -1; > >? ? ?408? ? ? ? ? ? ? ?try { > >? ? ?409? ? ? ? ? ? ? ? ? ?offset = getFieldOffset(name, > Integer.class, "jlong"); > >? ? ?410? ? ? ? ? ? ? ?} catch (JVMCIError e) { > >? ? ?411? ? ? ? ? ? ? ? ? ?try { > >? ? ?412? ? ? ? ? ? ? ? ? ? ? ?offset = getFieldOffset(name, > Integer.class, "long"); > >? ? ?413? ? ? ? ? ? ? ? ? ?} catch (JVMCIError e2) { > >? ? ?414? ? ? ? ? ? ? ? ? ?} > >? ? ?415? ? ? ? ? ? ? ?} > >? ? ?416? ? ? ? ? ? ? ?if (offset == -1) { > >? ? ?417? ? ? ? ? ? ? ? ? ?throw new JVMCIError("cannot get > offset of field " + name + " with type long or jlong"); > >? ? ?418? ? ? ? ? ? ? ?} > >? ? ?419? ? ? ? ? ? ? ?pendingFailedSpeculationOffset = offset; > >? ? ?420? ? ? ? ? ?} > > > > and in other case at line 229 in the same class > (src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java) > > > > 221? ? ? ?public final int classMirrorOffset; > >? ? ?222? ? ? ? ? ?{ > >? ? ?223? ? ? ? ? ? ? ?String name = "Klass::_java_mirror"; > >? ? ?224? ? ? ? ? ? ? ?int offset = -1; > >? ? ?225? ? ? ? ? ? ? ?boolean isHandle = false; > >? ? ?226? ? ? ? ? ? ? ?try { > >? ? ?227? ? ? ? ? ? ? ? ? ?offset = getFieldOffset(name, > Integer.class, "oop"); > >? ? ?228? ? ? ? ? ? ? ?} catch (JVMCIError e) { > >? ? ?229 > >? ? ?230? ? ? ? ? ? ? ?} > >? ? ?231? ? ? ? ? ? ? ?if (offset == -1) { > >? ? ?232? ? ? ? ? ? ? ? ? ?try { > >? ? ?233? ? ? ? ? ? ? ? ? ? ? ?offset = getFieldOffset(name, > Integer.class, "jobject"); > >? ? ?234? ? ? ? ? ? ? ? ? ? ? ?isHandle = true; > >? ? ?235? ? ? ? ? ? ? ? ? ?} catch (JVMCIError e) { > >? ? ?236? ? ? ? ? ? ? ? ? ? ? ?try { > >? ? ?237? ? ? ? ? ? ? ? ? ? ? ? ? ?// JDK-8186777 > >? ? ?238? ? ? ? ? ? ? ? ? ? ? ? ? ?offset = getFieldOffset(name, > Integer.class, "OopHandle"); > >? ? ?239? ? ? ? ? ? ? ? ? ? ? ? ? ?isHandle = true; > >? ? ?240? ? ? ? ? ? ? ? ? ? ? ?} catch (JVMCIError e2) { > >? ? ?241? ? ? ? ? ? ? ? ? ? ? ?} > >? ? ?242? ? ? ? ? ? ? ? ? ?} > >? ? ?243? ? ? ? ? ? ? ?} > >? ? ?244? ? ? ? ? ? ? ?if (offset == -1) { > >? ? ?245? ? ? ? ? ? ? ? ? ?throw new JVMCIError("cannot get > offset of field " + name + " with type oop, jobject or OopHandle"); > >? ? ?246? ? ? ? ? ? ? ?} > >? ? ?247? ? ? ? ? ? ? ?classMirrorOffset = offset; > >? ? ?248? ? ? ? ? ? ? ?classMirrorIsHandle = isHandle; > >? ? ?249? ? ? ? ? ?} > > > > That results in the number of received exception events exceeds > 1 and the test fails. > > > > To ignore these unexpected events the fix adds > "jdk.vm.ci.hotspot.*"? class exclusion filter when it creates an > exception request. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222821/webrev.01/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222821 > > > > Thanks! > > -Daniil > > > > > > > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 30 18:37:17 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 30 Apr 2019 11:37:17 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 30 18:40:26 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 30 Apr 2019 11:40:26 -0700 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: <5CC70F06.1010205@oracle.com> <7ff1ad30-19b0-ff30-00e3-60a1bb4c4b51@oracle.com> Message-ID: On 4/30/19 4:30 AM, Schmelter, Ralf wrote: > Hi Chris. > >> I think print_debug_listen_address() should have some exception checking >> added after the java calls. > That is already done by the CHECK_false macro. It checks if an exception is occurred, and returns with false if this is the case. And depending on how the dcmd was called, this exception is then handled (e.g. if called via jcmd, the exception is printed and if called the jmm_ExecuteDiagnosticCommand method, the exception is delivered to the Java code). Ok. > >> I'm a little unsure why you modified DebugOnCmdStartDCmd to use >> print_debug_listen_address(), but still have a fallback to print the >> specified transport and address. > Yeah, the fallback is really not needed, since the debugger is not listening in this case. I've removed it from the code. > >> If anything I would have written a >> get_debug_listen_address() and used it to verify that the specified and >> actual addresses end up being the same (and then also make >> print_debug_listen_address() use this API). > Because the requested address and the actual address the debugger is listening can be different. In the case of sockets, if you request localhost:0, the system will find an unused port, so the listening address will be the actual port on which we listen. Ok. > >> You need to update copyright date to 2019. > Fixed. > >> Can you write a test for this new dcmd. You can probably just extend >> OnJcmdTest.java. > The GetListenAddressTest tests the new dcmd. Ok. I missed it because when after reviewing the OnJcmdTest.java changes in "frames" mode and then clicking on "next" to review the next file, it returns you to the index. Seems this is normal behavior for new files in webrevs since there is no "frames" mode for them. Changes look good. Chris > > I've updated the webrev (including David's suggestion): http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ > > Best regards, > Ralf From daniil.x.titov at oracle.com Tue Apr 30 20:28:51 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 30 Apr 2019 13:28:51 -0700 Subject: 8222821: com/sun/jdi/ExceptionEvents.java failed In-Reply-To: <67bcaa1a-d7f3-eab1-4826-fa2d6a4f33cf@oracle.com> References: <0C8A7EA5-D032-4842-A5D6-050F102C01DC@oracle.com> <1f247f0c-7581-9125-8fac-55116795dbd4@oracle.com> <67bcaa1a-d7f3-eab1-4826-fa2d6a4f33cf@oracle.com> Message-ID: <2C6101E9-D67D-4105-9CDD-972930BBD420@oracle.com> Thank you, Dean, JC, Chris, and Serguei, for reviewing this change! Best regards, Daniil From: Chris Plummer Date: Tuesday, April 30, 2019 at 11:39 AM To: Daniil Titov Subject: Re: FW: 8222821: com/sun/jdi/ExceptionEvents.java failed Looks good. Chris From: serviceability-dev on behalf of Jean Christophe Beyler Date: Thursday, April 25, 2019 at 7:38 PM To: Cc: OpenJDK Serviceability Subject: Re: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed Hi Daniil, Looks good to me too, (thanks for the detailed explanation about the test failure btw :-)), Jc On Thu, Apr 25, 2019 at 6:43 PM wrote: Looks good. dl On 4/25/19 6:33 PM, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test when running with Graal on. > > The test creates exception requests for different kinds of exceptions and errors, starts the debuggee that throws an exception, and listens for exception events. If the number of received exception events is not equal to 1 the test fails. For the case when the exception request is created for java.lang.Error class the test intermittently fails if Graal is on. It happens because, sometimes, in addition to StackOverflowError thrown by the test itself, jdk.vm.ci.common.JVMCIError is thrown from method getField() in class jdk.vm.ci.hotspot .HotSpotVMConfigAccess at line 252 (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java) > > 240 private VMField getField(String name, String cppType, boolean required) { > 241 VMField entry = store.vmFields.get(name); > 242 if (entry == null) { > 243 if (!required) { > 244 return null; > 245 } > 246 store.printConfig(); > 247 throw new JVMCIError("expected VM field not found in " + store + ": " + name); > 248 } > 249 > 250 // Make sure the native type is still the type we expect. > 251 if (cppType != null && !cppType.equals(entry.type)) { > 252 throw new JVMCIError("expected type " + cppType + " but VM field " + name + " is of type " + entry.type); > 253 } > 254 return entry; > 255 } > > that in one case is caught at line 412 in src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > 404 public final int pendingFailedSpeculationOffset; > 405 { > 406 String name = "JavaThread::_pending_failed_speculation"; > 407 int offset = -1; > 408 try { > 409 offset = getFieldOffset(name, Integer.class, "jlong"); > 410 } catch (JVMCIError e) { > 411 try { > 412 offset = getFieldOffset(name, Integer.class, "long"); > 413 } catch (JVMCIError e2) { > 414 } > 415 } > 416 if (offset == -1) { > 417 throw new JVMCIError("cannot get offset of field " + name + " with type long or jlong"); > 418 } > 419 pendingFailedSpeculationOffset = offset; > 420 } > > and in other case at line 229 in the same class (src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java) > > 221 public final int classMirrorOffset; > 222 { > 223 String name = "Klass::_java_mirror"; > 224 int offset = -1; > 225 boolean isHandle = false; > 226 try { > 227 offset = getFieldOffset(name, Integer.class, "oop"); > 228 } catch (JVMCIError e) { > 229 > 230 } > 231 if (offset == -1) { > 232 try { > 233 offset = getFieldOffset(name, Integer.class, "jobject"); > 234 isHandle = true; > 235 } catch (JVMCIError e) { > 236 try { > 237 // JDK-8186777 > 238 offset = getFieldOffset(name, Integer.class, "OopHandle"); > 239 isHandle = true; > 240 } catch (JVMCIError e2) { > 241 } > 242 } > 243 } > 244 if (offset == -1) { > 245 throw new JVMCIError("cannot get offset of field " + name + " with type oop, jobject or OopHandle"); > 246 } > 247 classMirrorOffset = offset; > 248 classMirrorIsHandle = isHandle; > 249 } > > That results in the number of received exception events exceeds 1 and the test fails. > > To ignore these unexpected events the fix adds "jdk.vm.ci.hotspot.*" class exclusion filter when it creates an exception request. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222821/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222821 > > Thanks! > -Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: serguei.spitsyn at oracle.com Subject: Re: RFR: 8222821: com/sun/jdi/ExceptionEvents.java failed Date: Tue, 30 Apr 2019 11:26:10 -0700 Size: 27453 URL: From jcbeyler at google.com Tue Apr 30 22:36:28 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 15:36:28 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> Message-ID: You are right I was overthinking the naming, so I did this now: - loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, TRACE_JNI_CALL, className); + loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, TRACE_VARARGS(className)); Question now is: this variadic won't work if there are no arguments in a portable way, so if there are no arguments for the call, should we use a TRACE_JNI_CALL such as: jni_env->CallVoidMethod(thread, methodID, TRACE_JNI_CALL); or should I create a TRACE_VARARGS for no arguments: jni_env->CallVoidMethod(thread, methodID, TRACE_EMPTY_VARARGS()); Advantage of the latter is that you would know it is a VARARG at least and you can see it; draw-back is yet another macro. What do you think? Jc On Tue, Apr 30, 2019 at 11:37 AM Chris Plummer wrote: > Hi JC, > > I'm not sure why you are suggesting TRACED_JNI_CALL instead of > TRACED_VARARGS. How are they different? Are you suggesting non-varargs > calls would just end up using an empty TRACED_JNI_CALL()? > > Chris > > On 4/30/19 10:05 AM, Jean Christophe Beyler wrote: > > I do have more of these coming and there are 86 CallXMethod cases where > this will occur and 49 NewObject cases. So it would be good to figure out > something that does not hurt our eyes too many times. > > I think I would go with the TRACED_VARARGS, it at least has the advantage > of not being too bad. I would move toward doing: > 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, > TRACED_JNI_CALL(className)); > > To be consisted with the non-vararg cases, what do you think? > > Jc > > On Tue, Apr 30, 2019 at 9:51 AM Chris Plummer > wrote: > >> The advantage of the TRACED_VARARGS approach (or leaving it as-is) is >> that there are limited APIs and callsites affected (only 1 of each in this >> review, but it's unclear to me if you have more of these changes coming). >> >> Chris >> >> On 4/29/19 9:49 PM, Jean Christophe Beyler wrote: >> >> Yes I would fix them all in the next webrev and then continue the >> porting. I 100% agree to which is less offensive. I find that >> >> 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, >> methodID, className); >> >> to be offensive as well. >> >> So perhaps the TRACED_VARARGS is best: >> >> >> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >> methodID, TRACED_VARARGS(className)); >> >> What do you think? >> >> >> On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: >>> >>> Hi Chris, >>> >>> I agree it's not ideal, how about putting it first? >>> >>> 73 loadedClass = (jclass) >>> jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); >>> >>> It's not consistent with other uses, or are you suggesting changing them >>> all? >>> >>> >>> I find that less awkward than the VAR_ARGS, no? >>> >>> Or something like: >>> 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, >>> methodID, className); >>> >>> Where CallObjectMethodTraced is actually a define in the exception >>> handling system that adds the line and filename... >>> >>> I don't like macroizing a method call in this manner (macros should be >>> all upper case, right?). Also it's inconsistent with the other tracing >>> calls, unless you plan on doing it to all of them. >>> >>> >>> Which looks better? >>> >>> Not sure. I wouldn't ask which is better. I'd ask which is less >>> offensive. :) >>> >>> thanks, >>> >>> Chris >>> >>> >>> Thanks again, >>> Jc >>> >>> On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer >>> wrote: >>> >>>> Ok. I only half heatedly suggest the following >>>> >>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>> methodID, VAR_ARGS(className)); >>>> >>>> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >>>> >>>> Chris >>>> >>>> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >>>> >>>> Hi Chris, >>>> >>>> Thanks for the review! It is the only issue I have with the system now >>>> and I had not found a good solution for: >>>> >>>> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL at >>>> the end; so I put right before the end; that allows me to do this: >>>> >>>> >>>> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >>>> >>>> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >>>> >>>> Do you have any better suggestion? >>>> >>>> Thanks! >>>> >>>> Jc >>>> >>>> >>>> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer < >>>> chris.plummer at oracle.com> wrote: >>>> >>>>> Hi JC, >>>>> >>>>> In em01t002.cpp, is this correct? >>>>> >>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>> methodID, TRACE_JNI_CALL, className); >>>>> >>>>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into why >>>>> this test didn't fail as a result. >>>>> >>>>> Other than that the changes look good. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>>>> >>>>> Hi all, >>>>> >>>>> (Re-sending with subject line complete :-)) >>>>> >>>>> Since JDK-8213501 finally merged (sorry it took so long), I am able to >>>>> continue this work. Here is the work that puts back the messages for any >>>>> calls that were moved around due to JDK-8212884. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>>>> >>>>> All modified tests pass on my local dev machine. >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Apr 30 22:46:00 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 30 Apr 2019 15:46:00 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> Message-ID: <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 30 22:47:33 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 15:47:33 -0700 Subject: RFR (M) 8223040: Add a AGCT test Message-ID: Hi all, As I start looking at working on the AGCT bugs, I wanted to at least start creating a baseline of tests for AGCT. This is an attempt to just have a "base" test (and infrastructure) that tries to call AGCT and get back some sane information. Next step will be to add a few more tests that will be exposing the limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for example. Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 This passed the test on my linux machine (the test is only for linux due to the dlsym) and the submit-repo. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Apr 30 23:59:24 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 16:59:24 -0700 Subject: RFR (S) Message-ID: Hi all, I figured out the problem for this test bug, I put additional data in the bug itself for tracking. Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 Note: If this solution is ok to all, I'll drop the problem list webrev and push this one; if this lingers and I get LGTMs for the problem list, I'll push that one and then we can work out this problem/solution. (I've tested this as much as I could and have pushed this on the submit-repo but I'm unsure that would test this test on Windows; if someone could test it, that would be perhaps a good idea as well). Thanks for your help, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: