From serguei.spitsyn at oracle.com Wed Nov 1 02:47:40 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 31 Oct 2017 19:47:40 -0700 Subject: [PATCH] Unnecessary Amount Of Internal Class Conversion In-Reply-To: <27fee1e0-4f58-469b-04d9-1e2ffda71731@oracle.com> References: <5b08c7bf-c1df-6ba1-227b-277ec57832a3@oracle.com> <27fee1e0-4f58-469b-04d9-1e2ffda71731@oracle.com> Message-ID: Hi Alan, Sorry for the delay (forgot to push the send button). On 10/30/17 00:52, Alan Bateman wrote: > > > On 27/10/2017 12:08, serguei.spitsyn at oracle.com wrote: >> Let's check if Alan has a time to look at it. >> The patch is not that big. Hi Ben, > There isn't any changes to the hotspot code so one reviewer should be > fine. Ok. I normally push to the jdk10/hs, so that was thinking it is better to have two reviews. > In any case, I looked through it and it seems okay. Ok, I'll add you as a reviewer. > My only comment is that setHasTransformers would be clearer if it were > named something like enableClassFileLoadHook as it just enables or > disables the CFLH. Just enableClassFileLoadHook is not good enough as we enable CFLH events separately for retransformable and non-retransformable environments. The name setHasTransformers looks Ok to me as it signals about the status change that causes enabling the CFLH events. I'd suggest to keep it as it is for now. Please, let me know if it is Ok with you. > I realize this would mean find a better name for > setHasRetransformableTransformers too. Right. Thanks, Serguei > > -Alan From yasuenag at gmail.com Wed Nov 1 12:58:37 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 1 Nov 2017 21:58:37 +0900 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> Message-ID: <0138549d-340a-f552-1355-1817b2190426@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ Thanks, Yasumasa On 2017/10/09 23:19, Yasumasa Suenaga wrote: > Hi all, > > I uploaded new webrev to be adapted to current jdk10/hs: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ > > > Please review and sponsor it. > > > Thanks, > > Yasumasa > > > On 2017/09/27 0:31, Yasumasa Suenaga wrote: >> Hi all, >> >> I uploaded new webrev to be adapted to jdk10/hs: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>> Thanks Jini! >>> >>> I uploaded new webrev: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>> >>> This webrev has been ported print_lock_info() to JavaVFrame.java, and I've added new testcase for `jhsdb jstack` and jstack command on `jhsdb clhsdb`. >>> >>> >>> Yasumasa >>> >>> >>> On 2017/08/24 18:01, Jini George wrote: >>>> Apologize for the late reply, Yasumasa. >>>> >>>> >>>>> I think so, but I guess it is difficult. >>>>> For example, test for CLHSDB command is provided as test/serviceability/sa/TestPrintMdo.java . >>>>> But target process seems to be fixed to "LingeredApp". >>>>> Can we change it to another program which generates lock contention? >>>> >>>> You can take a look at any of the hotspot/test/serviceability/sa/LingeredAppWith*.java files for this. The target process does not have to be be fixed to LingeredApp -- in these LingeredAppWith* cases, the targets are test-specific variations built on top of LingeredApp for ease of implementation. >>>> >>>> Thanks, >>>> Jini. From yasuenag at gmail.com Wed Nov 1 12:59:45 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 1 Nov 2017 21:59:45 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: Message-ID: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ Thanks, Yasumasa On 2017/09/29 13:24, Yasumasa Suenaga wrote: > Hi all, > > If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we > will get "Command executed successfully". However, it implies error in > JVMTIAgentLoadDCmd. > This message is from JCmd.java when jcmd does not receive any output > from target VM. > > I think HotSopt/jcmd should return useful error message to users to > understand the cause of failure. > > I uploaded webrev for this issue. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ > > > This change is work fine on Fedora 26 x86_64 as following jtreg testcases: > > - hotspot/jtreg/serviceability/attach > - hotspot/jtreg/serviceability/dcmd/jvmti > - jdk/com/sun/tools/attach > > I cannot access JPRT. So I need a sponsor. > (I cannot test it on other platforms.) > > > Thanks, > > Yasumasa > From yasuenag at gmail.com Wed Nov 1 13:02:40 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 1 Nov 2017 22:02:40 +0900 Subject: PING: RFR: JDK-8153333: [REDO] STW phases at Concurrent GC should count in PerfCounter In-Reply-To: References: <2f4e0901-1602-6276-e7fd-84e168e7b317@gmail.com> Message-ID: PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.04/ Also I need JPRT results of this change. Could you cooperate? Thanks, Yasumasa On 2017/09/27 0:08, Yasumasa Suenaga wrote: > Hi all, > > I uploaded new webrev to be adapted to jdk10/hs: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.04/ > > I want to check this patch via JPRT, but I cannot access it. > Could you cooperate? > > > Thanks, > > yasumasa > > > On 2017/09/21 7:46, Yasumasa Suenaga wrote: >> PING: >> >> Have you checked this issue? >> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ >> >> >> Yasumasa >> >> >> On 2017/07/01 23:44, Yasumasa Suenaga wrote: >>> PING: >>> >>> Have you checked this issue? >>> >>> >>> Yasumasa >>> >>> >>> On 2017/06/14 13:22, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I changed PerfCounter to show CGC STW phase in jstat in JDK-8151674. >>>> However, it occurred several jtreg test failure, so it was back-outed. >>>> >>>> I want to resume to work for this issue. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153333/webrev.03/jdk/ >>>> >>>> These changes are work fine on jtreg test as below: >>>> >>>> ?? hotspot/test/serviceability/tmtools/jstat >>>> ?? jdk/test/sun/tools >>>> >>>> >>>> Since JDK 9, default GC algorithm is set to G1. >>>> So I think this change is useful to watch GC behavior through jstat. >>>> >>>> I cannot access JPRT. Could you help? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> From Roger.Riggs at Oracle.com Wed Nov 1 15:18:32 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 1 Nov 2017 11:18:32 -0400 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <6a193cdf-efea-e4e9-4faf-72d8960cd72b@Oracle.com> <0483f2c9-892e-f842-bb5f-2b522b81b199@oracle.com> <6ec697c3-cb0d-ef5b-4a0c-e26e0cfc92b0@Oracle.com> <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: <356108c0-6215-d991-17f6-3a2140f3e7d0@Oracle.com> Hi Harsha, Sorry for the late editorial recommendations: In jmxremote.password.template: 41: "Clear text" -> "A clear text" 43: 'below format" -> "format below" 53: "in clear" -> "in the clear" 63: "in clear" -> "in the clear" 77: "by ONLY the owner" -> "ONLY by the owner" 80-81: Is not consistent with the 77-78;? 80-81 can be removed 82: "should" -> "must" to be consistent with 77: 82: "except for owner" ->? "ONLY by the owner" 92: should end with "." or ':" 97: "passwords will" -> "the passwords will" 98: "below entries with clear" -> "the entries below with the clear" 99: "should end with "." or ":" management.properties: 311: sentence should end with "." Thanks, Roger On 10/31/2017 1:07 PM, mandy chung wrote: > > > On 10/31/17 8:55 AM, Harsha Wardhana B wrote: >> >> Hi Mandy, >> >> Below is the new webrev incorporating below review comments. >> >> http://cr.openjdk.java.net/~hb/5016517/webrev.06/ > > Looks okay in general except this: > 286 // Check if header needs to be inserted > 287 if (sbuf.indexOf("# The passwords in this file are hashed") != 0) { > 288 String lastUpdated = "# file last updated on - " > 289 + new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new Date()) + "\n\n"; > 290 sbuf.insert(0, header + lastUpdated); > 291 } > > Relying on matching the partial header string is fragile. > Also the timestamp is not updated if the file contains such > heading but the file is re-written again. > > You should probably drop the header (auto-inserted), not add > it to sbuf, and always add the header when updating the > password file. > > Mandy > From daniel.fuchs at oracle.com Wed Nov 1 16:12:27 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 1 Nov 2017 16:12:27 +0000 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <6a193cdf-efea-e4e9-4faf-72d8960cd72b@Oracle.com> <0483f2c9-892e-f842-bb5f-2b522b81b199@oracle.com> <6ec697c3-cb0d-ef5b-4a0c-e26e0cfc92b0@Oracle.com> <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: On 31/10/2017 17:07, mandy chung wrote: > On 10/31/17 8:55 AM, Harsha Wardhana B wrote: >> >> Hi Mandy, >> >> Below is the new webrev incorporating below review comments. >> >> http://cr.openjdk.java.net/~hb/5016517/webrev.06/ > > Looks okay in general except this: > > 286 // Check if header needs to be inserted > 287 if (sbuf.indexOf("# The passwords in this file are hashed") != 0) { > 288 String lastUpdated = "# file last updated on - " > 289 + new SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new Date()) + "\n\n"; > 290 sbuf.insert(0, header + lastUpdated); > 291 } > > Relying on matching the partial header string is fragile. > Also the timestamp is not updated if the file contains such > heading but the file is re-written again. > > You should probably drop the header (auto-inserted), not add > it to sbuf, and always add the header when updating the > password file. Sorry Mandy, that was my demand. The header is several lines long. It will look strange if it's added several times to the password file every time the user/administrator adds/changes a password. Concerning FileLock - I'm not an expert there, but the Javadoc says: https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileLock.html "File locks are held on behalf of the entire Java virtual machine. They are not suitable for controlling access to a file by multiple threads within the same virtual machine." Which means you need to also protect against concurrent writes to the same file from within the same JVM by some other means. Also I wonder if HashedPasswordManager.authenticate should take a char[] array rather than a String for the password. best regards, -- daniel > > Mandy > From jcbeyler at google.com Wed Nov 1 17:46:31 2017 From: jcbeyler at google.com (JC Beyler) Date: Wed, 1 Nov 2017 10:46:31 -0700 Subject: Low-Overhead Heap Profiling In-Reply-To: <1508935388.13554.11.camel@oracle.com> References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> Message-ID: Dear all, Here is the next webrev: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ Incremental since the rebase: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ (I'm still not too familiar with hg so I had to do a fresh rebase so v14 is once the rebase was done and v14a integrates the changes requested from Thomas). I have also inlined answers to Thomas' email: > > A few minor issues: > > - weak reference handling has been factored out in JDK-8189359, now > you only need to add the additions required for this change to one > place. :) Please update the webrev :) > > That is awesome and very happily done :) > - the one issue Robin noticed. > > - in the declaration of CollectedHeap::sample_allocation, it would be > nice if the fix_sample_rate parameter would be described - it takes a > time to figure out what it's used for. I.e. in case an allocation goes > beyond the sampling watermark, this value which represents the amount > of overallocation is used to adjust the next sampling watermark to > sample at the correct rate. > Something like this - and if what I wrote is incorrect, there is even > more reason to document it. > Or maybe just renaming "fix_sample_rate" to something more descriptive > - but I have no good idea about that. > With lack of units in the type, it would also be nice to have the unit > in the identifier name, as done elsewhere. > Done for Robbin's issue and changed it to > > - some (or most actually) of the new setters and getters in the > ThreadLocalAllocBuffer class could be private I think. Also, we > typically do not use "simple" getters that just return a member in the > class where they are defined. > I removed all that were not used that I could see (not used outside the class) moved the ones that are not simple to private if they could be. I think it's a bit weird because now some of the setting of the tlab internal data is using methods, others are directly setting. Let me know what you think. > > - ThreadLocalAllocBuffer::set_sample_end(): please use > pointer_delta() for pointer subtractions. > Done! > > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making the > first check an assert - it seems that it is only useful to call this > with heap monitoring enabled, as is done right now. > Longer conversation below about this, It cannot be an assert (I could remove the test altogether though). > > - ThreadLocalAllocBuffer::pick_next_sample() - please use > "PTR_FORMAT" (or INTPTR_FORMAT - they are the same) as format string > for printing pointer values as is customary within Hotspot. %p output > is OS dependent. I.e. I heard that e.g. on Ubuntu it prints "null" > instead of 0x0...0 .... which is kind of annoying. > Done :) > > - personal preference: do not allocate > HeapMonitoring::AlwaysTrueClosure globally, but only locally when it's > used. Setting it up seems to be very cheap. > Done! > > - HeapMonitoring::next_random() - the different names for the > constants use different formatting. Preferable (to me) is > UpperCamelCase, but at least make them uniform. > > I think done the way you wanted! > - in HeapMonitoring::next_random(), you might want to use > right_n_bits() to create your mask. Done! > > - not really convinced that it is a good idea to not somehow guard > StartHeapSampling() and StopHeapSampling() against being called by > multiple threads. > > I added another mutex for the start/stop so that way it will protect from that. > Otherwise looks okay from what I can see. > Awesome, what do you think I still need for this before going to the next step (which is what by the way? :)). --------------- Ok now the longer conversation about this remark: > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making the > first check an assert - it seems that it is only useful to call this > with heap monitoring enabled, as is done right now. > You can't do this right now because this is how the mutexes work right now to ensure we allow things to work fast but safely: I) Background before I go into details 1) You can turn on/off whenever you like; which flips the switch of the HeapMonitoring::enabled() method. 2) When you hit the end of a tlab, you go to the slow path, check HeapMonitoring::enabled() 3) Later in the handling of the sample if enabled() returned true, you get to the point of choosing a new sampling rate Now imagine we have two threads A & B and imagine that enabled is currently returning true. Here is a series of events: i) Thread A hits the end of tlab, checks enabled at entrance, gets a stack ii) Meanwhile, Thread B turned off HeapMonitoring iii) Thread A now goes to pick a new sample rate and is going to check HeapMonitoring::enabled If put as an assert, clearly (iii) will fail, we don't want this. II) So it this really an issue? Is there something really broken? Not really, I can go into a bigger explanation as to why but really it boils down to: - Tlab asks the HeapMonitoring system if it should try to sample and thus move its end pointer a bit for the next sample - If it "missed" a disable event, it will try to sample, find out monitoring is disabled and just not pick a sample. - If it did the sample and sends it to HeapMonitoring, HeapMonitoring just ignores it and TLab goes back to do its thing Because of this producer/consumer relationship between Tlab and HeapMonitoring, there is no real need to ensure that we are not in a specific part of the code. The thread sensitive data that could get corrupted is in HeapMonitoring and guarded by a specific lock, the rest of it will just result in a bit of extra useless work but won't provoke an race issue. I put a few extra checks for the HeapMonitoring::enabled because they allow a quick exit of sampling but to be honest, we could check at the entrance of the code path and if ever it got disabled then we are really only sampling one extra object that will get discarded. Thanks for looking as always, welcome back and let me know if there are any other concerns/questions/criticisms, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Nov 1 19:11:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 Nov 2017 12:11:25 -0700 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: <44bb3285-702f-19dd-0dc1-481cab42ac1f@oracle.com> An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Thu Nov 2 03:55:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 23:55:18 -0400 Subject: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0@redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE@oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d@redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F@oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7@oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af@redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I?ll take care of it, but not today. From jini.george at oracle.com Thu Nov 2 04:54:03 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 2 Nov 2017 10:24:03 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From shafi.s.ahmad at oracle.com Thu Nov 2 06:19:00 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 1 Nov 2017 23:19:00 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: <43948d91-7145-0627-62e5-8ed875183a3a@oracle.com> References: <43948d91-7145-0627-62e5-8ed875183a3a@oracle.com> Message-ID: Hi All, May get the second review for this backport. Regards, Shafi > -----Original Message----- > From: Daniel Fuchs > Sent: Wednesday, October 25, 2017 2:34 PM > To: Shafi Ahmad ; serviceability- > dev at openjdk.java.net > Cc: David Holmes > Subject: Re: [8u] RFR for backport of JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > Hi Shafi, > > If I compare your webrev [1] with the JDK 9 changeset [2] then this looks OK > to me. > > best regards, > > -- daniel > > [1] http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ > [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/9c9b8a48cd4a > > On 25/10/2017 09:11, Shafi Ahmad wrote: > > Hi, > > > > Please review the backport of "JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent()" to jdk8u-dev. > > > > The backport is not clean as I got the below conflict. > > shshahma at slc12kkg:/scratch/shshahma/Java/jdk8u-dev/jdk$ cat > > src/share/classes/sun/management/Agent.java.rej > > --- Agent.java > > +++ Agent.java > > @@ -665,18 +665,6 @@ > > throw new RuntimeException(keyText); > > } > > > > - public static void error(String key, String[] params) { > > - if (params == null || params.length == 0) { > > - error(key); > > - } else { > > - StringBuilder message = new StringBuilder(params[0]); > > - for (int i = 1; i < params.length; i++) { > > - message.append(' ').append(params[i]); > > - } > > - error(key, message.toString()); > > - } > > - } > > - > > public static void error(String key, String message) { > > String keyText = getText(key); > > System.err.print(getText("agent.err.error") + ": " + > > keyText); > > > > Webrev: > http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ > > Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 > > Jdk9 review: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/0 > > 21188.html > > > > Testing: jprt and jtreg test. > > > > > > Regards, > > Shafi > > > From david.holmes at oracle.com Thu Nov 2 06:25:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Nov 2017 16:25:26 +1000 Subject: [8u] RFR for backport of JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: <43948d91-7145-0627-62e5-8ed875183a3a@oracle.com> Message-ID: On 2/11/2017 4:19 PM, Shafi Ahmad wrote: > Hi All, > > May get the second review for this backport. Not sure a second one is needed for a backport like this, but I concur with Daniel that the changes match the original changeset. :) Thanks, David > Regards, > Shafi > >> -----Original Message----- >> From: Daniel Fuchs >> Sent: Wednesday, October 25, 2017 2:34 PM >> To: Shafi Ahmad ; serviceability- >> dev at openjdk.java.net >> Cc: David Holmes >> Subject: Re: [8u] RFR for backport of JDK-8177721: Improve diagnostics in >> sun.management.Agent#startAgent() >> >> Hi Shafi, >> >> If I compare your webrev [1] with the JDK 9 changeset [2] then this looks OK >> to me. >> >> best regards, >> >> -- daniel >> >> [1] http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ >> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/9c9b8a48cd4a >> >> On 25/10/2017 09:11, Shafi Ahmad wrote: >>> Hi, >>> >>> Please review the backport of "JDK-8177721: Improve diagnostics in >> sun.management.Agent#startAgent()" to jdk8u-dev. >>> >>> The backport is not clean as I got the below conflict. >>> shshahma at slc12kkg:/scratch/shshahma/Java/jdk8u-dev/jdk$ cat >>> src/share/classes/sun/management/Agent.java.rej >>> --- Agent.java >>> +++ Agent.java >>> @@ -665,18 +665,6 @@ >>> throw new RuntimeException(keyText); >>> } >>> >>> - public static void error(String key, String[] params) { >>> - if (params == null || params.length == 0) { >>> - error(key); >>> - } else { >>> - StringBuilder message = new StringBuilder(params[0]); >>> - for (int i = 1; i < params.length; i++) { >>> - message.append(' ').append(params[i]); >>> - } >>> - error(key, message.toString()); >>> - } >>> - } >>> - >>> public static void error(String key, String message) { >>> String keyText = getText(key); >>> System.err.print(getText("agent.err.error") + ": " + >>> keyText); >>> >>> Webrev: >> http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ >>> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 >>> Jdk9 review: >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April/0 >>> 21188.html >>> >>> Testing: jprt and jtreg test. >>> >>> >>> Regards, >>> Shafi >>> >> From shafi.s.ahmad at oracle.com Thu Nov 2 06:37:50 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Wed, 1 Nov 2017 23:37:50 -0700 (PDT) Subject: [8u] RFR for backport of JDK-8177721: Improve diagnostics in sun.management.Agent#startAgent() In-Reply-To: References: <43948d91-7145-0627-62e5-8ed875183a3a@oracle.com> Message-ID: Thank you David. Regards, Shafi > -----Original Message----- > From: David Holmes > Sent: Thursday, November 02, 2017 11:55 AM > To: Shafi Ahmad ; Daniel Fuchs > ; serviceability-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of JDK-8177721: Improve diagnostics in > sun.management.Agent#startAgent() > > On 2/11/2017 4:19 PM, Shafi Ahmad wrote: > > Hi All, > > > > May get the second review for this backport. > > Not sure a second one is needed for a backport like this, but I concur with > Daniel that the changes match the original changeset. :) > > Thanks, > David > > > Regards, > > Shafi > > > >> -----Original Message----- > >> From: Daniel Fuchs > >> Sent: Wednesday, October 25, 2017 2:34 PM > >> To: Shafi Ahmad ; serviceability- > >> dev at openjdk.java.net > >> Cc: David Holmes > >> Subject: Re: [8u] RFR for backport of JDK-8177721: Improve > >> diagnostics in > >> sun.management.Agent#startAgent() > >> > >> Hi Shafi, > >> > >> If I compare your webrev [1] with the JDK 9 changeset [2] then this > >> looks OK to me. > >> > >> best regards, > >> > >> -- daniel > >> > >> [1] http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ > >> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/9c9b8a48cd4a > >> > >> On 25/10/2017 09:11, Shafi Ahmad wrote: > >>> Hi, > >>> > >>> Please review the backport of "JDK-8177721: Improve diagnostics in > >> sun.management.Agent#startAgent()" to jdk8u-dev. > >>> > >>> The backport is not clean as I got the below conflict. > >>> shshahma at slc12kkg:/scratch/shshahma/Java/jdk8u-dev/jdk$ cat > >>> src/share/classes/sun/management/Agent.java.rej > >>> --- Agent.java > >>> +++ Agent.java > >>> @@ -665,18 +665,6 @@ > >>> throw new RuntimeException(keyText); > >>> } > >>> > >>> - public static void error(String key, String[] params) { > >>> - if (params == null || params.length == 0) { > >>> - error(key); > >>> - } else { > >>> - StringBuilder message = new StringBuilder(params[0]); > >>> - for (int i = 1; i < params.length; i++) { > >>> - message.append(' ').append(params[i]); > >>> - } > >>> - error(key, message.toString()); > >>> - } > >>> - } > >>> - > >>> public static void error(String key, String message) { > >>> String keyText = getText(key); > >>> System.err.print(getText("agent.err.error") + ": " + > >>> keyText); > >>> > >>> Webrev: > >> http://cr.openjdk.java.net/~shshahma/8177721/jdk8u/webrev.00/ > >>> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8177721 > >>> Jdk9 review: > >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-April > >>> /0 > >>> 21188.html > >>> > >>> Testing: jprt and jtreg test. > >>> > >>> > >>> Regards, > >>> Shafi > >>> > >> From kim.barrett at oracle.com Thu Nov 2 03:55:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 23:55:18 -0400 Subject: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0@redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE@oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d@redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F@oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7@oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af@redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoABe99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEMtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 6197 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-Sa for lutz.schmidt at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldABsdXR6LnNjaG1pZHRAc2FwLmNvbQAyOGI5N2YxOWY4YWI5YmI2NzdkMmYyYzM2ZTRjM2IyYjQ1MDJiM2Qw X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.1753 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: eaf2ee3e-0520-485b-8f97-08d521a5a149 X-MS-Exchange-Organization-OriginalSize: 5875 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE306.842|UTH=0.001|RST306.826|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.004|CAT=0.005;2017-11-02T07:37:47.017Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoABu99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEQtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.20 X-EndOfInjectedXHeaders: 6211 Received: from mx.expurgate.net (195.190.135.20) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-UG for richard.reingruber at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldAByaWNoYXJkLnJlaW5ncnViZXJAc2FwLmNvbQAzNDY0MmI0NTU3YmJiZjA2MzM3OGIxODJkZTI3ZDRiNzBhN2NmMTgx X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.2378 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.20 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: ab8b4fac-2077-4acc-b6a2-08d521a5a150 X-MS-Exchange-Organization-OriginalSize: 5889 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE306.780|UTH=0.001|RST306.780|CATCM-McAfeeTxRoutingAgent=0.003|CATCM=0.003|CAT=0.004;2017-11-02T07:37:47.017Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAB+99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEUtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 6210 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-Ue for andreas.schoesser at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldABhbmRyZWFzLnNjaG9lc3NlckBzYXAuY29tAGUyNmJmMTkzN2NiZDI0ODcyYjIwYmI5Y2Q4NTFmNjhiZDBlNGY3ZDMX-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.2378 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 7c025af1-fe7b-4811-18fd-08d521a5a153 X-MS-Exchange-Organization-OriginalSize: 5888 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE306.780|UTH=0.001|RST306.780|CATCM-McAfeeTxRoutingAgent=0.002|CATCM=0.003|CAT=0.004;2017-11-02T07:37:47.017Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoACu99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEctAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.20 X-EndOfInjectedXHeaders: 6364 Received: from mx.expurgate.net (194.145.224.20) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:01 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bo-0001O1-Ub for christoph.langer at sap.com; Thu, 02 Nov 2017 04:56:00 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59fa974d-6357-c0a8029709dd-8d927ee5e109-3 for ; Thu, 02 Nov 2017 04:56:00 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_14a7_35924fc9_1f5e_4fc0_bc92_145b060d2997; Thu, 02 Nov 2017 03:55:42 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 0EE61229BE5; Thu, 2 Nov 2017 03:58:44 +0000 (UTC) X-Original-To: serviceability-dev at openjdk.java.net Delivered-To: serviceability-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: serviceability-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: serviceability-dev-bounces at openjdk.java.net Sender: serviceability-dev X-purgate-ID: tlsNG-38ea93/1509594960-00006357-0E5687D9/0/0 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AHNlcnZpY2VhYmlsaXR5LWRldi1ib3VuY2VzQG9wZW5qZGsuamF2YS5uZXQAY2hyaXN0b3BoLmxhbmdlckBzYXAuY29tAGU4NmM0NmM1MGZmM2E4OGQ3MDkyOTM4ZGViZGU0OWMzNTJhZWQxZWUX-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-Spam-Status: clean X-SAP-SPAM-Status: clean Return-Path: serviceability-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:01.2691 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.20 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: b6dd3e1a-de24-485a-11e5-08d521a5a1ee X-MS-Exchange-Organization-OriginalSize: 6042 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE305.748|UTH=0.001|RST305.748|CATCM-McAfeeTxRoutingAgent=0.001|CATCM=0.001|CAT=0.002;2017-11-02T07:37:47.017Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. From kim.barrett at oracle.com Thu Nov 2 03:55:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Nov 2017 23:55:18 -0400 Subject: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0@redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE@oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d@redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F@oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7@oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af@redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoABe99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEMtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 6197 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-Sa for lutz.schmidt at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldABsdXR6LnNjaG1pZHRAc2FwLmNvbQAyOGI5N2YxOWY4YWI5YmI2NzdkMmYyYzM2ZTRjM2IyYjQ1MDJiM2Qw X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.1753 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: eaf2ee3e-0520-485b-8f97-08d521a5a149 X-MS-Exchange-Organization-OriginalSize: 5875 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE488.529|UTH=0.001|RST488.529|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.004|CAT=0.005;2017-11-02T08:14:08.704Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoABu99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEQtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.20 X-EndOfInjectedXHeaders: 6211 Received: from mx.expurgate.net (195.190.135.20) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-UG for richard.reingruber at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldAByaWNoYXJkLnJlaW5ncnViZXJAc2FwLmNvbQAzNDY0MmI0NTU3YmJiZjA2MzM3OGIxODJkZTI3ZDRiNzBhN2NmMTgx X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.2378 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.20 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: ab8b4fac-2077-4acc-b6a2-08d521a5a150 X-MS-Exchange-Organization-OriginalSize: 5889 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE488.467|UTH=0.001|RST488.467|CATCM-McAfeeTxRoutingAgent=0.003|CATCM=0.003|CAT=0.004;2017-11-02T08:14:08.704Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAB+99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEUtAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 6210 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:00 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bn-0005xQ-Ue for andreas.schoesser at sap.com; Thu, 02 Nov 2017 04:55:59 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59fa9749-7c01-c0a8033409dd-8d927ee5f701-3 for ; Thu, 02 Nov 2017 04:55:59 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_148f_284ba7da_f1c2_42cb_9b5d_5aea06abddc2; Thu, 02 Nov 2017 03:55:40 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 9E27E229BE1; Thu, 2 Nov 2017 03:58:43 +0000 (UTC) X-Original-To: hotspot-gc-dev at openjdk.java.net Delivered-To: hotspot-gc-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: hotspot-gc-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot garbage collectors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-gc-dev-bounces at openjdk.java.net Sender: hotspot-gc-dev X-purgate-ID: tlsNG-9b91ac/1509594959-00007C01-CD289925/9/51289 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtZ2MtZGV2LWJvdW5jZXNAb3Blbmpkay5qYXZhLm5ldABhbmRyZWFzLnNjaG9lc3NlckBzYXAuY29tAGUyNmJmMTkzN2NiZDI0ODcyYjIwYmI5Y2Q4NTFmNjhiZDBlNGY3ZDMX-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-gc-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:00.2378 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 7c025af1-fe7b-4811-18fd-08d521a5a153 X-MS-Exchange-Organization-OriginalSize: 5888 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE488.467|UTH=0.001|RST488.467|CATCM-McAfeeTxRoutingAgent=0.002|CATCM=0.002|CAT=0.003;2017-11-02T08:14:08.704Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoACu99Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAEctAAB1AAAABQBkAA8ABAAAAEVkZ2UX-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.20 X-EndOfInjectedXHeaders: 6364 Received: from mx.expurgate.net (194.145.224.20) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 04:56:01 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA6bo-0001O1-Ub for christoph.langer at sap.com; Thu, 02 Nov 2017 04:56:00 +0100 Received: from [141.146.126.229] (helo?sinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59fa974d-6357-c0a8029709dd-8d927ee5e109-3 for ; Thu, 02 Nov 2017 04:56:00 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_14a7_35924fc9_1f5e_4fc0_bc92_145b060d2997; Thu, 02 Nov 2017 03:55:42 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 0EE61229BE5; Thu, 2 Nov 2017 03:58:44 +0000 (UTC) X-Original-To: serviceability-dev at openjdk.java.net Delivered-To: serviceability-dev at openjdk.java.net Received: from acsinet40.oracle.com (acsinet40.oracle.com [141.146.126.228]) by aojmv0009 (Postfix) with ESMTP id A8363229BD3; Thu, 2 Nov 2017 03:58:40 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by acsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,DHE-RSA-AES256-GCM-SHA384) id 4a70_661b_2f0c8545_06c1_4c61_b5b2_6d4f747f2c95; Thu, 02 Nov 2017 03:55:28 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA23tR1Y022085 (version=TLSv1.2 cipher?DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:28 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tRn9028154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits%6 verify=OK); Thu, 2 Nov 2017 03:55:27 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA23tQrb028552; Thu, 2 Nov 2017 03:55:26 GMT Received: from dhcp-10-152-15-141.usdhcp.oraclecorp.com (/10.152.15.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 20:55:26 -0700 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass From: Kim Barrett In-Reply-To: <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> Date: Wed, 1 Nov 2017 23:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98 at oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0 at redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE at oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d at redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F at oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7 at oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af at redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb at redhat.com> To: Roman Kennke X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] CC: , hotspot-gc-dev openjdk.java.net X-BeenThere: serviceability-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: serviceability-dev-bounces at openjdk.java.net Sender: serviceability-dev X-purgate-ID: tlsNG-38ea93/1509594960-00006357-0E5687D9/0/0 X-purgate-type: clean X-purgate-size: 459 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AHNlcnZpY2VhYmlsaXR5LWRldi1ib3VuY2VzQG9wZW5qZGsuamF2YS5uZXQAY2hyaXN0b3BoLmxhbmdlckBzYXAuY29tAGU4NmM0NmM1MGZmM2E4OGQ3MDkyOTM4ZGViZGU0OWMzNTJhZWQxZWUX-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-Spam-Status: clean X-SAP-SPAM-Status: clean Return-Path: serviceability-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 03:56:01.2691 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.20 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: b6dd3e1a-de24-485a-11e5-08d521a5a1ee X-MS-Exchange-Organization-OriginalSize: 6042 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV?WDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE487.435|UTH=0.001|RST487.435|CATCM-McAfeeTxRoutingAgent=0.001|CATCM=0.001|CAT=0.002;2017-11-02T08:14:08.704Z > On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: > > Hi Kim, hi Jini, > > thank you both for your reviews! > > I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): > http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ Sorry, I overlooked the sponsorship request. I???ll take care of it, but not today. From jini.george at oracle.com Thu Nov 2 04:54:03 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 2 Nov 2017 10:24:03 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAtfd+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAN8MAAB3AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.110 X-EndOfInjectedXHeaders: 7619 Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 06:15:06 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7qL-0003Wx-9M for axel.siebenborn at sap.com; Thu, 02 Nov 2017 06:15:05 +0100 Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59faa520-6357-c0a8029709dd-9c971f45d7b5-3 for ; Thu, 02 Nov 2017 05:55:02 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by ucsinet41.oracle.com with smtp id 3f0c_0176_ccf6c206_c66b_4d53_aac8_13819c89af9f; Thu, 02 Nov 2017 04:54:29 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 2FB68229CF1; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: hotspot-dev at openjdk.java.net Delivered-To: hotspot-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: hotspot-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot virtual machine that's not specific to any particular component List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-dev-bounces at openjdk.java.net Sender: hotspot-dev X-purgate-ID: tlsNG-38ea93/1509598502-00006357-E5788386/2/24257462887 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTU2LjE1MS4zMS42OQBob3RzcG90LWRldi1ib3VuY2VzQG9wZW5qZGsuamF2YS5uZXQAYXhlbC5zaWViZW5ib3JuQHNhcC5jb20AZDg1NTEwM2IxOTM3MzJhYTJiNzFhMmY0MTMxYjAyMWRmYzllZTI4Ng== X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 05:15:06.2733 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 72539627-be68-44eb-0652-08d521b0ae31 X-MS-Exchange-Organization-OriginalSize: 7295 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=10779.618|UTH=0.001|RST=10779.603|CATCM-McAfeeTxRoutingAgent=0.001|CATCM=0.001|CAT=0.002;2017-11-02T08:14:45.891Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From rkennke at redhat.com Thu Nov 2 12:04:05 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 2 Nov 2017 13:04:05 +0100 Subject: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass In-Reply-To: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0@redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE@oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d@redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F@oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7@oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af@redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> Message-ID: <842392bf-ed10-7aa5-08de-31bce3998bb1@redhat.com> Am 02.11.2017 um 04:55 schrieb Kim Barrett: >> On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: >> >> Hi Kim, hi Jini, >> >> thank you both for your reviews! >> >> I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): >> http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ > Sorry, I overlooked the sponsorship request. I?ll take care of it, but not today. > Thanks, Kim! Roman From daniel.daugherty at oracle.com Thu Nov 2 17:13:36 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Nov 2017 13:13:36 -0400 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> On 10/13/17 12:58 AM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8187289 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ > > > Summary: > ? The issue is that the FRAME_POP event request is not cleaned if the > requested > ? method frame is popped but the notification mode is temporarily > disabled. > ? If later the notification mode is enabled again then it will post a > FRAME_POP > event on the first return from an arbitrary method with the same frame > depth. > ? Notification mode for JVMTI_EVENT_FRAME_POP events is checked in the > JvmtiExport::post_method_exit() under the condition: > ????? if (state->is_enabled(JVMTI_EVENT_FRAME_POP)) { > ? Just removing this condition would likely to introduce a performance > regression > ? in interpreted mode. To mitigate it the fix introduces new > JVMTI_SUPPORT_FLAG > ? can_generate_frame_pop_events that is is checked instead of the > notification mode. > ? Also, it is necessary to to keep the > state->is_interp_only_mode()turned on > ? while the JvmtiEnvThreadState has any FRAME_POP requests registered. > > ? One alternate approach to this fix is to leave the current behavior > as it is > ? but update the JVMTI spec with some clarification about this behavior. > > Testing: > ? Verified with new unit test serviceability/jvmti/NotifyFramePop. > ? Also ran the nsk.jvmti, nsk.jdi and jtreg jdk_jdi tests to make sure > there is no regression. > > Thanks, > Serguei First, I'm going to take a step back and look at the JVM/TI programming model for NotifyFramePop() and JVMTI_EVENT_FRAME_POP events. Here's the relevant JVM/TI spec links: https://docs.oracle.com/javase/9/docs/specs/jvmti.html#NotifyFramePop https://docs.oracle.com/javase/9/docs/specs/jvmti.html#FramePop ??? NotifyFramePop() is used by agent code to register interest in ??? when a target thread leaves a Java frame at a specific depth. ??? The target thread can be NULL which means that the current thread ??? is registering interest in itself. The frame is specified by a ??? 'depth' parameter so the agent is not expressing an interest in a ??? specific named function. Also note that NotifyFramePop() can only ??? register interest in Java frames. ??? The agent code must also enable the JVMTI_EVENT_FRAME_POP event in ??? order for the FRAME_POP event to be delivered to the agent's event ??? handler. There is no requirement to enable the FRAME_POP event before ??? calling NotifyFramePop(). Nor is there any requirement for clearing ??? existing frame interest entries when the FRAME_POP event is disabled. ??? If we have target thread call stack that looks like this: ??????? call_depth_0() ??????? call_depth_1() ??????? call_depth_2() ??????? agent_code() ??? The agent_code(), operating on the current thread, calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? NotifyFramePop(NULL, 1); ??? or it calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? NotifyFramePop(NULL, 1); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??? and in either case, we expect a FRAME_POP event to be posted when the ??? target thread returns from call_depth_1() to call_depth_0(). The ??? FRAME_POP event is typically disabled in the FRAME_POP event handler ??? function (frame_pop_callback) that is called when the FRAME_POP event ??? is posted. ??? Because disabling FRAME_POP is not specified to clear interest in a ??? frame, if the agent_code(), operating on the current thread, calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? NotifyFramePop(NULL, 1); ??????? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??? then we expect a FRAME_POP event to be posted when the target thread ??? returns from call_depth_1 to call_depth_0 (and the frame_pop_callback() ??? event handler is called). Okay so I think that covers the general programming model and includes a scenario that shows why we can't clear interest in a frame when the FRAME_POP event is disabled. So we have this NotifyFramePop() function that registers interest in when a target thread leaves a Java frame at a specific depth. We don't have a ClearFramePop() or UnNotifyFramePop() function so the expected way to clear an existing frame interest entry is to do so when we leave that frame. So the current behavior where we can return from call_depth_1() to call_depth_0() without clearing the existing frame interest entry is a bug. Okay so I'm now caught up with this thread and I agree that we have a bug. Definitely a corner case, but a bug none the less. So far I don't see a reason to change any spec wording so let's look at the webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ src/hotspot/share/prims/jvmtiExport.hpp ??? I'm wondering why the existing can_post_interpreter_events() can't ??? cover the case for us since we need to stay in interpreted mode. ??? Update: The existing can_post_interpreter_events() could be used ??? but the new can_generate_frame_pop_events() is more specific. I'm ??? okay with it. src/hotspot/share/prims/jvmtiExport.cpp ??? I agree that JvmtiExport::post_method_exit() needs to check a ??? condition other than "is_enabled(JVMTI_EVENT_FRAME_POP)", but ??? should it be can_generate_frame_pop_events() or should it be ??? can_post_interpreter_events()? ??? Update: The existing can_post_interpreter_events() could be used ??? but the new can_generate_frame_pop_events() is more specific. I'm ??? okay with it. src/hotspot/share/prims/jvmtiEventController.cpp ??? L513: ??? // This iteration will include JvmtiEnvThreadStates whoses environments ??????? Not yours, but could you please fix it? ??????? Typo: 'whoses' -> 'whose' ??? L523-542 - Perhaps we should refactor the code as: ? ? 523?? if (any_env_enabled != was_any_env_enabled) { ? ? 524???? // mark if event is truly enabled on this thread in any environment ? ? 525 state->thread_event_enable()->_event_enabled.set_bits(any_env_enabled); ? ? 526 ? ? 527 ??? // update the JavaThread cached value for thread-specific should_post_on_exceptions value ? ? 528 ??? bool should_post_on_exceptions = (any_env_enabled & SHOULD_POST_ON_EXCEPTIONS_BITS) != 0; ? ? 529 state->set_should_post_on_exceptions(should_post_on_exceptions); ? ? 530?? } ? ? 531 ? ? 532 ? // compute interp_only mode ? ? 533 ? bool should_be_interp = (any_env_enabled & INTERP_EVENT_BITS) != 0 || has_frame_pops; ? ? 534 ? bool is_now_interp = state->is_interp_only_mode(); ? ? 535?? if (should_be_interp != is_now_interp) { ? ? 536 ??? if (should_be_interp) { ? ? 537 ????? enter_interp_only_mode(state); ? ? 538 ??? } else { ? ? 539 ????? leave_interp_only_mode(state); ? ? 540 ??? } ? ? 541 ? } ??? My reasoning is that new L525 and L529 should only be called when ??? this is true: (any_env_enabled != was_any_env_enabled). We always ??? have to check for a change in interp_only mode because the new ??? has_frame_pops condition is independent of the ??? (any_env_enabled != was_any_env_enabled) check so we might as well ??? make that really clear. src/hotspot/share/prims/jvmtiManageCapabilities.cpp ??? Needs copyright year update. make/test/JtregNativeHotspot.gmk ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java ??? L69: ??????? notifyFramePop(null); ??????? Please add comment above L69: ????????? // Ask for notification when we leave frame 1 (meth01). ??? L70:???????? setFramePopNotificationMode(false); ??????? Please add comment above L70: ????????? // Disabling FRAME_POP event notification should not ????????? // prevent the notification for frame 1 from being cleared ????????? // when we return from meth01. ??? L75: ??????? setFramePopNotificationMode(true); ??????? Please add comment above L75: ????????? // Enabling FRAME_POP event notification here should ????????? // not result in a FRAME_POP event when we return from ????????? // frame 1 (meth02) because we did not ask for a ????????? // notification when we leave frame 1 in the context of ????????? // this method (meth02). ??????? to replace this comment: ????????? L76: ??????? // We expect no FramePop event on the meth02() exit as the ????????? L77: ??????? // request from meth01() had to be clear at its exit. ??????? If you like my new comment. :-) test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c ??? L73: ??????? jmethodID method, jboolean wasPopedByException) { ??????? Typo: 'wasPopedByException' -> 'wasPoppedByException' ??? L80: ??? result = FAILED; // This event is not expect ??????? Typo: 'expect' -> 'expected' ??? L101: jint? Agent_Initialize(JavaVM *jvm, char *options, void *reserved) { ??????? Extra space between 'jint' and function name. ??? L150: ??????? if (err != JVMTI_ERROR_NONE) { ??? L151: ??????????? printf("Failed to set notification mode for FRAME_POP events: %s (%d)\n", ??? L152: ?????????????????? TranslateError(err), err); ??????? This error message should also report the 'mode' we're ??????? trying to set for complete context. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Nov 2 20:59:19 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Nov 2017 13:59:19 -0700 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> References: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> Message-ID: <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Nov 3 07:31:02 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 Nov 2017 00:31:02 -0700 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Nov 3 10:14:50 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 3 Nov 2017 03:14:50 -0700 (PDT) Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: Hi Jini, You have appended 'Field' for most of the SA variables. Example: private static CIntegerField pcOffsetField; pcOffsetField = type.getCIntegerField("_pc_offset"); However that is not the case in private static long MinChunkSizeInBytes; MinChunkSizeInBytes = (type.getCIntegerField("_min_chunk_size_in_bytes")).getValue(); You may want to follow the same convention here. Rest of the changes look ok. Thanks, Sharath (not a reviewer) -----Original Message----- From: Jini George Sent: Thursday, November 02, 2017 10:24 AM To: Serguei Spitsyn; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAqbJ+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAGcrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 7733 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:39 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7WZ-000EZw-D4 for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:39 +0100 Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59faa50b-7c01-c0a8033409dd-9c971f454783-3 for ; Thu, 02 Nov 2017 05:54:38 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by ucsinet41.oracle.com with smtp id 4eb7_00c7_3ecf1c93_28fd_4a9f_97f0_f31de9ddb295; Thu, 02 Nov 2017 04:54:17 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 15A99229CEC; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: serviceability-dev at openjdk.java.net Delivered-To: serviceability-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: serviceability-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: serviceability-dev-bounces at openjdk.java.net Sender: serviceability-dev X-purgate-ID: tlsNG-9b91ac/1509598479-00007C01-219CB02A/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTU2LjE1MS4zMS42OQBzZXJ2aWNlYWJpbGl0eS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADgwYzQ2ZTI0N2Q2MTBlYjNiNTQ5MmE5YWE2NzJjNzJjN2NiNjcwNDQ= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: serviceability-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:39.6785 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 8fba1fcd-01cd-4a67-1ee6-08d521add313 X-MS-Exchange-Organization-OriginalSize: 7400 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11997.291|UTH=0.001|RST=11997.244|QS=0.029|CATCM-McAfeeTxRoutingAgent=0.011|CATCM=0.011|CAT=0.012;2017-11-02T08:14:36.969Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAALN+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAIMrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.110 X-EndOfInjectedXHeaders: 7704 Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:46 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7Wg-0004R0-FP for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:46 +0100 Received: from [141.146.126.229] (helo=acsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59faa50f-65eb-c0a8029b09dd-8d927ee53db9-3 for ; Thu, 02 Nov 2017 05:54:45 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_15f0_154b24ba_5aa0_408c_88bd_1cdb37c9c8f4; Thu, 02 Nov 2017 04:54:31 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 3B280229CF4; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: hotspot-runtime-dev at openjdk.java.net Delivered-To: hotspot-runtime-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: hotspot-runtime-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot runtime subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-runtime-dev-bounces at openjdk.java.net Sender: hotspot-runtime-dev X-purgate-ID: tlsNG-81024b/1509598486-000065EB-186BA960/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtcnVudGltZS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADE0ZjI2NjVmYTY4ZGRiOWMwNGJiMGU0MmE2Njk2M2ZiNWQxNzAyOGI= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-runtime-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:46.7566 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 9365fa06-08de-47df-2865-08d521add74b X-MS-Exchange-Organization-OriginalSize: 7380 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11990.260|UTH=0.001|RST=11990.260|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.005|CAT=0.006;2017-11-02T08:14:37.016Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From jini.george at oracle.com Fri Nov 3 10:51:19 2017 From: jini.george at oracle.com (Jini George) Date: Fri, 3 Nov 2017 16:21:19 +0530 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> Message-ID: <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> Here is the updated webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ I have made changes to validate the test results of each command separately, done away with the asserts and have added some more comments. Thank you, Jini. On 10/31/2017 12:32 PM, Jini George wrote: > Thank you for the quick review, David. My comments inline: > > On 10/30/2017 11:18 AM, David Holmes wrote: > >>> Plus this assumes G1 is being used but Lingered App is started using >>> the test run vmOptions AFAICS so it would use whatever GC were passed >>> through, wouldn't it? >> >> Okay the above are just examples of "int constants" that will be >> printed when you dump all the "int constants". The G1 constant doesn't >> indicate (I presume) that G1 is the active GC. > > Yes, the int constants contain compile time values and there are entries > for all the GC types. > >> As I said to Sharath it would be good to validate the results of each >> command separately rather than collectively. > > Will do. > > Thanks! > - Jini. > > > >> Thanks, >> David >> >>> --- >>> >>> TestType.java >>> >>> The expected output is not quite so strange, but still could do with >>> some commentary. >>> >>> ?? 90???????? Asserts.assertTrue(output.contains("type >>> G1CollectedHeap CollectedHeap")); >>> >>> Same comment about assuming G1. >>> >>> Thanks, >>> David >>> ------ >>> >>> On 30/10/2017 1:44 PM, Jini George wrote: >>>> Hello, >>>> >>>> We have been working on writing sanity tests for the various jhsdb >>>> clhsdb commands of the SA to improve the robustness of the SA. As a >>>> part of this, here is a webrev for sanity tests for 3 of the clhsdb >>>> commands: >>>> >>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>> >>>> I would like to request for reviews for this simple addition. >>>> >>>> Thank you, >>>> Jini. From daniel.daugherty at oracle.com Fri Nov 3 11:56:39 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 3 Nov 2017 07:56:39 -0400 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> References: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> Message-ID: > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ make/test/JtregNativeHotspot.gmk ??? No comments. src/hotspot/share/prims/jvmtiEventController.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.hpp ??? No comments. src/hotspot/share/prims/jvmtiManageCapabilities.cpp ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c ??? No comments. Thumbs up! Dan On 11/2/17 4:59 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot for doing this review! > I was waiting for you for a couple of weeks. :) > > > On 11/2/17 10:13, Daniel D. Daugherty wrote: >> On 10/13/17 12:58 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8187289 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ >>> >>> >>> Summary: >>> ? The issue is that the FRAME_POP event request is not cleaned if >>> the requested >>> ? method frame is popped but the notification mode is temporarily >>> disabled. >>> ? If later the notification mode is enabled again then it will post >>> a FRAME_POP >>> ? event on the first return from an arbitrary method with the same >>> frame depth. >>> ? Notification mode for JVMTI_EVENT_FRAME_POP events is checked in the >>> ? JvmtiExport::post_method_exit() under the condition: >>> ????? if (state->is_enabled(JVMTI_EVENT_FRAME_POP)) { >>> ? Just removing this condition would likely to introduce a >>> performance regression >>> ? in interpreted mode. To mitigate it the fix introduces new >>> JVMTI_SUPPORT_FLAG >>> ? can_generate_frame_pop_events that is is checked instead of the >>> notification mode. >>> ? Also, it is necessary to to keep the state->is_interp_only_mode() >>> turned on >>> ? while the JvmtiEnvThreadState has any FRAME_POP requests registered. >>> >>> ? One alternate approach to this fix is to leave the current >>> behavior as it is >>> ? but update the JVMTI spec with some clarification about this >>> behavior. >>> >>> Testing: >>> ? Verified with new unit test serviceability/jvmti/NotifyFramePop. >>> ? Also ran the nsk.jvmti, nsk.jdi and jtreg jdk_jdi tests to make >>> sure there is no regression. >>> >>> Thanks, >>> Serguei >> >> First, I'm going to take a step back and look at the JVM/TI programming >> model for NotifyFramePop() and JVMTI_EVENT_FRAME_POP events. Here's the >> relevant JVM/TI spec links: >> >> https://docs.oracle.com/javase/9/docs/specs/jvmti.html#NotifyFramePop >> https://docs.oracle.com/javase/9/docs/specs/jvmti.html#FramePop >> >> ??? NotifyFramePop() is used by agent code to register interest in >> ??? when a target thread leaves a Java frame at a specific depth. >> ??? The target thread can be NULL which means that the current thread >> ??? is registering interest in itself. The frame is specified by a >> ??? 'depth' parameter so the agent is not expressing an interest in a >> ??? specific named function. Also note that NotifyFramePop() can only >> ??? register interest in Java frames. >> >> ??? The agent code must also enable the JVMTI_EVENT_FRAME_POP event in >> ??? order for the FRAME_POP event to be delivered to the agent's event >> ??? handler. There is no requirement to enable the FRAME_POP event before >> ??? calling NotifyFramePop(). Nor is there any requirement for clearing >> ??? existing frame interest entries when the FRAME_POP event is disabled. > > All the above is correct. > Thank you for providing this background as it is useful for reviewers! > > >> ??? If we have target thread call stack that looks like this: >> >> ??????? call_depth_0() >> ??????? call_depth_1() >> ??????? call_depth_2() >> ??????? agent_code() >> >> ??? The agent_code(), operating on the current thread, calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> ??????? NotifyFramePop(NULL, 1); >> >> ??? or it calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? NotifyFramePop(NULL, 1); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> >> ??? and in either case, we expect a FRAME_POP event to be posted when the >> ??? target thread returns from call_depth_1() to call_depth_0(). The >> ??? FRAME_POP event is typically disabled in the FRAME_POP event handler >> ??? function (frame_pop_callback) that is called when the FRAME_POP event >> ??? is posted. >> >> ??? Because disabling FRAME_POP is not specified to clear interest in a >> ??? frame, if the agent_code(), operating on the current thread, calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> ??????? NotifyFramePop(NULL, 1); >> ??????? SetEventNotificationMode(JVMTI_DISABLE, >> JVMTI_EVENT_FRAME_POP, NULL); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> >> ??? then we expect a FRAME_POP event to be posted when the target thread >> ??? returns from call_depth_1 to call_depth_0 (and the >> frame_pop_callback() >> ??? event handler is called). >> >> >> Okay so I think that covers the general programming model and includes >> a scenario that shows why we can't clear interest in a frame when the >> FRAME_POP event is disabled. > > The above is correct too. > > >> So we have this NotifyFramePop() function that registers interest in >> when a >> target thread leaves a Java frame at a specific depth. We don't have a >> ClearFramePop() or UnNotifyFramePop() function so the expected way to >> clear >> an existing frame interest entry is to do so when we leave that frame. So >> the current behavior where we can return from call_depth_1() to >> call_depth_0() >> without clearing the existing frame interest entry is a bug. > > Right. > > >> Okay so I'm now caught up with this thread and I agree that we have a >> bug. >> Definitely a corner case, but a bug none the less. So far I don't see a >> reason to change any spec wording so let's look at the webrev: > > Right but modulo what Alan said that bug fixing this bug we are going > to change the behavior. > So that at least we need a CSR and release note for this update. > > > >> >> > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ >> >> src/hotspot/share/prims/jvmtiExport.hpp >> ??? I'm wondering why the existing can_post_interpreter_events() can't >> ??? cover the case for us since we need to stay in interpreted mode. >> >> ??? Update: The existing can_post_interpreter_events() could be used >> ??? but the new can_generate_frame_pop_events() is more specific. I'm >> ??? okay with it. > > Ok, thanks. > > >> src/hotspot/share/prims/jvmtiExport.cpp >> ??? I agree that JvmtiExport::post_method_exit() needs to check a >> ??? condition other than "is_enabled(JVMTI_EVENT_FRAME_POP)", but >> ??? should it be can_generate_frame_pop_events() or should it be >> ??? can_post_interpreter_events()? >> >> ??? Update: The existing can_post_interpreter_events() could be used >> ??? but the new can_generate_frame_pop_events() is more specific. I'm >> ??? okay with it. > > Ok, thanks. > > >> src/hotspot/share/prims/jvmtiEventController.cpp >> ??? L513: ??? // This iteration will include JvmtiEnvThreadStates >> whoses environments >> ??????? Not yours, but could you please fix it? >> ??????? Typo: 'whoses' -> 'whose' > > Good eyes! > Fixed. > > >> ??? L523-542 - Perhaps we should refactor the code as: >> >> ? ? 523?? if (any_env_enabled != was_any_env_enabled) { >> ? ? 524???? // mark if event is truly enabled on this thread in any >> environment >> ? ? 525 >> state->thread_event_enable()->_event_enabled.set_bits(any_env_enabled); >> ? ? 526 >> ? ? 527 ??? // update the JavaThread cached value for thread-specific >> should_post_on_exceptions value >> ? ? 528 ??? bool should_post_on_exceptions = (any_env_enabled & >> SHOULD_POST_ON_EXCEPTIONS_BITS) != 0; >> ? ? 529 state->set_should_post_on_exceptions(should_post_on_exceptions); >> ? ? 530?? } >> ? ? 531 >> ? ? 532 ? // compute interp_only mode >> ? ? 533 ? bool should_be_interp = (any_env_enabled & >> INTERP_EVENT_BITS) != 0 || has_frame_pops; >> ? ? 534 ? bool is_now_interp = state->is_interp_only_mode(); >> ? ? 535?? if (should_be_interp != is_now_interp) { >> ? ? 536 ??? if (should_be_interp) { >> ? ? 537 ????? enter_interp_only_mode(state); >> ? ? 538 ??? } else { >> ? ? 539 ????? leave_interp_only_mode(state); >> ? ? 540 ??? } >> ? ? 541 ? } >> >> ??? My reasoning is that new L525 and L529 should only be called when >> ??? this is true: (any_env_enabled != was_any_env_enabled). We always >> ??? have to check for a change in interp_only mode because the new >> ??? has_frame_pops condition is independent of the >> ??? (any_env_enabled != was_any_env_enabled) check so we might as well >> ??? make that really clear. > > Refactored as you suggested. > Will need to test it well. > > >> src/hotspot/share/prims/jvmtiManageCapabilities.cpp >> ??? Needs copyright year update. > > Updated the copyright year, thanks. > > >> make/test/JtregNativeHotspot.gmk >> ??? No comments. >> >> test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java >> ??? L69: ??????? notifyFramePop(null); >> ??????? Please add comment above L69: >> >> ????????? // Ask for notification when we leave frame 1 (meth01). >> >> ??? L70:???????? setFramePopNotificationMode(false); >> ??????? Please add comment above L70: >> >> ????????? // Disabling FRAME_POP event notification should not >> ????????? // prevent the notification for frame 1 from being cleared >> ????????? // when we return from meth01. >> >> ??? L75: ??????? setFramePopNotificationMode(true); >> ??????? Please add comment above L75: >> >> ????????? // Enabling FRAME_POP event notification here should >> ????????? // not result in a FRAME_POP event when we return from >> ????????? // frame 1 (meth02) because we did not ask for a >> ????????? // notification when we leave frame 1 in the context of >> ????????? // this method (meth02). >> >> ??????? to replace this comment: >> >> ????????? L76: ??????? // We expect no FramePop event on the meth02() >> exit as the >> ????????? L77: ??????? // request from meth01() had to be clear at >> its exit. >> >> ??????? If you like my new comment. :-) > > Good suggestions, thanks. > Added the comments. > > >> test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c >> ??? L73: ??????? jmethodID method, jboolean wasPopedByException) { >> ??????? Typo: 'wasPopedByException' -> 'wasPoppedByException' >> >> ??? L80: ??? result = FAILED; // This event is not expect >> ??????? Typo: 'expect' -> 'expected' >> >> ??? L101: jint? Agent_Initialize(JavaVM *jvm, char *options, void >> *reserved) { >> ??????? Extra space between 'jint' and function name. >> >> ??? L150: ??????? if (err != JVMTI_ERROR_NONE) { >> ??? L151: ??????????? printf("Failed to set notification mode for >> FRAME_POP events: %s (%d)\n", >> ??? L152: ?????????????????? TranslateError(err), err); >> ??????? This error message should also report the 'mode' we're >> ??????? trying to set for complete context. > > Good catches, thanks. > Fixed. > > > The updated webrev is: > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ > > > I will also run the jvmti, jdi, jdwp and j.l.instrument tests. > > > Thanks, > Serguei > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri Nov 3 12:10:12 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 3 Nov 2017 21:10:12 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> Message-ID: <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> Hi Serguei, Thank you for your comment! I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html > > - if (!ex.getMessage().contains("Invalid com.sun.management.jmxremote.port number")) { > + if (!ex.getMessage().contains("For input string: \"apa\"")) { > > > What is the motivation for this change? > It seems, the original comparison is better. "ex" is AttachOperationFailedException. We can get the result as below when we run StartManagementAgent: ------------- [runApplication] Error: Invalid com.sun.management.jmxremote.port number: apa [runApplication] jdk.internal.agent.AgentConfigurationError: java.lang.NumberFormatException: For input string: "apa" [runApplication] at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) ------------- I think we should check exception message in AttachOperationFailedException. In fact, jtreg fails at this point in my environment. > What tests did you run to make sure there are no regressions? I've tested the following testcases: - hotspot/jtreg/serviceability/attach - hotspot/jtreg/serviceability/dcmd/jvmti - jdk/com/sun/tools/attach Thanks, Yasumasa On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Some comments. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html > > - if (!ex.getMessage().contains("Invalid com.sun.management.jmxremote.port number")) { > + if (!ex.getMessage().contains("For input string: \"apa\"")) { > > > ? What is the motivation for this change? > ? It seems, the original comparison is better. > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html > > 37 public void run(CommandExecutor executor) { > 38 try{ > > ? A space is missed after 'try'. > > > ? It is odd that all test java classes define exactly the same methods: sharedObjectName(), jmx() and cli(). > ? Would it better to defin a common base class with these methods? > > > Otherwise, it looks good. > Thank you for taking care about it! > > What tests did you run to make sure there are no regressions? > > Thanks, > Serguei > > > > On 11/1/17 05:59, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>> will get "Command executed successfully". However, it implies error in >>> JVMTIAgentLoadDCmd. >>> This message is from JCmd.java when jcmd does not receive any output >>> from target VM. >>> >>> I think HotSopt/jcmd should return useful error message to users to >>> understand the cause of failure. >>> >>> I uploaded webrev for this issue. Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>> >>> >>> This change is work fine on Fedora 26 x86_64 as following? jtreg testcases: >>> >>> ?? - hotspot/jtreg/serviceability/attach >>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>> ?? - jdk/com/sun/tools/attach >>> >>> I cannot access JPRT. So I need a sponsor. >>> (I cannot test it on other platforms.) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> > From serguei.spitsyn at oracle.com Fri Nov 3 16:45:17 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 Nov 2017 09:45:17 -0700 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> Message-ID: <89387e82-5497-f6e6-aa97-b55bc5420d8d@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat Nov 4 00:25:20 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 3 Nov 2017 17:25:20 -0700 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout Message-ID: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8059334 http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ The CR is closed, so I'll try to explain the issue here. The very short explanation is that the JVMTI test was enabling SINGLE STEP and doing a PopFrame, but the test method managed to get compiled and started executing compiled after the thread was put in "interp only" mode (which should never happen) and before the PopFrame was processed. The cause is a lack of a check for "interp only" mode in the OSR related compilation policy code. Details: The test is testing JVMTI PopFrame support. The test thread has a small method that sits in a tight loop. It will never exit. The main thread enables SINGLE STEP on the test thread, and then does a PopFrame on the test thread to force it out of the looping method. When the test failed due to a time out, I noticed it was still stuck in the small method, even though a PopFrame had been requested. Further, I noticed the method was compiled, so there was no chance the method would ever detect that it should do a PopFrame. Since "interp only" mode for SINGLE STEP had been enabled, the method should not be running compiled, so clearly something went wrong that allowed it to compile and execute. When SINGLE STEP is requested, JVMTI will deopt the topmost method (actually the top 2), put the thread in "interp only" mode, and then has checks to make sure the thread continues to execute interpreted. To avoid compilation when a back branch tries to trigger one, there is a check for "interp only" mode in SimpleThresholdPolicy::event(). If the thread is in "interp only" mode, it will prevent compilation. SimpleThresholdPolicy::event() is called (indirectly) by InterpreterRuntime::frequency_counter_overflow(), which is called from the interpreter when the back branch threshold is reached. After some debugging I noticed when the test timeout happens, "interp only" mode is not yet enabled when InterpreterRuntime::frequency_counter_overflow() is called, but is enabled by the time InterpreterRuntime::frequency_counter_overflow() has done the lookup of the nm. So there is a race here allowing the thread to begin execution in a compiled method even though "interp only" mode is enabled. I think the reason is because we safepoint during the compilation, and this allows a SINGLE STEP request to be processed, which enables "interp only" mode. I should add that initially I only saw this bug with -Xcomp, but eventually realized it was caused by disabling BackgroundCompilation. That makes it much more likely that a SINGLE STEP request will come in and be processed during the call to InterpreterRuntime::frequency_counter_overflow() (because it will block until the compilation completes). I believe for the fix it is enough just to add an "interp only" mode check in InterpreterRuntime::frequency_counter_overflow() after the nm lookup, and set it nm to NULL if we are now in "interp only" mode. If we are not in "interp only" mode at this point (and start executing the compiled method) it should not be possible to enter "interp only" mode until we reach a safepoint at some later time, and at that point the method will be properly deopt so it can execute interpreted. thanks, Chris From dean.long at oracle.com Sat Nov 4 04:44:20 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 3 Nov 2017 21:44:20 -0700 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <901dc547-182d-155d-5340-b973731003e1@oracle.com> I'm not an expert in this area of code, but I'm wondering about Vladimir's comment about ciEnv::jvmti_state_changed() in the bug report.? With your fix, maybe we don't need to check ciEnv::jvmti_state_changed() (which doesn't seem to be enough by itself) and throw away the compiled result.? We could just keep it around so it can be used when "interp only" mode is switched off. dl On 11/3/17 5:25 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From sharath.ballal at oracle.com Sun Nov 5 16:33:44 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 5 Nov 2017 08:33:44 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> Message-ID: Thanks David for the comments. Reply inline. The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Monday, October 30, 2017 11:15 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Hi Sharath, I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. I have a few comments. On 30/10/2017 2:29 PM, Sharath Ballal wrote: > Hello, > > This webrev has changes for a framework for running the 'jhsdb clhsdb' > commands and verifying the output.? It also has sanity tests for 8 of I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... hsdb> hsdb> hsdb> flags .... ...... ZombieALotInterval = 5 0 hashCode = 5 0 hsdb> hsdb> My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); toolProcess.waitFor(); output = outputAnalyzer.getOutput(); Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? [Sharath Ballal] Launcher can do it. I have made the changes. Can the launcher internalize the management of the LingeredApp? [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. Can the launcher also handle the shouldSAAttach check? [Sharath Ballal] Yes. I have made that change. I can imagine the test logic reducing to a very simple: println(Starting test of ... List cmds = List.of( ...); List expected = List.of(...); List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. [Sharath Ballal] I have done this change. I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. [Sharath Ballal] OK. I have done these changes. It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. or the difference in expected output between: 57 "longConstant jtreg::test 6\n", 58 "longConstant jtreg::test\n", I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? [Sharath Ballal] Yes. I have provided a way to specify the expected/unexpected output per command and check it separately. Thanks, David > the clhsdb commands. > > Pls review the changes. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 > > Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ > > Thanks, > > Sharath > From david.holmes at oracle.com Mon Nov 6 07:28:12 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Nov 2017 17:28:12 +1000 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> Message-ID: <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> Hi Jini, On 3/11/2017 8:51 PM, Jini George wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ > > I have made changes to validate the test results of each command > separately, done away with the asserts and have added some more comments. This looks much better to me - thanks. This fragment: int exitValue = p.exitValue(); OutputAnalyzer output = new OutputAnalyzer(p); System.out.println(output.getOutput()); if (exitValue != 0) { throw new Error("clhsdb wasn't run successfully."); } can be reduced to: OutputAnalyzer output = new OutputAnalyzer(p); output.shouldHaveExitValue(0); There's probably no need to print getOutput() as if anything goes wrong it will be printed by OutputAnalyzer anyway. But that's your choice. It may also be advisable to ensure the process is destroyed if you get an exception here: try { p.waitFor(); } catch (InterruptedException ie) { + p.destroyForcibly(); throw new Error("Problem awaiting the child process: " + ie, ie); } similar to how ProcessTools.executeProcess manages things. Thanks, David ----- > Thank you, > Jini. > > On 10/31/2017 12:32 PM, Jini George wrote: >> Thank you for the quick review, David. My comments inline: >> >> On 10/30/2017 11:18 AM, David Holmes wrote: >> >>>> Plus this assumes G1 is being used but Lingered App is started using >>>> the test run vmOptions AFAICS so it would use whatever GC were >>>> passed through, wouldn't it? >>> >>> Okay the above are just examples of "int constants" that will be >>> printed when you dump all the "int constants". The G1 constant >>> doesn't indicate (I presume) that G1 is the active GC. >> >> Yes, the int constants contain compile time values and there are >> entries for all the GC types. >> >>> As I said to Sharath it would be good to validate the results of each >>> command separately rather than collectively. >> >> Will do. >> >> Thanks! >> - Jini. >> >> >> >>> Thanks, >>> David >>> >>>> --- >>>> >>>> TestType.java >>>> >>>> The expected output is not quite so strange, but still could do with >>>> some commentary. >>>> >>>> ?? 90???????? Asserts.assertTrue(output.contains("type >>>> G1CollectedHeap CollectedHeap")); >>>> >>>> Same comment about assuming G1. >>>> >>>> Thanks, >>>> David >>>> ------ >>>> >>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> We have been working on writing sanity tests for the various jhsdb >>>>> clhsdb commands of the SA to improve the robustness of the SA. As a >>>>> part of this, here is a webrev for sanity tests for 3 of the clhsdb >>>>> commands: >>>>> >>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>> >>>>> I would like to request for reviews for this simple addition. >>>>> >>>>> Thank you, >>>>> Jini. From rkennke at redhat.com Mon Nov 6 10:55:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Nov 2017 11:55:07 +0100 Subject: RFR: 8183542: Factor out serial GC specific code from GenCollectedHeap into its own subclass In-Reply-To: <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> References: <6dea5306-1ec9-d439-b498-b9e657d7daf0@redhat.com> <3979E865-1363-4B60-ABDF-63128BAF04CE@oracle.com> <352c558d-40ba-27c4-861b-fcdb99ef706d@redhat.com> <487881EC-2CCD-47C4-BA7A-1723A40C1F9F@oracle.com> <11759C2F-6F17-49C0-9D68-5B5B057C14B7@oracle.com> <4f84ff16-3f69-d2cf-2eb3-2e820aad49af@redhat.com> <90d877fb-a406-e1e3-6d26-a5e00e5666eb@redhat.com> <2C530D1F-DAFA-428F-BC80-BF04EDB1DA98@oracle.com> Message-ID: Am 02.11.2017 um 04:55 schrieb Kim Barrett: >> On Oct 25, 2017, at 4:07 AM, Roman Kennke wrote: >> >> Hi Kim, hi Jini, >> >> thank you both for your reviews! >> >> I think I need a sponsor now. The final webrev (same as before plus Reviewed-by line): >> http://cr.openjdk.java.net/~rkennke/8183542/webrev.03/ > Sorry, I overlooked the sponsorship request. I?ll take care of it, but not today. > Ping? :-) From serguei.spitsyn at oracle.com Mon Nov 6 11:06:25 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Nov 2017 03:06:25 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> Message-ID: <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> Hi Yasumasa, The changes looks good. Thank you for making them! On 11/3/17 05:10, Yasumasa Suenaga wrote: > Hi Serguei, > > Thank you for your comment! > I uploaded new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ > > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >> >> >> - if (!ex.getMessage().contains("Invalid >> com.sun.management.jmxremote.port number")) { >> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >> >> >> ?? What is the motivation for this change? >> ?? It seems, the original comparison is better. > > "ex" is AttachOperationFailedException. > We can get the result as below when we run StartManagementAgent: > > ------------- > [runApplication] Error: Invalid com.sun.management.jmxremote.port > number: apa > [runApplication] jdk.internal.agent.AgentConfigurationError: > java.lang.NumberFormatException: For input string: "apa" > [runApplication]??????? at > jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) > ------------- > > I think we should check exception message in > AttachOperationFailedException. > In fact, jtreg fails at this point in my environment. I'd expect a check for some exception name, not for details like: For input string: "apa". >> What tests did you run to make sure there are no regressions? > > I've tested the following testcases: > > ? - hotspot/jtreg/serviceability/attach > ? - hotspot/jtreg/serviceability/dcmd/jvmti > ? - jdk/com/sun/tools/attach There are more tests related to dynamic attach in closed, nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. I'm not sure, if they are included into any of the Mach5 testing levels. Will need to check. We have to make sure these tests are still passed. Thanks, Serguei > Thanks, > > Yasumasa > > > On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Some comments. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >> >> >> - if (!ex.getMessage().contains("Invalid >> com.sun.management.jmxremote.port number")) { >> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >> >> >> ?? What is the motivation for this change? >> ?? It seems, the original comparison is better. >> >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >> >> >> ?? 37???? public void run(CommandExecutor executor)? { >> ?? 38???????? try{ >> >> ?? A space is missed after 'try'. >> >> >> ?? It is odd that all test java classes define exactly the same >> methods: sharedObjectName(), jmx() and cli(). >> ?? Would it better to defin a common base class with these methods? >> >> >> Otherwise, it looks good. >> Thank you for taking care about it! >> >> What tests did you run to make sure there are no regressions? >> >> Thanks, >> Serguei >> >> >> >> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>> will get "Command executed successfully". However, it implies error in >>>> JVMTIAgentLoadDCmd. >>>> This message is from JCmd.java when jcmd does not receive any output >>>> from target VM. >>>> >>>> I think HotSopt/jcmd should return useful error message to users to >>>> understand the cause of failure. >>>> >>>> I uploaded webrev for this issue. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>> >>>> >>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>> testcases: >>>> >>>> ?? - hotspot/jtreg/serviceability/attach >>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>> ?? - jdk/com/sun/tools/attach >>>> >>>> I cannot access JPRT. So I need a sponsor. >>>> (I cannot test it on other platforms.) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >> From yasuenag at gmail.com Mon Nov 6 12:31:03 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 6 Nov 2017 21:31:03 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> Message-ID: <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> Hi Serguei, On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > The changes looks good. > Thank you for making them! Thanks! > On 11/3/17 05:10, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> Thank you for your comment! >> I uploaded new webrev: >> >> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>> >>> - if (!ex.getMessage().contains("Invalid com.sun.management.jmxremote.port number")) { >>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>> >>> >>> ?? What is the motivation for this change? >>> ?? It seems, the original comparison is better. >> >> "ex" is AttachOperationFailedException. >> We can get the result as below when we run StartManagementAgent: >> >> ------------- >> [runApplication] Error: Invalid com.sun.management.jmxremote.port number: apa >> [runApplication] jdk.internal.agent.AgentConfigurationError: java.lang.NumberFormatException: For input string: "apa" >> [runApplication]??????? at jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >> ------------- >> >> I think we should check exception message in AttachOperationFailedException. >> In fact, jtreg fails at this point in my environment. > > > I'd expect a check for some exception name, not for details like: For input string: "apa". Should we remove this comparison? >>> What tests did you run to make sure there are no regressions? >> >> I've tested the following testcases: >> >> ? - hotspot/jtreg/serviceability/attach >> ? - hotspot/jtreg/serviceability/dcmd/jvmti >> ? - jdk/com/sun/tools/attach > > There are more tests related to dynamic attach in closed, nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. > I'm not sure, if they are included into any of the Mach5 testing levels. Will need to check. > We have to make sure these tests are still passed. I cannot access JPRT and closed testcases because I'm not an Oracle employee. Can you run them with this change? Thanks, Yasumasa > Thanks, > Serguei > >> Thanks, >> >> Yasumasa >> >> >> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Some comments. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>> >>> - if (!ex.getMessage().contains("Invalid com.sun.management.jmxremote.port number")) { >>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>> >>> >>> ?? What is the motivation for this change? >>> ?? It seems, the original comparison is better. >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>> >>> ?? 37???? public void run(CommandExecutor executor)? { >>> ?? 38???????? try{ >>> >>> ?? A space is missed after 'try'. >>> >>> >>> ?? It is odd that all test java classes define exactly the same methods: sharedObjectName(), jmx() and cli(). >>> ?? Would it better to defin a common base class with these methods? >>> >>> >>> Otherwise, it looks good. >>> Thank you for taking care about it! >>> >>> What tests did you run to make sure there are no regressions? >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>> will get "Command executed successfully". However, it implies error in >>>>> JVMTIAgentLoadDCmd. >>>>> This message is from JCmd.java when jcmd does not receive any output >>>>> from target VM. >>>>> >>>>> I think HotSopt/jcmd should return useful error message to users to >>>>> understand the cause of failure. >>>>> >>>>> I uploaded webrev for this issue. Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>> >>>>> >>>>> This change is work fine on Fedora 26 x86_64 as following jtreg testcases: >>>>> >>>>> ?? - hotspot/jtreg/serviceability/attach >>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>> ?? - jdk/com/sun/tools/attach >>>>> >>>>> I cannot access JPRT. So I need a sponsor. >>>>> (I cannot test it on other platforms.) >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>> > From chris.plummer at oracle.com Mon Nov 6 18:56:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Nov 2017 10:56:43 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <901dc547-182d-155d-5340-b973731003e1@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> Message-ID: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Hi Dean, It looks like ciEnv::jvmti_state_changed() is used to support the JVMTI AddCapabilities() interface, which I believe typically a JVMTI agent uses to setup the available capabilities when the agent is first loaded (although capabilities can by changed afterwords also). So I don't see that code as being related to changing the thread to be changed to "interp only" mode. thanks, Chris On 11/3/17 9:44 PM, dean.long at oracle.com wrote: > I'm not an expert in this area of code, but I'm wondering about > Vladimir's comment about ciEnv::jvmti_state_changed() in the bug > report. With your fix, maybe we don't need to check > ciEnv::jvmti_state_changed() (which doesn't seem to be enough by > itself) and throw away the compiled result.? We could just keep it > around so it can be used when "interp only" mode is switched off. > > dl > > > On 11/3/17 5:25 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >> >> The CR is closed, so I'll try to explain the issue here. The very >> short explanation is that the JVMTI test was enabling SINGLE STEP and >> doing a PopFrame, but the test method managed to get compiled and >> started executing compiled after the thread was put in "interp only" >> mode (which should never happen) and before the PopFrame was >> processed. The cause is a lack of a check for "interp only" mode in >> the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a >> small method that sits in a tight loop. It will never exit. The main >> thread enables SINGLE STEP on the test thread, and then does a >> PopFrame on the test thread to force it out of the looping method. >> When the test failed due to a time out, I noticed it was still stuck >> in the small method, even though a PopFrame had been requested. >> Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since >> "interp only" mode for SINGLE STEP had been enabled, the method >> should not be running compiled, so clearly something went wrong that >> allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method >> (actually the top 2), put the thread in "interp only" mode, and then >> has checks to make sure the thread continues to execute interpreted. >> To avoid compilation when a back branch tries to trigger one, there >> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >> If the thread is in "interp only" mode, it will prevent compilation. >> SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called >> from the interpreter when the back branch threshold is reached. >> >> After some debugging I noticed when the test timeout happens, "interp >> only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is >> enabled by the time InterpreterRuntime::frequency_counter_overflow() >> has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp >> only" mode is enabled. I think the reason is because we safepoint >> during the compilation, and this allows a SINGLE STEP request to be >> processed, which enables "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but >> eventually realized it was caused by disabling BackgroundCompilation. >> That makes it much more likely that a SINGLE STEP request will come >> in and be processed during the call to >> InterpreterRuntime::frequency_counter_overflow() (because it will >> block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode >> check in InterpreterRuntime::frequency_counter_overflow() after the >> nm lookup, and set it nm to NULL if we are now in "interp only" mode. >> If we are not in "interp only" mode at this point (and start >> executing the compiled method) it should not be possible to enter >> "interp only" mode until we reach a safepoint at some later time, and >> at that point the method will be properly deopt so it can execute >> interpreted. >> >> thanks, >> >> Chris >> > From dean.long at oracle.com Mon Nov 6 19:14:37 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 6 Nov 2017 11:14:37 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Message-ID: <7c91ed2f-4462-d890-c2aa-aea9526f6653@oracle.com> OK thanks. dl On 11/6/17 10:56 AM, Chris Plummer wrote: > Hi Dean, > > It looks like ciEnv::jvmti_state_changed() is used to support the > JVMTI AddCapabilities() interface, which I believe typically a JVMTI > agent uses to setup the available capabilities when the agent is first > loaded (although capabilities can by changed afterwords also). So I > don't see that code as being related to changing the thread to be > changed to "interp only" mode. > > thanks, > > Chris > > On 11/3/17 9:44 PM, dean.long at oracle.com wrote: >> I'm not an expert in this area of code, but I'm wondering about >> Vladimir's comment about ciEnv::jvmti_state_changed() in the bug >> report. With your fix, maybe we don't need to check >> ciEnv::jvmti_state_changed() (which doesn't seem to be enough by >> itself) and throw away the compiled result.? We could just keep it >> around so it can be used when "interp only" mode is switched off. >> >> dl >> >> >> On 11/3/17 5:25 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> > > From daniel.daugherty at oracle.com Mon Nov 6 20:23:50 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Nov 2017 15:23:50 -0500 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> On 11/3/17 8:25 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 Wow! This bug was quite the adventure... > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ src/hotspot/share/interpreter/interpreterRuntime.cpp ??? L924: ? if (thread->is_interp_only_mode()) { ??????? Perhaps: if (nm != NULL && thread->is_interp_only_mode()) { ??? I kept trying to decide whether your new check only needs to ? ? be inside the existing block: ? ? ? ? L913: ? if (branch_bcp != NULL && nm != NULL) { ??????? : ? ? ? ? L923?? } ? ? but I finally convinced myself that you want to check a non-NULL ? ? nm value in either branch_bcp code branch (NULL or non-NULL) so ??? where you put the fix is just fine. ? ? Of course, the usual question we have to ask in these kinds of ? ? races is what prevents the racy condition from asserting itself ? ? right after the fixed code location. Thanks for including your ? ? last sentence: > ??? If we are not in "interp only" mode at this point (and start executing > ??? the compiled method) it should not be possible to enter "interp only" > ??? mode until we reach a safepoint at some later time, and at that point > ??? the method will be properly deopt so it can execute interpreted. Nicely done bug hunt! Thumbs up! Dan > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From chris.plummer at oracle.com Mon Nov 6 20:33:43 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 Nov 2017 12:33:43 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <304657a1-fe1a-100d-b155-3897d18e9770@oracle.com> Message-ID: Hi Dan, On 11/6/17 12:23 PM, Daniel D. Daugherty wrote: > On 11/3/17 8:25 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 > > Wow! This bug was quite the adventure... I know how to pick 'em, huh? :) > > >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > src/hotspot/share/interpreter/interpreterRuntime.cpp > ??? L924: ? if (thread->is_interp_only_mode()) { > ??????? Perhaps: if (nm != NULL && thread->is_interp_only_mode()) { Ok, I'll add the NULL check. > > ??? I kept trying to decide whether your new check only needs to > ? ? be inside the existing block: > > ? ? ? ? L913: ? if (branch_bcp != NULL && nm != NULL) { > ??????? : > ? ? ? ? L923?? } > > ? ? but I finally convinced myself that you want to check a non-NULL > ? ? nm value in either branch_bcp code branch (NULL or non-NULL) so > ??? where you put the fix is just fine. > > ? ? Of course, the usual question we have to ask in these kinds of > ? ? races is what prevents the racy condition from asserting itself > ? ? right after the fixed code location. Thanks for including your > ? ? last sentence: > >> ??? If we are not in "interp only" mode at this point (and start >> executing >> ??? the compiled method) it should not be possible to enter "interp >> only" >> ??? mode until we reach a safepoint at some later time, and at that >> point >> ??? the method will be properly deopt so it can execute interpreted. > > Nicely done bug hunt! > > Thumbs up! Thanks! Chris > > Dan > > >> >> The CR is closed, so I'll try to explain the issue here. The very >> short explanation is that the JVMTI test was enabling SINGLE STEP and >> doing a PopFrame, but the test method managed to get compiled and >> started executing compiled after the thread was put in "interp only" >> mode (which should never happen) and before the PopFrame was >> processed. The cause is a lack of a check for "interp only" mode in >> the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a >> small method that sits in a tight loop. It will never exit. The main >> thread enables SINGLE STEP on the test thread, and then does a >> PopFrame on the test thread to force it out of the looping method. >> When the test failed due to a time out, I noticed it was still stuck >> in the small method, even though a PopFrame had been requested. >> Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since >> "interp only" mode for SINGLE STEP had been enabled, the method >> should not be running compiled, so clearly something went wrong that >> allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method >> (actually the top 2), put the thread in "interp only" mode, and then >> has checks to make sure the thread continues to execute interpreted. >> To avoid compilation when a back branch tries to trigger one, there >> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >> If the thread is in "interp only" mode, it will prevent compilation. >> SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called >> from the interpreter when the back branch threshold is reached. >> >> After some debugging I noticed when the test timeout happens, "interp >> only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is >> enabled by the time InterpreterRuntime::frequency_counter_overflow() >> has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp >> only" mode is enabled. I think the reason is because we safepoint >> during the compilation, and this allows a SINGLE STEP request to be >> processed, which enables "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but >> eventually realized it was caused by disabling BackgroundCompilation. >> That makes it much more likely that a SINGLE STEP request will come >> in and be processed during the call to >> InterpreterRuntime::frequency_counter_overflow() (because it will >> block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode >> check in InterpreterRuntime::frequency_counter_overflow() after the >> nm lookup, and set it nm to NULL if we are now in "interp only" mode. >> If we are not in "interp only" mode at this point (and start >> executing the compiled method) it should not be possible to enter >> "interp only" mode until we reach a safepoint at some later time, and >> at that point the method will be properly deopt so it can execute >> interpreted. >> >> thanks, >> >> Chris >> > From daniel.daugherty at oracle.com Mon Nov 6 20:41:23 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Nov 2017 15:41:23 -0500 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <901dc547-182d-155d-5340-b973731003e1@oracle.com> <54b19b95-a682-9422-b430-d6ea59e287d9@oracle.com> Message-ID: On 11/6/17 1:56 PM, Chris Plummer wrote: > Hi Dean, > > It looks like ciEnv::jvmti_state_changed() is used to support the > JVMTI AddCapabilities() interface, which I believe typically a JVMTI > agent uses to setup the available capabilities when the agent is first > loaded (although capabilities can by changed afterwords also). So I > don't see that code as being related to changing the thread to be > changed to "interp only" mode. Agreed. An agent enables a capability to indicate that it might want to use that capability/feature at some point during the agent's life. The compiler needs to know if an agent enabled specific capabilities because it may need to generate different code in order for specific features to work during compilation. The "interp only" mode state is set by the VM and is not directly managed by the agent. The agent may enable capabilities or events that cause "interp only" mode to be set and cleared, but it is not a mode that is directly managed by the agent. Put more simply: - The agent enables capabilities to indicate what it might want to do. - The "interp only" mode is set and cleared by the VM as the VM is ? actually doing stuff. Dan > > thanks, > > Chris > > On 11/3/17 9:44 PM, dean.long at oracle.com wrote: >> I'm not an expert in this area of code, but I'm wondering about >> Vladimir's comment about ciEnv::jvmti_state_changed() in the bug >> report. With your fix, maybe we don't need to check >> ciEnv::jvmti_state_changed() (which doesn't seem to be enough by >> itself) and throw away the compiled result.? We could just keep it >> around so it can be used when "interp only" mode is switched off. >> >> dl >> >> >> On 11/3/17 5:25 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> > > From serguei.spitsyn at oracle.com Tue Nov 7 00:58:08 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 Nov 2017 16:58:08 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> Message-ID: <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> Hi Chris, The fix looks good. I'm not that familiar with the compiler code to judge if this the best place to make this check. But, at least, it looks as such to me. Perhaps, it would be great if Vladimir could also look at it. But now pressure for this. Thanks, Serguei On 11/3/17 17:25, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8059334 > http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ > > The CR is closed, so I'll try to explain the issue here. The very > short explanation is that the JVMTI test was enabling SINGLE STEP and > doing a PopFrame, but the test method managed to get compiled and > started executing compiled after the thread was put in "interp only" > mode (which should never happen) and before the PopFrame was > processed. The cause is a lack of a check for "interp only" mode in > the OSR related compilation policy code. > > Details: > > The test is testing JVMTI PopFrame support. The test thread has a > small method that sits in a tight loop. It will never exit. The main > thread enables SINGLE STEP on the test thread, and then does a > PopFrame on the test thread to force it out of the looping method. > When the test failed due to a time out, I noticed it was still stuck > in the small method, even though a PopFrame had been requested. > Further, I noticed the method was compiled, so there was no chance the > method would ever detect that it should do a PopFrame. Since "interp > only" mode for SINGLE STEP had been enabled, the method should not be > running compiled, so clearly something went wrong that allowed it to > compile and execute. > > When SINGLE STEP is requested, JVMTI will deopt the topmost method > (actually the top 2), put the thread in "interp only" mode, and then > has checks to make sure the thread continues to execute interpreted. > To avoid compilation when a back branch tries to trigger one, there is > a check for "interp only" mode in SimpleThresholdPolicy::event(). If > the thread is in "interp only" mode, it will prevent compilation. > SimpleThresholdPolicy::event() is called (indirectly) by > InterpreterRuntime::frequency_counter_overflow(), which is called from > the interpreter when the back branch threshold is reached. > > After some debugging I noticed when the test timeout happens, "interp > only" mode is not yet enabled when > InterpreterRuntime::frequency_counter_overflow() is called, but is > enabled by the time InterpreterRuntime::frequency_counter_overflow() > has done the lookup of the nm. So there is a race here allowing the > thread to begin execution in a compiled method even though "interp > only" mode is enabled. I think the reason is because we safepoint > during the compilation, and this allows a SINGLE STEP request to be > processed, which enables "interp only" mode. > > I should add that initially I only saw this bug with -Xcomp, but > eventually realized it was caused by disabling BackgroundCompilation. > That makes it much more likely that a SINGLE STEP request will come in > and be processed during the call to > InterpreterRuntime::frequency_counter_overflow() (because it will > block until the compilation completes). > > I believe for the fix it is enough just to add an "interp only" mode > check in InterpreterRuntime::frequency_counter_overflow() after the nm > lookup, and set it nm to NULL if we are now in "interp only" mode. If > we are not in "interp only" mode at this point (and start executing > the compiled method) it should not be possible to enter "interp only" > mode until we reach a safepoint at some later time, and at that point > the method will be properly deopt so it can execute interpreted. > > thanks, > > Chris > From ujwal.vangapally at oracle.com Tue Nov 7 05:34:57 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 7 Nov 2017 11:04:57 +0530 Subject: RFR : JDK-8044122 MBean access to the PID In-Reply-To: <20d80859-32b0-0933-77ec-ced4a0f5f435@oracle.com> References: <2721cad6-a8a4-af6e-f0dd-90e933580003@oracle.com> <7b20fd53-e7e9-337a-d77a-e068deeb10b7@oracle.com> <6e09f0f8-6040-bd84-47f0-1e88239e9164@oracle.com> <0f405cfa-e47d-3b12-a919-8dea79724100@oracle.com> <4bf99bf0-53e3-42f8-0771-bfaada14fb51@oracle.com> <053745e8-88e5-84b6-da5a-42b13df86ac5@Oracle.com> <8d34373f-8d7e-7744-372e-dd17645d99f1@oracle.com> <0ef1923e-7bb6-890a-ba0f-c41c071b329c@oracle.com> <5857eda2-b57e-222c-877c-297da5133dc4@oracle.com> <20d80859-32b0-0933-77ec-ced4a0f5f435@oracle.com> Message-ID: <31db7ed8-3a8e-9361-3ea6-4366c13cd848@oracle.com> Hi, kindly take a look at latest changes. webrev: http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.05/ Thanks, Ujwal. On 10/31/2017 9:20 AM, Ujwal Vangapally wrote: > > Thanks for the Review Roger, Mandy. > > Ujwal. > > > On 10/31/2017 4:09 AM, mandy chung wrote: >> >> >> On 10/30/17 9:50 AM, Ujwal Vangapally wrote: >>> >>> Hi Mandy, >>> >>> yes, this makes it more clear. >>> >>> kindly take a look at new webrev. >>> >>> webrev : >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.04/ >>> >> >> Looks good. >> >> thanks >> Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Tue Nov 7 06:15:40 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 6 Nov 2017 22:15:40 -0800 Subject: RFR : JDK-8044122 MBean access to the PID In-Reply-To: <31db7ed8-3a8e-9361-3ea6-4366c13cd848@oracle.com> References: <2721cad6-a8a4-af6e-f0dd-90e933580003@oracle.com> <7b20fd53-e7e9-337a-d77a-e068deeb10b7@oracle.com> <6e09f0f8-6040-bd84-47f0-1e88239e9164@oracle.com> <0f405cfa-e47d-3b12-a919-8dea79724100@oracle.com> <4bf99bf0-53e3-42f8-0771-bfaada14fb51@oracle.com> <053745e8-88e5-84b6-da5a-42b13df86ac5@Oracle.com> <8d34373f-8d7e-7744-372e-dd17645d99f1@oracle.com> <0ef1923e-7bb6-890a-ba0f-c41c071b329c@oracle.com> <5857eda2-b57e-222c-877c-297da5133dc4@oracle.com> <20d80859-32b0-0933-77ec-ced4a0f5f435@oracle.com> <31db7ed8-3a8e-9361-3ea6-4366c13cd848@oracle.com> Message-ID: Looks good to me. Please do make docs target to verify. Mandy On 11/6/17 9:34 PM, Ujwal Vangapally wrote: > > Hi, > > kindly take a look at latest changes. > > webrev: > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.05/ > > Thanks, > > Ujwal. > > On 10/31/2017 9:20 AM, Ujwal Vangapally wrote: >> >> Thanks for the Review Roger, Mandy. >> >> Ujwal. >> >> >> On 10/31/2017 4:09 AM, mandy chung wrote: >>> >>> >>> On 10/30/17 9:50 AM, Ujwal Vangapally wrote: >>>> >>>> Hi Mandy, >>>> >>>> yes, this makes it more clear. >>>> >>>> kindly take a look at new webrev. >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.04/ >>>> >>> >>> Looks good. >>> >>> thanks >>> Mandy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Tue Nov 7 06:38:59 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 6 Nov 2017 22:38:59 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> Message-ID: <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> I have made changes to use the outputAnalyzer (thanks Jini). Latest webrev is : http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Sunday, November 05, 2017 10:04 PM To: David Holmes; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Thanks David for the comments. Reply inline. The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Monday, October 30, 2017 11:15 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Hi Sharath, I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. I have a few comments. On 30/10/2017 2:29 PM, Sharath Ballal wrote: > Hello, > > This webrev has changes for a framework for running the 'jhsdb clhsdb' > commands and verifying the output.? It also has sanity tests for 8 of I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... hsdb> hsdb> hsdb> flags .... ...... ZombieALotInterval = 5 0 hashCode = 5 0 hsdb> hsdb> My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); toolProcess.waitFor(); output = outputAnalyzer.getOutput(); Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? [Sharath Ballal] Launcher can do it. I have made the changes. Can the launcher internalize the management of the LingeredApp? [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. Can the launcher also handle the shouldSAAttach check? [Sharath Ballal] Yes. I have made that change. I can imagine the test logic reducing to a very simple: println(Starting test of ... List cmds = List.of( ...); List expected = List.of(...); List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. [Sharath Ballal] I have done this change. I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. [Sharath Ballal] OK. I have done these changes. It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. or the difference in expected output between: 57 "longConstant jtreg::test 6\n", 58 "longConstant jtreg::test\n", I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? [Sharath Ballal] Yes. I have provided a way to specify the expected/unexpected output per command and check it separately. Thanks, David > the clhsdb commands. > > Pls review the changes. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 > > Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ > > Thanks, > > Sharath > From jini.george at oracle.com Tue Nov 7 09:24:54 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 7 Nov 2017 14:54:54 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: <810c7db7-fe2a-45e1-92f9-2e34f1cc328a@oracle.com> Thank you very much, Sharath, for the review. My response inline: On 11/3/2017 3:44 PM, Sharath Ballal wrote: > Hi Jini, > > You have appended 'Field' for most of the SA variables. Example: > > private static CIntegerField pcOffsetField; > pcOffsetField = type.getCIntegerField("_pc_offset"); > > However that is not the case in > private static long MinChunkSizeInBytes; > MinChunkSizeInBytes = (type.getCIntegerField("_min_chunk_size_in_bytes")).getValue(); > > You may want to follow the same convention here. [Jini]: Unlike in the other cases, for MinChunkSizeInBytes, we are getting and storing the __value__ of the Field rather than the Field itself. Hence, I feel it might make more sense to not have 'Field' in this name. Thanks, Jini. > Rest of the changes look ok. > > Thanks, > Sharath (not a reviewer) > > > -----Original Message----- > From: Jini George > Sent: Thursday, November 02, 2017 10:24 AM > To: Serguei Spitsyn; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> > X-sender: > X-Receiver: > X-CreatedBy: MSExchange15 > X-HeloDomain: mx.expurgate.net > X-ExtendedProps: BQBjAAoAqbJ+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAGcrAAB2AAAABQBkAA8ABAAAAEVkZ2U= > X-Source: SMTP:External Receive Connector > X-SourceIPAddress: 195.190.135.10 > X-EndOfInjectedXHeaders: 7733 > Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de > (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov > 2017 05:54:39 +0100 > Received: from mx.expurgate.net (helo=localhost) > by mx.expurgate.net with esmtp > id 1eA7WZ-000EZw-D4 > for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:39 +0100 > Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) > by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) > (envelope-from ) > id 59faa50b-7c01-c0a8033409dd-9c971f454783-3 > for ; Thu, 02 Nov 2017 05:54:38 +0100 > Received: from aojmv0009 (unknown [137.254.59.6]) by ucsinet41.oracle.com with smtp > id 4eb7_00c7_3ecf1c93_28fd_4a9f_97f0_f31de9ddb295; > Thu, 02 Nov 2017 04:54:17 +0000 > Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) > by aojmv0009 (Postfix) with ESMTP id 15A99229CEC; > Thu, 2 Nov 2017 04:57:26 +0000 (UTC) > X-Original-To: serviceability-dev at openjdk.java.net > Delivered-To: serviceability-dev at openjdk.java.net > Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) > Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp > (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) > id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; > Thu, 02 Nov 2017 04:54:08 +0000 > Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id > vA24s8KW028461 > (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT > Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > From: Jini George > To: "serguei.spitsyn at oracle.com" , > "serviceability-dev at openjdk.java.net" , > "hotspot-runtime-dev at openjdk.java.net" > , > References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> > > <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> > > Organization: Oracle Corporation > Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> > Date: Thu, 2 Nov 2017 10:24:03 +0530 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.4.0 > MIME-Version: 1.0 > In-Reply-To: > Content-Type: text/plain; charset="utf-8"; format=flowed > Content-Language: en-US > Content-Transfer-Encoding: 7bit > X-Source-IP: userv0022.oracle.com [156.151.31.74] > X-BeenThere: serviceability-dev at openjdk.java.net > X-Mailman-Version: 2.1.17 > Precedence: list > List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Errors-To: serviceability-dev-bounces at openjdk.java.net > Sender: serviceability-dev > X-purgate-ID: tlsNG-9b91ac/1509598479-00007C01-219CB02A/0/0 > X-purgate-type: clean > X-purgate-size: 2000 > X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de > Comment: eleven transport token MTU2LjE1MS4zMS42OQBzZXJ2aWNlYWJpbGl0eS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADgwYzQ2ZTI0N2Q2MTBlYjNiNTQ5MmE5YWE2NzJjNzJjN2NiNjcwNDQ= > X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) > X-purgate: clean > X-SAP-SPAM-Status: clean > Return-Path: serviceability-dev-bounces at openjdk.java.net > X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:39.6785 > (UTC) > X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 > X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 > X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-AuthAs: Anonymous > X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-Network-Message-Id: 8fba1fcd-01cd-4a67-1ee6-08d521add313 > X-MS-Exchange-Organization-OriginalSize: 7400 > X-MS-Exchange-Organization-HygienePolicy: Standard > X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: > LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11997.291|UTH=0.001|RST=11997.244|QS=0.029|CATCM-McAfeeTxRoutingAgent=0.011|CATCM=0.011|CAT=0.012;2017-11-02T08:14:36.969Z > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> > X-sender: > X-Receiver: > X-CreatedBy: MSExchange15 > X-HeloDomain: mx.expurgate.net > X-ExtendedProps: BQBjAAoAALN+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAIMrAAB2AAAABQBkAA8ABAAAAEVkZ2U= > X-Source: SMTP:External Receive Connector > X-SourceIPAddress: 194.145.224.110 > X-EndOfInjectedXHeaders: 7704 > Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de > (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov > 2017 05:54:46 +0100 > Received: from mx.expurgate.net (helo=localhost) > by mx.expurgate.net with esmtp > id 1eA7Wg-0004R0-FP > for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:46 +0100 > Received: from [141.146.126.229] (helo=acsinet41.oracle.com) > by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) > (envelope-from ) > id 59faa50f-65eb-c0a8029b09dd-8d927ee53db9-3 > for ; Thu, 02 Nov 2017 05:54:45 +0100 > Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp > id 6461_15f0_154b24ba_5aa0_408c_88bd_1cdb37c9c8f4; > Thu, 02 Nov 2017 04:54:31 +0000 > Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) > by aojmv0009 (Postfix) with ESMTP id 3B280229CF4; > Thu, 2 Nov 2017 04:57:26 +0000 (UTC) > X-Original-To: hotspot-runtime-dev at openjdk.java.net > Delivered-To: hotspot-runtime-dev at openjdk.java.net > Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) > Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp > (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) > id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; > Thu, 02 Nov 2017 04:54:08 +0000 > Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id > vA24s8KW028461 > (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT > Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > From: Jini George > To: "serguei.spitsyn at oracle.com" , > "serviceability-dev at openjdk.java.net" , > "hotspot-runtime-dev at openjdk.java.net" > , > References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> > > <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> > > Organization: Oracle Corporation > Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> > Date: Thu, 2 Nov 2017 10:24:03 +0530 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.4.0 > MIME-Version: 1.0 > In-Reply-To: > Content-Type: text/plain; charset="utf-8"; format=flowed > Content-Language: en-US > Content-Transfer-Encoding: 7bit > X-Source-IP: userv0022.oracle.com [156.151.31.74] > X-BeenThere: hotspot-runtime-dev at openjdk.java.net > X-Mailman-Version: 2.1.17 > Precedence: list > List-Id: Technical discussion about the development of the HotSpot runtime subsystem > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Errors-To: hotspot-runtime-dev-bounces at openjdk.java.net > Sender: hotspot-runtime-dev > X-purgate-ID: tlsNG-81024b/1509598486-000065EB-186BA960/0/0 > X-purgate-type: clean > X-purgate-size: 2000 > X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de > Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtcnVudGltZS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADE0ZjI2NjVmYTY4ZGRiOWMwNGJiMGU0MmE2Njk2M2ZiNWQxNzAyOGI= > X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) > X-purgate: clean > X-SAP-SPAM-Status: clean > Return-Path: hotspot-runtime-dev-bounces at openjdk.java.net > X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:46.7566 > (UTC) > X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 > X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 > X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-AuthAs: Anonymous > X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-Network-Message-Id: 9365fa06-08de-47df-2865-08d521add74b > X-MS-Exchange-Organization-OriginalSize: 7380 > X-MS-Exchange-Organization-HygienePolicy: Standard > X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: > LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11990.260|UTH=0.001|RST=11990.260|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.005|CAT=0.006;2017-11-02T08:14:37.016Z > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> From ujwal.vangapally at oracle.com Tue Nov 7 10:04:17 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 7 Nov 2017 15:34:17 +0530 Subject: RFR : JDK-8044122 MBean access to the PID In-Reply-To: References: <2721cad6-a8a4-af6e-f0dd-90e933580003@oracle.com> <7b20fd53-e7e9-337a-d77a-e068deeb10b7@oracle.com> <6e09f0f8-6040-bd84-47f0-1e88239e9164@oracle.com> <0f405cfa-e47d-3b12-a919-8dea79724100@oracle.com> <4bf99bf0-53e3-42f8-0771-bfaada14fb51@oracle.com> <053745e8-88e5-84b6-da5a-42b13df86ac5@Oracle.com> <8d34373f-8d7e-7744-372e-dd17645d99f1@oracle.com> <0ef1923e-7bb6-890a-ba0f-c41c071b329c@oracle.com> <5857eda2-b57e-222c-877c-297da5133dc4@oracle.com> <20d80859-32b0-0933-77ec-ced4a0f5f435@oracle.com> <31db7ed8-3a8e-9361-3ea6-4366c13cd848@oracle.com> Message-ID: Thanks for the review Mandy, built image and verified everything is as expected. Ujwal. On 11/7/2017 11:45 AM, mandy chung wrote: > Looks good to me. > > Please do make docs target to verify. > > Mandy > > On 11/6/17 9:34 PM, Ujwal Vangapally wrote: >> >> Hi, >> >> kindly take a look at latest changes. >> >> webrev: >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.05/ >> >> Thanks, >> >> Ujwal. >> >> On 10/31/2017 9:20 AM, Ujwal Vangapally wrote: >>> >>> Thanks for the Review Roger, Mandy. >>> >>> Ujwal. >>> >>> >>> On 10/31/2017 4:09 AM, mandy chung wrote: >>>> >>>> >>>> On 10/30/17 9:50 AM, Ujwal Vangapally wrote: >>>>> >>>>> Hi Mandy, >>>>> >>>>> yes, this makes it more clear. >>>>> >>>>> kindly take a look at new webrev. >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8044122/webrev.04/ >>>>> >>>> >>>> Looks good. >>>> >>>> thanks >>>> Mandy >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Tue Nov 7 11:05:17 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 7 Nov 2017 16:35:17 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" Message-ID: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> Kindly review the fix for bug below. https://bugs.openjdk.java.net/browse/JDK-8024352 webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ Thanks, Ujwal. From Roger.Riggs at Oracle.com Tue Nov 7 15:40:39 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 7 Nov 2017 10:40:39 -0500 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> Message-ID: <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> Hi Ujwal, MBeanOperationInfo:163: Since the values are fixed, you could more concisely just compare impact >=0 and impact <= UNKNOWN. 257/263:? I don't see a reason to change the toString in the default case for getImpact(). A suggestion would be to introduce an Enum for the action values and the corresponding new method; perhaps deprecating the current method (or not). The enum would use the same values as currently and so internally the implementation does not change significantly. $.02, Roger On 11/7/2017 6:05 AM, Ujwal Vangapally wrote: > Kindly review the fix for bug below. > > https://bugs.openjdk.java.net/browse/JDK-8024352 > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ > > Thanks, > > Ujwal. > > From harsha.wardhana.b at oracle.com Tue Nov 7 16:26:05 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 7 Nov 2017 21:56:05 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <0483f2c9-892e-f842-bb5f-2b522b81b199@oracle.com> <6ec697c3-cb0d-ef5b-4a0c-e26e0cfc92b0@Oracle.com> <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: Hi, Please find below the webrev addressing Daniel and Mandy's comments. http://cr.openjdk.java.net/~hb/5016517/webrev.07/ -Harsha On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote: > On 31/10/2017 17:07, mandy chung wrote: >> On 10/31/17 8:55 AM, Harsha Wardhana B wrote: >>> >>> Hi Mandy, >>> >>> Below is the new webrev incorporating below review comments. >>> >>> http://cr.openjdk.java.net/~hb/5016517/webrev.06/ >> >> Looks okay in general except this: >> >> ? 286???????? // Check if header needs to be inserted >> ? 287???????? if (sbuf.indexOf("# The passwords in this file are >> hashed") != 0) { >> ? 288???????????? String lastUpdated = "# file last updated on - " >> ? 289???????????????????? + new SimpleDateFormat("MM/dd/yyyy >> HH:mm:ss").format(new Date()) + "\n\n"; >> ? 290???????????? sbuf.insert(0, header + lastUpdated); >> ? 291???????? } >> >> Relying on matching the partial header string is fragile. >> Also the timestamp is not updated if the file contains such >> heading but the file is re-written again. >> >> You should probably drop the header (auto-inserted), not add >> it to sbuf, and always add the header when updating the >> password file. > > Sorry Mandy, that was my demand. The header is several lines long. > It will look strange if it's added several times to the password file > every time the user/administrator adds/changes a password. > > Concerning FileLock - I'm not an expert there, but the Javadoc says: > > https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileLock.html > "File locks are held on behalf of the entire Java virtual machine. > ?They are not suitable for controlling access to a file by multiple > ?threads within the same virtual machine." > > Which means you need to also protect against concurrent writes to > the same file from within the same JVM by some other means. > > Also I wonder if HashedPasswordManager.authenticate should take > a char[] array rather than a String for the password. > > best regards, > > -- daniel > > > >> >> Mandy >> > From mandy.chung at oracle.com Tue Nov 7 16:54:50 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 7 Nov 2017 08:54:50 -0800 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <6ec697c3-cb0d-ef5b-4a0c-e26e0cfc92b0@Oracle.com> <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: On 11/7/17 8:26 AM, Harsha Wardhana B wrote: > Hi, > > Please find below the webrev addressing Daniel and Mandy's comments. > > http://cr.openjdk.java.net/~hb/5016517/webrev.07/ Can you summarize the change? I thought we agree to only replace the clear passwords with the hashes and not to alter any other content nor inserting any header.?? Also log a message when the file is overridden - we didn't discuss the format but I think it should include the pathname of the file and the role name of the overridden entries (should it be info level?).? line 308-311 is debug message - is that the one? Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Nov 7 17:04:37 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 7 Nov 2017 22:34:37 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: Hi Mandy, To summarize the changes, 1. The header will not contain the file modification timestamp. Instead when the password file is modified, a debug log will be printed. The log will contain the timestamp. 2. The password file is now protected from concurrent writes from within the JVM. 3. HashedPasswordManager.authenticate accepts char[] for password instead of String. -Harsha On Tuesday 07 November 2017 10:24 PM, mandy chung wrote: > > > On 11/7/17 8:26 AM, Harsha Wardhana B wrote: >> Hi, >> >> Please find below the webrev addressing Daniel and Mandy's comments. >> >> http://cr.openjdk.java.net/~hb/5016517/webrev.07/ > > Can you summarize the change? > > I thought we agree to only replace the clear passwords with the hashes > and not to alter any other content nor inserting any header. Header will be inserted. Apart from that all the comments will be retained. > Also log a message when the file is overridden - we didn't discuss the > format but I think it should include the pathname of the file and the > role name of the overridden entries (should it be info level?).? line > 308-311 is debug message - is that the one? I guess this wasn't discussed. We just output a debug log saying the file is overwritten. File name can be mentioned in the log. > > Mandy Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Nov 7 17:13:23 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 7 Nov 2017 17:13:23 +0000 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <6ec697c3-cb0d-ef5b-4a0c-e26e0cfc92b0@Oracle.com> <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: <4048f1da-1d02-df8f-aa6c-ba6e52d48505@oracle.com> Hi Harsha, HashedPasswordManager.java: I'd suggest to use java.nio.charset.StandardCharset.UTF_8 instead of Charset.forName("UTF-8"); The reading of the password file should probably not be allowed if some process (this one or another one) is currently writing to it, because you could just read some garbage. Maybe you'd need a ReadWriteLock here or something to avoid having this become a bottleneck - but then it probably means you'll need to keep track of which file is protected by a FileLock too. Also previously it was possible to update the password file while the agent was running, as the file was read with each login(). I'm suspecting your change will break this partly as it looks as if reloading the file does not clear the new userCredentialsMap. best regards, -- daniel On 07/11/2017 16:26, Harsha Wardhana B wrote: > Hi, > > Please find below the webrev addressing Daniel and Mandy's comments. > > http://cr.openjdk.java.net/~hb/5016517/webrev.07/ > > -Harsha > > On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote: >> On 31/10/2017 17:07, mandy chung wrote: >>> On 10/31/17 8:55 AM, Harsha Wardhana B wrote: >>>> >>>> Hi Mandy, >>>> >>>> Below is the new webrev incorporating below review comments. >>>> >>>> http://cr.openjdk.java.net/~hb/5016517/webrev.06/ >>> >>> Looks okay in general except this: >>> >>> ? 286???????? // Check if header needs to be inserted >>> ? 287???????? if (sbuf.indexOf("# The passwords in this file are >>> hashed") != 0) { >>> ? 288???????????? String lastUpdated = "# file last updated on - " >>> ? 289???????????????????? + new SimpleDateFormat("MM/dd/yyyy >>> HH:mm:ss").format(new Date()) + "\n\n"; >>> ? 290???????????? sbuf.insert(0, header + lastUpdated); >>> ? 291???????? } >>> >>> Relying on matching the partial header string is fragile. >>> Also the timestamp is not updated if the file contains such >>> heading but the file is re-written again. >>> >>> You should probably drop the header (auto-inserted), not add >>> it to sbuf, and always add the header when updating the >>> password file. >> >> Sorry Mandy, that was my demand. The header is several lines long. >> It will look strange if it's added several times to the password file >> every time the user/administrator adds/changes a password. >> >> Concerning FileLock - I'm not an expert there, but the Javadoc says: >> >> https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileLock.html >> "File locks are held on behalf of the entire Java virtual machine. >> ?They are not suitable for controlling access to a file by multiple >> ?threads within the same virtual machine." >> >> Which means you need to also protect against concurrent writes to >> the same file from within the same JVM by some other means. >> >> Also I wonder if HashedPasswordManager.authenticate should take >> a char[] array rather than a String for the password. >> >> best regards, >> >> -- daniel >> >> >> >>> >>> Mandy >>> >> > From ujwal.vangapally at oracle.com Tue Nov 7 17:18:28 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Tue, 7 Nov 2017 22:48:28 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> Message-ID: <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> Hi Roger, kindly see my understanding below. On 11/7/2017 9:10 PM, Roger Riggs wrote: > Hi Ujwal, > > MBeanOperationInfo:163: > Since the values are fixed, you could more concisely just compare > impact >=0 and impact <= UNKNOWN. As there are only 4 constants, I thought it would be better to include them directly instead of depending on there values. If it is a good practice to do it by comparing there values I will do it that way. > > 257/263: I don't see a reason to change the toString in the default > case for getImpact(). > As impact can't have any other value than 4 constants, we don't need the default case any more. > > A suggestion would be to introduce an Enum for the action values and > the corresponding new > method; perhaps deprecating the current method (or not). > The enum would use the same values as currently and so internally the > implementation does not > change significantly. Kindly clarify. As it changes the constructor signature if we introduce a Enum, but as we can solve the issue by throwing IAE, do we still need to introduce Enum and change method signature. Thanks, Ujwal. > > $.02, Roger > > > On 11/7/2017 6:05 AM, Ujwal Vangapally wrote: >> Kindly review the fix for bug below. >> >> https://bugs.openjdk.java.net/browse/JDK-8024352 >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ >> >> Thanks, >> >> Ujwal. >> >> > From vladimir.kozlov at oracle.com Tue Nov 7 18:39:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 10:39:18 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> Message-ID: <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> Looks good to me too. I assume you will add NULL check as Dan suggested. I thought that you may need to call nm->make_not_entrant() to deoptimize method. But on other hand you may still want to run compiled code in other threads. So your fix should is good for your problem. Thanks, Vladimir On 11/6/17 4:58 PM, serguei.spitsyn at oracle.com wrote: > Hi Chris, > > The fix looks good. > I'm not that familiar with the compiler code to judge if this the best place to make this check. > But, at least, it looks as such to me. > Perhaps, it would be great if Vladimir could also look at it. > But now pressure for this. > > Thanks, > Serguei > > > On 11/3/17 17:25, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8059334 >> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >> >> The CR is closed, so I'll try to explain the issue here. The very short explanation is that the JVMTI test was >> enabling SINGLE STEP and doing a PopFrame, but the test method managed to get compiled and started executing compiled >> after the thread was put in "interp only" mode (which should never happen) and before the PopFrame was processed. The >> cause is a lack of a check for "interp only" mode in the OSR related compilation policy code. >> >> Details: >> >> The test is testing JVMTI PopFrame support. The test thread has a small method that sits in a tight loop. It will >> never exit. The main thread enables SINGLE STEP on the test thread, and then does a PopFrame on the test thread to >> force it out of the looping method. When the test failed due to a time out, I noticed it was still stuck in the small >> method, even though a PopFrame had been requested. Further, I noticed the method was compiled, so there was no chance >> the method would ever detect that it should do a PopFrame. Since "interp only" mode for SINGLE STEP had been enabled, >> the method should not be running compiled, so clearly something went wrong that allowed it to compile and execute. >> >> When SINGLE STEP is requested, JVMTI will deopt the topmost method (actually the top 2), put the thread in "interp >> only" mode, and then has checks to make sure the thread continues to execute interpreted. To avoid compilation when a >> back branch tries to trigger one, there is a check for "interp only" mode in SimpleThresholdPolicy::event(). If the >> thread is in "interp only" mode, it will prevent compilation. SimpleThresholdPolicy::event() is called (indirectly) by >> InterpreterRuntime::frequency_counter_overflow(), which is called from the interpreter when the back branch threshold >> is reached. >> >> After some debugging I noticed when the test timeout happens, "interp only" mode is not yet enabled when >> InterpreterRuntime::frequency_counter_overflow() is called, but is enabled by the time >> InterpreterRuntime::frequency_counter_overflow() has done the lookup of the nm. So there is a race here allowing the >> thread to begin execution in a compiled method even though "interp only" mode is enabled. I think the reason is >> because we safepoint during the compilation, and this allows a SINGLE STEP request to be processed, which enables >> "interp only" mode. >> >> I should add that initially I only saw this bug with -Xcomp, but eventually realized it was caused by disabling >> BackgroundCompilation. That makes it much more likely that a SINGLE STEP request will come in and be processed during >> the call to InterpreterRuntime::frequency_counter_overflow() (because it will block until the compilation completes). >> >> I believe for the fix it is enough just to add an "interp only" mode check in >> InterpreterRuntime::frequency_counter_overflow() after the nm lookup, and set it nm to NULL if we are now in "interp >> only" mode. If we are not in "interp only" mode at this point (and start executing the compiled method) it should not >> be possible to enter "interp only" mode until we reach a safepoint at some later time, and at that point the method >> will be properly deopt so it can execute interpreted. >> >> thanks, >> >> Chris >> > From chris.plummer at oracle.com Tue Nov 7 19:55:42 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 7 Nov 2017 11:55:42 -0800 Subject: RFR(S): 8059334: nsk/jvmti/scenarios/hotswap/HS201/hs201t001 fails with exit code 0 after timeout In-Reply-To: <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> References: <94c478bd-6660-cf87-f7f8-391f5dccd7f9@oracle.com> <4a20d856-08e9-1a17-c6d0-ad0d0d3396b5@oracle.com> <36179db5-3a76-af68-773f-7a5d80370d4a@oracle.com> Message-ID: Hi Vladimir, I also considered calling nm->make_not_entrant(), but came to the same conclusion as you. thanks, Chris On 11/7/17 10:39 AM, Vladimir Kozlov wrote: > Looks good to me too. I assume you will add NULL check as Dan suggested. > > I thought that you may need to call nm->make_not_entrant() to > deoptimize method. But on other hand you may still want to run > compiled code in other threads. So your fix should is good for your > problem. > > Thanks, > Vladimir > > On 11/6/17 4:58 PM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> The fix looks good. >> I'm not that familiar with the compiler code to judge if this the >> best place to make this check. >> But, at least, it looks as such to me. >> Perhaps, it would be great if Vladimir could also look at it. >> But now pressure for this. >> >> Thanks, >> Serguei >> >> >> On 11/3/17 17:25, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8059334 >>> http://cr.openjdk.java.net/~cjplummer/8059334/webrev.00/webrev.open/ >>> >>> The CR is closed, so I'll try to explain the issue here. The very >>> short explanation is that the JVMTI test was enabling SINGLE STEP >>> and doing a PopFrame, but the test method managed to get compiled >>> and started executing compiled after the thread was put in "interp >>> only" mode (which should never happen) and before the PopFrame was >>> processed. The cause is a lack of a check for "interp only" mode in >>> the OSR related compilation policy code. >>> >>> Details: >>> >>> The test is testing JVMTI PopFrame support. The test thread has a >>> small method that sits in a tight loop. It will never exit. The main >>> thread enables SINGLE STEP on the test thread, and then does a >>> PopFrame on the test thread to force it out of the looping method. >>> When the test failed due to a time out, I noticed it was still stuck >>> in the small method, even though a PopFrame had been requested. >>> Further, I noticed the method was compiled, so there was no chance >>> the method would ever detect that it should do a PopFrame. Since >>> "interp only" mode for SINGLE STEP had been enabled, the method >>> should not be running compiled, so clearly something went wrong that >>> allowed it to compile and execute. >>> >>> When SINGLE STEP is requested, JVMTI will deopt the topmost method >>> (actually the top 2), put the thread in "interp only" mode, and then >>> has checks to make sure the thread continues to execute interpreted. >>> To avoid compilation when a back branch tries to trigger one, there >>> is a check for "interp only" mode in SimpleThresholdPolicy::event(). >>> If the thread is in "interp only" mode, it will prevent compilation. >>> SimpleThresholdPolicy::event() is called (indirectly) by >>> InterpreterRuntime::frequency_counter_overflow(), which is called >>> from the interpreter when the back branch threshold is reached. >>> >>> After some debugging I noticed when the test timeout happens, >>> "interp only" mode is not yet enabled when >>> InterpreterRuntime::frequency_counter_overflow() is called, but is >>> enabled by the time InterpreterRuntime::frequency_counter_overflow() >>> has done the lookup of the nm. So there is a race here allowing the >>> thread to begin execution in a compiled method even though "interp >>> only" mode is enabled. I think the reason is because we safepoint >>> during the compilation, and this allows a SINGLE STEP request to be >>> processed, which enables "interp only" mode. >>> >>> I should add that initially I only saw this bug with -Xcomp, but >>> eventually realized it was caused by disabling >>> BackgroundCompilation. That makes it much more likely that a SINGLE >>> STEP request will come in and be processed during the call to >>> InterpreterRuntime::frequency_counter_overflow() (because it will >>> block until the compilation completes). >>> >>> I believe for the fix it is enough just to add an "interp only" mode >>> check in InterpreterRuntime::frequency_counter_overflow() after the >>> nm lookup, and set it nm to NULL if we are now in "interp only" >>> mode. If we are not in "interp only" mode at this point (and start >>> executing the compiled method) it should not be possible to enter >>> "interp only" mode until we reach a safepoint at some later time, >>> and at that point the method will be properly deopt so it can >>> execute interpreted. >>> >>> thanks, >>> >>> Chris >>> >> From serguei.spitsyn at oracle.com Wed Nov 8 02:55:46 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Nov 2017 18:55:46 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> Message-ID: <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> On 11/6/17 04:31, Yasumasa Suenaga wrote: > Hi Serguei, > > On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> The changes looks good. >> Thank you for making them! > > Thanks! > > >> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> Thank you for your comment! >>> I uploaded new webrev: >>> >>> ? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>> >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>> >>>> >>>> - if (!ex.getMessage().contains("Invalid >>>> com.sun.management.jmxremote.port number")) { >>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>> >>>> >>>> ?? What is the motivation for this change? >>>> ?? It seems, the original comparison is better. >>> >>> "ex" is AttachOperationFailedException. >>> We can get the result as below when we run StartManagementAgent: >>> >>> ------------- >>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>> number: apa >>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>> java.lang.NumberFormatException: For input string: "apa" >>> [runApplication]??????? at >>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>> ------------- >>> >>> I think we should check exception message in >>> AttachOperationFailedException. >>> In fact, jtreg fails at this point in my environment. >> >> >> I'd expect a check for some exception name, not for details like: For >> input string: "apa". > > Should we remove this comparison? I don't understand. Why do remove? Would it better to check for the exception name instead? >>>> What tests did you run to make sure there are no regressions? >>> >>> I've tested the following testcases: >>> >>> ? - hotspot/jtreg/serviceability/attach >>> ? - hotspot/jtreg/serviceability/dcmd/jvmti >>> ? - jdk/com/sun/tools/attach >> >> There are more tests related to dynamic attach in closed, >> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >> I'm not sure, if they are included into any of the Mach5 testing >> levels. Will need to check. >> We have to make sure these tests are still passed. > > I cannot access JPRT and closed testcases because I'm not an Oracle > employee. > Can you run them with this change? Ok. I will sponsor this fix and run these tests before the push. It seems, another update and one more review is needed. Thanks, Serguei > > > Thanks, > > Yasumasa > > >> Thanks, >> Serguei >> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Some comments. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>> >>>> >>>> - if (!ex.getMessage().contains("Invalid >>>> com.sun.management.jmxremote.port number")) { >>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>> >>>> >>>> ?? What is the motivation for this change? >>>> ?? It seems, the original comparison is better. >>>> >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>> >>>> >>>> ?? 37???? public void run(CommandExecutor executor)? { >>>> ?? 38???????? try{ >>>> >>>> ?? A space is missed after 'try'. >>>> >>>> >>>> ?? It is odd that all test java classes define exactly the same >>>> methods: sharedObjectName(), jmx() and cli(). >>>> ?? Would it better to defin a common base class with these methods? >>>> >>>> >>>> Otherwise, it looks good. >>>> Thank you for taking care about it! >>>> >>>> What tests did you run to make sure there are no regressions? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>> PING: Could you review and sponsor it? >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load >>>>>> dcmd, we >>>>>> will get "Command executed successfully". However, it implies >>>>>> error in >>>>>> JVMTIAgentLoadDCmd. >>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>> from target VM. >>>>>> >>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>> understand the cause of failure. >>>>>> >>>>>> I uploaded webrev for this issue. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>> >>>>>> >>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>> testcases: >>>>>> >>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>> ?? - jdk/com/sun/tools/attach >>>>>> >>>>>> I cannot access JPRT. So I need a sponsor. >>>>>> (I cannot test it on other platforms.) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>> >> From mandy.chung at oracle.com Wed Nov 8 03:59:54 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 7 Nov 2017 19:59:54 -0800 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: On 11/7/17 9:04 AM, Harsha Wardhana B wrote: > > Hi Mandy, > > To summarize the changes, > > 1. The header will not contain the file modification timestamp. > Instead when the password file is modified, a debug log will be > printed. The log will contain the timestamp. > > 2. The password file is now protected from concurrent writes from > within the JVM. > > 3. HashedPasswordManager.authenticate accepts char[] for password > instead of String. > Thanks for this. That helps. > Header will be inserted. Apart from that all the comments will be > retained. I think this header can also be taken out.? The comment may already be copied from the template or deleted on purpose. >> Also log a message when the file is overridden - we didn't discuss >> the format but I think it should include the pathname of the file and >> the role name of the overridden entries (should it be info level?).? >> line 308-311 is debug message - is that the one? > I guess this wasn't discussed. We just output a debug log saying the > file is overwritten. File name can be mentioned in the log. INFO log message seems more appropriate. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Nov 8 06:38:09 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 8 Nov 2017 15:38:09 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> Message-ID: Hi Serguei, I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>> I'd expect a check for some exception name, not for details like: For >>> input string: "apa". >> >> >> Should we remove this comparison? > > > I don't understand. Why do remove? > Would it better to check for the exception name instead? I've changed to check exception name (NumberFormatException) in StartManagementAgent.java. > I will sponsor this fix and run these tests before the push. Thanks! I'm waiting for second reviewer. Yasumasa 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com : > On 11/6/17 04:31, Yasumasa Suenaga wrote: >> >> Hi Serguei, >> >> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Yasumasa, >>> >>> The changes looks good. >>> Thank you for making them! >> >> >> Thanks! >> >> >>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>> >>>> Hi Serguei, >>>> >>>> Thank you for your comment! >>>> I uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>> >>>> >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>> >>>>> - if (!ex.getMessage().contains("Invalid >>>>> com.sun.management.jmxremote.port number")) { >>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>> >>>>> >>>>> What is the motivation for this change? >>>>> It seems, the original comparison is better. >>>> >>>> >>>> "ex" is AttachOperationFailedException. >>>> We can get the result as below when we run StartManagementAgent: >>>> >>>> ------------- >>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>> number: apa >>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>> java.lang.NumberFormatException: For input string: "apa" >>>> [runApplication] at >>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>> ------------- >>>> >>>> I think we should check exception message in >>>> AttachOperationFailedException. >>>> In fact, jtreg fails at this point in my environment. >>> >>> >>> >>> I'd expect a check for some exception name, not for details like: For >>> input string: "apa". >> >> >> Should we remove this comparison? > > > I don't understand. Why do remove? > Would it better to check for the exception name instead? > > >>>>> What tests did you run to make sure there are no regressions? >>>> >>>> >>>> I've tested the following testcases: >>>> >>>> - hotspot/jtreg/serviceability/attach >>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>> - jdk/com/sun/tools/attach >>> >>> >>> There are more tests related to dynamic attach in closed, >>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>> I'm not sure, if they are included into any of the Mach5 testing levels. >>> Will need to check. >>> We have to make sure these tests are still passed. >> >> >> I cannot access JPRT and closed testcases because I'm not an Oracle >> employee. >> Can you run them with this change? > > > Ok. > I will sponsor this fix and run these tests before the push. > > It seems, another update and one more review is needed. > > Thanks, > Serguei > >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, >>> Serguei >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> Some comments. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>> >>>>> - if (!ex.getMessage().contains("Invalid >>>>> com.sun.management.jmxremote.port number")) { >>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>> >>>>> >>>>> What is the motivation for this change? >>>>> It seems, the original comparison is better. >>>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>> >>>>> 37 public void run(CommandExecutor executor) { >>>>> 38 try{ >>>>> >>>>> A space is missed after 'try'. >>>>> >>>>> >>>>> It is odd that all test java classes define exactly the same >>>>> methods: sharedObjectName(), jmx() and cli(). >>>>> Would it better to defin a common base class with these methods? >>>>> >>>>> >>>>> Otherwise, it looks good. >>>>> Thank you for taking care about it! >>>>> >>>>> What tests did you run to make sure there are no regressions? >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>> >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>> will get "Command executed successfully". However, it implies error >>>>>>> in >>>>>>> JVMTIAgentLoadDCmd. >>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>> from target VM. >>>>>>> >>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>> understand the cause of failure. >>>>>>> >>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>> >>>>>>> >>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>> testcases: >>>>>>> >>>>>>> - hotspot/jtreg/serviceability/attach >>>>>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>> - jdk/com/sun/tools/attach >>>>>>> >>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>> (I cannot test it on other platforms.) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>> >>> > From harsha.wardhana.b at oracle.com Wed Nov 8 10:49:35 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 8 Nov 2017 16:19:35 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: <4048f1da-1d02-df8f-aa6c-ba6e52d48505@oracle.com> References: <1ceb614a-585d-2ccd-0877-f99202c43718@oracle.com> <5892e0b2-51c6-6a22-5a39-d4ab93ca2fcf@oracle.com> <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> <4048f1da-1d02-df8f-aa6c-ba6e52d48505@oracle.com> Message-ID: Hi Daniel, On Tuesday 07 November 2017 10:43 PM, Daniel Fuchs wrote: > Hi Harsha, > > HashedPasswordManager.java: > > I'd suggest to use java.nio.charset.StandardCharset.UTF_8 instead of > Charset.forName("UTF-8"); ok. > > The reading of the password file should probably not be allowed if > some process (this one or another one) is currently writing to it, > because you could just read some garbage. I think reading a file while it is being written to might give us incomplete data (depending on how often we flush the stream) but not garbage. > > Maybe you'd need a ReadWriteLock here or something to avoid > having this become a bottleneck - but then it probably means > you'll need to keep track of which file is protected by > a FileLock too. I think using a local lock (synchronized block or r/w lock) in conjunction with FileLock for both read/write operations should solve this problem. I am not sure why we need to keep track of FileLocks. I will send a modified webrev. > > Also previously it was possible to update the > password file while the agent was running, as the file was > read with each login(). > I'm suspecting your change will break this partly as it > looks as if reloading the file does not clear the > new userCredentialsMap. Now also the file gets reloaded for each login. Not clearing the userCredentialMap might leave stale entries (which should be cleared), but new entries will get updated and hence it will not break existing functionality. The test-cases validate the above use-case. > > best regards, > > -- daniel > > -Harsha > On 07/11/2017 16:26, Harsha Wardhana B wrote: >> Hi, >> >> Please find below the webrev addressing Daniel and Mandy's comments. >> >> http://cr.openjdk.java.net/~hb/5016517/webrev.07/ >> >> -Harsha >> >> On Wednesday 01 November 2017 09:42 PM, Daniel Fuchs wrote: >>> On 31/10/2017 17:07, mandy chung wrote: >>>> On 10/31/17 8:55 AM, Harsha Wardhana B wrote: >>>>> >>>>> Hi Mandy, >>>>> >>>>> Below is the new webrev incorporating below review comments. >>>>> >>>>> http://cr.openjdk.java.net/~hb/5016517/webrev.06/ >>>> >>>> Looks okay in general except this: >>>> >>>> ? 286???????? // Check if header needs to be inserted >>>> ? 287???????? if (sbuf.indexOf("# The passwords in this file are >>>> hashed") != 0) { >>>> ? 288???????????? String lastUpdated = "# file last updated on - " >>>> ? 289???????????????????? + new SimpleDateFormat("MM/dd/yyyy >>>> HH:mm:ss").format(new Date()) + "\n\n"; >>>> ? 290???????????? sbuf.insert(0, header + lastUpdated); >>>> ? 291???????? } >>>> >>>> Relying on matching the partial header string is fragile. >>>> Also the timestamp is not updated if the file contains such >>>> heading but the file is re-written again. >>>> >>>> You should probably drop the header (auto-inserted), not add >>>> it to sbuf, and always add the header when updating the >>>> password file. >>> >>> Sorry Mandy, that was my demand. The header is several lines long. >>> It will look strange if it's added several times to the password file >>> every time the user/administrator adds/changes a password. >>> >>> Concerning FileLock - I'm not an expert there, but the Javadoc says: >>> >>> https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileLock.html >>> >>> "File locks are held on behalf of the entire Java virtual machine. >>> ?They are not suitable for controlling access to a file by multiple >>> ?threads within the same virtual machine." >>> >>> Which means you need to also protect against concurrent writes to >>> the same file from within the same JVM by some other means. >>> >>> Also I wonder if HashedPasswordManager.authenticate should take >>> a char[] array rather than a String for the password. >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> >>>> >>>> Mandy >>>> >>> >> > From thomas.schatzl at oracle.com Wed Nov 8 13:07:05 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 08 Nov 2017 14:07:05 +0100 Subject: Low-Overhead Heap Profiling In-Reply-To: References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> Message-ID: <1510146425.3155.11.camel@oracle.com> Hi JC, sorry for the long wait. On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > Dear all, > > Here is the next webrev: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > Incremental since the rebase: > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > (I'm still not too familiar with hg so I had to do a fresh rebase so > v14 is once the rebase was done and v14a integrates the changes > requested from Thomas). Yeah, there seem to be something missing in the incremental webrev, but thanks for the effort. > I have also inlined answers to Thomas' email: > > A few minor issues: > ? > > ? - in the declaration of CollectedHeap::sample_allocation, it > > would be nice if the fix_sample_rate parameter would be described - > > it takes a time to figure out what it's used for. I.e. in case an > > allocation goes beyond the sampling watermark, this value which > > represents the amount of overallocation is used to adjust the next > > sampling watermark to sample at the correct rate. > > Something like this - and if what I wrote is incorrect, there is > > even more reason to document it. > > Or maybe just renaming "fix_sample_rate" to something more > > descriptive - but I have no good idea about that. > > With lack of units in the type, it would also be nice to have the > > unit in the identifier name, as done elsewhere. > Thanks. Could you s/passed/past in that documentation? > Done for Robbin's issue and changed it to? > > ? - some (or most actually) of the new setters and getters in the > > ThreadLocalAllocBuffer class could be private I think. Also, we > > typically do not use "simple" getters that just return a member in > > the class where they are defined. > > I removed all that were not used that I could see (not used outside > the class) moved the ones that are not simple to private if they > could be. I think it's a bit weird because now some of the setting of > the tlab internal data is using methods, others are directly setting. > Let me know what you think. That's fine with me. You need to start somewhere I guess. > > ? - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making > > the first check an assert - it seems that it is only useful to call > > this with heap monitoring enabled, as is done right now. > > Longer conversation below about this, It cannot be an assert (I could > remove the test altogether though). I looked at the description, and you are right. I missed that. Keep it as is. :) > > - HeapMonitoring::next_random() - the different names for the > > constants use different formatting. Preferable (to me) is > > UpperCamelCase, but at least make them uniform. > > > > I think done the way you wanted! In heapMonitoring.hpp:50-53 the constants still have different format? ? > > ? > > ? - not really convinced that it is a good idea to not somehow > > guard > > StartHeapSampling() and StopHeapSampling() against being called by > > multiple threads. > > > > I added another mutex for the start/stop so that way it will protect > from that. > Thanks! > ? > > Otherwise looks okay from what I can see. Still okay. I do not need a re-review for the changes suggested in this email. > > Awesome, what do you think I still need for this before going to the > next step (which is what by the way? :)). I think: - look through the JEP if it is still current and fix the descriptions if required - add a link to the latest webrev to the JEP as comment - if not done already, file CSRs [0] for - the new flag - JVMTI changes (I think, not sure actually) - find a sponsor from Oracle to do some internal work (pushing, and before that there is iirc still some background work related to JEPs that can only be done by Oracle, mostly shepherding :/). I talked to Robbin about this, and he offered to help you with that. Thanks, Thomas [0] https://wiki.openjdk.java.net/display/csr/Main From jini.george at oracle.com Wed Nov 8 17:19:16 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 8 Nov 2017 22:49:16 +0530 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: <0138549d-340a-f552-1355-1817b2190426@gmail.com> References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> <0138549d-340a-f552-1355-1817b2190426@gmail.com> Message-ID: <9073999d-4369-b284-496c-7aab2d0b4dd2@oracle.com> Hi Yasumasa, Your changes look good to me overall. Some nits: * src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java (lines 138 to 152): -> It would be nice if you could indent the "case" statements. * src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java -> It would be good if the indentation here for the newly added lines matches that of the rest of the file. (4 spaces instead of 2). * src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java -> Lines 198-212: I feel this commented out code could be removed and replaced by a call to printLockInfo(), though I am not entirely sure as to when this printOn() gets exercised. * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java -> You can remove these lines: import java.util.Scanner; import java.util.stream.Collectors; import java.io.File; Thanks, Jini (Not a Reviewer). On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ > > > Thanks, > > Yasumasa > > > On 2017/10/09 23:19, Yasumasa Suenaga wrote: >> Hi all, >> >> I uploaded new webrev to be adapted to current jdk10/hs: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >> >> >> Please review and sponsor it. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I uploaded new webrev to be adapted to jdk10/hs: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>> Thanks Jini! >>>> >>>> I uploaded new webrev: >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>> >>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>> `jhsdb clhsdb`. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/08/24 18:01, Jini George wrote: >>>>> Apologize for the late reply, Yasumasa. >>>>> >>>>> >>>>>> I think so, but I guess it is difficult. >>>>>> For example, test for CLHSDB command is provided as >>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>> But target process seems to be fixed to "LingeredApp". >>>>>> Can we change it to another program which generates lock contention? >>>>> >>>>> You can take a look at any of the >>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>> this. The target process does not have to be be fixed to >>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>> test-specific variations built on top of LingeredApp for ease of >>>>> implementation. >>>>> >>>>> Thanks, >>>>> Jini. From daniel.daugherty at oracle.com Wed Nov 8 17:49:43 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 12:49:43 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: Message-ID: <543b5bd6-1f5e-37df-d4fc-199b4e67fca3@oracle.com> Greetings, This code review from Stefan Karlsson was originally posted on an Oracle internal alias that we use for discussing HotSpot SMR development issues. That subject was: "Thread-SMR (8167108)(JDK10): CR round 0 changes". I did not have time to address Stefan's review before I went on vacation and Stefan graciously allowed me to defer his review to the OpenJDK review. With Stefan's permission, I'm replying to his code review on the OpenJDK aliases that we're using for the JDK-8167108 code review. On 10/6/17 1:19 PM, Stefan Karlsson wrote: > Hi Dan, > > Great that this is getting done! Thanks! It has been an adventure for all three primary contributors... > Erik already mentioned the file so I think that's on track, and that's > what I was most concerned about. > > > I have not been involved in the review of this patch at all, but now > that I've been looking at it I have a few comments. I hope you don't > mind. I don't want them to block the open review request, but at the > same time I'd like to share my opinion and have it weighted in for the > future of this code. > > 1) ThreadsListHandle allows a safepoint to block and allow GCs to run > and restructure objects and metadata, iff the ThreadsListHandle is > nested. This forced me to review all usages of ThreadsListHandle in > great detail to visually verify that it didn't break the surrounding code. > > If ThreadsListHandle didn't ever block for safepoints, I wouldn't have > had to care about that aspect when reading and reviewing the code. > This also means that we in the future runs the risk of someone > accidentally adding a nested ThreadsListHandle somewhere where they > don't expect a safepoint to happen. We included the following to automatically sanity check the placement of the ThreadsListHandle: src/hotspot/share/runtime/thread.cpp: 3596 ThreadsList *Threads::acquire_stable_list(Thread *self, bool is_ThreadsListSetter) { 3597?? assert(self != NULL, "sanity check"); 3598?? // acquire_stable_list_nested_path() will grab the Threads_lock 3599?? // so let's make sure the ThreadsListHandle is in a safe place. 3600?? // ThreadsListSetter cannot make this check on this code path. 3601?? debug_only(if (!is_ThreadsListSetter && StrictSafepointChecks) self->check_for_valid_safepoint_state(/* potential_vm_operation */ false);) So each ThreadsListHandle location is checked for being a valid safepoint state. We tested this idea with our work on JvmtiEnv::GetThreadLocalStorage(). GetThreadLocalStorage() is called from the 'in native' state so we cannot place a common ThreadsListHandle for all code paths because it would fail the assertion when called with 'thread == NULL', i.e., the thread is operating on itself. Update: Erik is going to explore a lock free solution for the nesting algorithm. That will likely mean that a ThreadsListHandle will not require placement in a safepoint safe location... > If the lock protecting the threads list could be taken with > no_safepoint_check, then the described problem above would completely > vanish. Unfortunately, we can't acquire the Threads_lock with > no_safepoint_check. A solution to this would be to introduced a > low-rank (rank == access) lock, say ThreadsList_lock, and always take > it with no_safepoint_check. The problem with switching locks is that we are protecting the scanning phase of the SMR algorithm with the Threads_lock so we would have to switch that lock also. I believe we use the Threads_lock with the scanning because we're using closures... Of course, Erik or Robbin should probably jump in here... :-) Update: Erik is going to explore a lock-free solution for the nesting algorithm. > That solution would also solve a potential lock-rank problem, we have > that ThreadsListHandle can't be used if a higher-rank lock is held. So far we haven't run into that problem and we think that the check_for_valid_safepoint_state() will catch that if the code should evolve to introduce one. Update: Erik is going to explore a lock-free solution for the nesting algorithm. > 2) The following one-liner: > - for (JavaThread* t = Threads::first(); t; t = t->next()) { > has been converted to a five-liner: > > + { > + ThreadsListHandle tlh; > + JavaThreadIterator jti(tlh.list()); > + for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { > ... + } I find that unfortunate, and would prefer if this was > rewritten. For example: for (JavaThreadIterator jti; JavaThread* t = > jit.next();) { jti will implicitly hold the ThreadListHandle on the > stack. I know that the implicit conversion of pointer to bool is > non-conventional in the HotSpot code, but in this case I prefer that > over five lines of extra noise in the GC code. Coleen made a similar comment in her OpenJDK review: > Hi,? From my initial look at this, I really like new interface for > walking the threads list, except every instance but 2 uses of > JavaThreadIterator has a preceding ThreadsListHandle declaration. > > +? ThreadsListHandle tlh; > +? JavaThreadIterator jti(tlh.list()); > > > Could there be a wrapper that embeds the ThreadsListHandle, like: > > class JavaThreadsListIterator { > ??? ThreadsListHandle _tlh; > ... > } Yup a definite code noise problem. We originally didn't have an iterator and used direct thread_at(foo) calls so we had a pretty close correspondence between the old for-loop and the new for-loop. Early reviewers asked for an iterator abstraction so we modeled JavaThreadIterator after other existing iterators in the JVM/TI area... (Yes, Dan stayed pretty close to "home" here...) There are places where we still need the existing JavaThreadIterator because a ThreadsList is passed down a call stack... So we've added a JavaThreadIteratorWithHandle class. Here's an example of the noisy code in the GC area: src/hotspot/share/gc/g1/dirtyCardQueue.cpp: @@ -319,8 +320,12 @@ ?? clear(); ?? // Since abandon is done only at safepoints, we can safely manipulate ?? // these queues. -? for (JavaThread* t = Threads::first(); t; t = t->next()) { -??? t->dirty_card_queue().reset(); +? { +??? ThreadsListHandle tlh; +??? JavaThreadIterator jti(tlh.list()); +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { +????? t->dirty_card_queue().reset(); +??? } ?? } ?? shared_dirty_card_queue()->reset(); ?} Here's an example of the revised code in the GC area: src/hotspot/share/gc/g1/dirtyCardQueue.cpp: @@ -319,7 +320,7 @@ ?? clear(); ?? // Since abandon is done only at safepoints, we can safely manipulate ?? // these queues. -? for (JavaThread* t = Threads::first(); t; t = t->next()) { +? for (JavaThreadIteratorWithHandle jtiwh; JavaThread *t = jtiwh.next(); ) { ???? t->dirty_card_queue().reset(); ?? } ?? shared_dirty_card_queue()->reset(); This is definitely much less noisy and I'm hoping I don't catch too much grief for the implied boolean usage... > 3) cv_internal_thread_to_JavaThread Has one return value and two > output parameter. It forces the callers to setup stack lock variables > for the two new variables. --- Used to be --- > - oop java_thread = JNIHandles::resolve_non_null(jthread); > java_lang_Thread::set_priority(java_thread, (ThreadPriority)prio); - > JavaThread* thr = java_lang_Thread::thread(java_thread); - if (thr != > NULL) { // Thread not yet started; priority pushed down when it is - > Thread::set_priority(thr, (ThreadPriority)prio); > --- Now is --- > + oop java_thread = NULL; + JavaThread* receiver = NULL; + bool > is_alive = tlh.cv_internal_thread_to_JavaThread(jthread, &receiver, > &java_thread); java_lang_Thread::set_priority(java_thread, > (ThreadPriority)prio); + + if (is_alive) { + // jthread refers to a > live JavaThread. + Thread::set_priority(receiver, > (ThreadPriority)prio); --- Maybe could be --- > oop java_thread = JNIHandles::resolve_non_null(jthread); > java_lang_Thread::set_priority(java_thread, (ThreadPriority)prio); > JavaThread* thr = tlh.cv_internal_thread_to_JavaThread(java_thread); > if (thr != NULL) { // Thread not yet started; priority pushed down > when it is Thread::set_priority(thr, (ThreadPriority)prio); I don't > see the need to for the extra complexity of the two output parameters. > The return value is always true when thr is non-null, and always false > when thr is null. There are three cv_*_to_JavaThread() functions and we had to craft them very, very carefully to avoid changing some of the subtle semantics at the original call sites. If you carefully examine the output parameters and return value usages at all of the call sites, you'll see that each was added to fit some existing semantic that we didn't want to risk changing. Of course, not all of the call sites need all of the special behaviors individually, but they do as a union. In short, compatibility and risk management led us here. > But the usage of cv_internal_thread_to_JavaThread is contained within > the Runtime code, so my opinion should probably not weigh as much as > other's opinions. :) We definitely agree this is a mess, but not one we're willing to risk changing at this time. Dan has made the observation that the JVM_* entry points, like Y2K code, shows a variety of different coding patterns, each with different (potential) issues... Thanks for being flexible on accepting cv_internal_thread_to_JavaThread() as is for now! > 4) I'd prefer if abbreviations where expanded, so that the casual > reader would immediately understood the code. For example: t_list -> > thread_list cv_internal_thread_to_JavaThread -> > internal_thread_to_JavaThread We've had requests to shorten names, spell out names, use different names, etc. It seems that no one is going to be happy with all of the names we used in this code. Our guidelines: - use the same consistently, e.g., t_list for ThreadsLists - use a name that doesn't show up in an existing grep (if possible) We hope you don't mind, but we're not planning to make any more name changes... > 5) This macro and the jesting is pretty bad. Yup! > I complained about it to Erik, and then he confessed that he wrote it :D > +// Possibly the ugliest for loop the world has seen. C++ does not > allow +// multiple types in the declaration section of the for loop. > In this case +// we are only dealing with pointers and hence can cast > them. It looks ugly +// but macros are ugly and therefore it's fine to > make things absurdly ugly. +#define DO_JAVA_THREADS(LIST, X) \ + for > (JavaThread *MACRO_scan_interval = > (JavaThread*)(uintptr_t)PrefetchScanIntervalInBytes, \ + *MACRO_list = > (JavaThread*)(LIST), \ + **MACRO_end = > ((JavaThread**)((ThreadsList*)MACRO_list)->threads()) + > ((ThreadsList*)MACRO_list)->length(), \ + **MACRO_current_p = > (JavaThread**)((ThreadsList*)MACRO_list)->threads(), \ + *X = > (JavaThread*)prefetch_and_load_ptr((void**)MACRO_current_p, > (intx)MACRO_scan_interval); \ + MACRO_current_p != MACRO_end; \ + > MACRO_current_p++, \ + X = > (JavaThread*)prefetch_and_load_ptr((void**)MACRO_current_p, > (intx)MACRO_scan_interval)) + This can be rewritten without all these > cast, and minimal usage of the macros expansions: struct > JavaThreadPrefetchedIterator { ThreadList* _list; JavaThread** _end; > JavaThread** _current; JavaThreadIteror(ThreadList* list) : > _list(list), _end(list->threads() + list->length()), > _current(list->threads()) {} JavaThread* current() { return > context._current != context._end ?? > prefetch_and_load_ptr(context._current, PrefetchScanIntervalInBytes) > ?: NULL) // ^ prefetch would be rewritten to return JavaThread* and > not void* } void next() { _current++; }; #define DO_JAVA_THREADS(LIST, > X) \ for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = > iter.current(); iter.next()) (I did some changes to the code above and > haven't compiled this exact version) Erik hasn't chimed in on this comment so I (Dan) am not planning to try to resolve this comment in this round. Update: Erik is planning to look at cleaning up the ugly macro... > 6) I think it would be nice if the SMR stuff in thread.hpp were > encapsulated into an class instead of added directly to Thread and > Threads. I sort-of expected the SMR variables to be moved to > threadSMR.hpp. For example: > class Threads: AllStatic { friend class VMStructs; private: + // Safe > Memory Reclamation (SMR) support: + static Monitor* _smr_delete_lock; > + // The '_cnt', '_max' and '_times" fields are enabled via + // > -XX:+EnableThreadSMRStatistics: + static uint > _smr_delete_lock_wait_cnt; + static uint _smr_delete_lock_wait_max; + > static volatile int _smr_delete_notify; + static volatile jint > _smr_deleted_thread_cnt; + static volatile jint > _smr_deleted_thread_time_max; + static volatile jint > _smr_deleted_thread_times; + static ThreadsList* volatile > _smr_java_thread_list; + static ThreadsList* > get_smr_java_thread_list() { + return > (ThreadsList*)OrderAccess::load_ptr_acquire((void* > volatile*)&_smr_java_thread_list); + } + static ThreadsList* > xchg_smr_java_thread_list(ThreadsList* new_list) { + return > (ThreadsList*)Atomic::xchg_ptr((void*)new_list, (volatile > void*)&_smr_java_thread_list); + } + static long > _smr_java_thread_list_alloc_cnt; + static long > _smr_java_thread_list_free_cnt; + static uint > _smr_java_thread_list_max; + static uint _smr_nested_thread_list_max; > + static volatile jint _smr_tlh_cnt; + static volatile jint > _smr_tlh_time_max; + static volatile jint _smr_tlh_times; + static > ThreadsList* _smr_to_delete_list; + static uint > _smr_to_delete_list_cnt; + static uint _smr_to_delete_list_max; Could > be: class Threads: AllStatic { friend class VMStructs; private: // > Safe Memory Reclamation (SMR) support: SMRSupport _smr_support; And > SMRSupport could be moved to threadSMR.hpp. I haven't read all the > code in detail, so I'm not sure if this is feasible or not, but my > gut-feeling says that it would be worth testing. The above is just an > example, and the rest of the code could probably be encapsulated and > moved as well. We already moved all of the SMR stuff that was "easy" to move based on your earlier comment. (Of course, doing that move introduced a number of compilation complications, but that's just Dan complaining :-)) We don't really want to try this migration at this time since we're still hoping to get this code into 18.3. (Also Dan doesn't see the value in moving the SMR fields... Threads is already an eclectic static class so why does SMR have to encapsulate when no other project did so?) > 7) Currently, threadSMR.hpp "only" contains the ThreadList. Unless, > you move the SMR stuff into threadSMR.hpp, maybe it should be renamed > to threadsList.hpp? Maybe it does make sense to have both > threadSMR.hpp and threadsList.hpp? We're planning to stick with the threadSMR.hpp and threadSMR.cpp file names. Currently they contain the more standalone pieces of thread SMR (more than just ThreadsList) so we're planning to keep those names. Thanks for the detailed review!! Dan, Erik and Robbin > Cheers and thanks! StefanK -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 8 17:53:22 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 12:53:22 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <2b180329-9cf3-d83b-133b-ddd5d33b4f1f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <2b180329-9cf3-d83b-133b-ddd5d33b4f1f@oracle.com> Message-ID: <10022dbf-74a6-5b38-265e-079ebaad22c8@oracle.com> Added back the other three OpenJDK aliases being used for this review... Coleen, thanks for chiming in on this review thread. Sorry for the delay in responding... I was on vacation... On 10/11/17 11:32 AM, coleen.phillimore at oracle.com wrote: > > Hi,? From my initial look at this, I really like new interface for > walking the threads list, except every instance but 2 uses of > JavaThreadIterator has a preceding ThreadsListHandle declaration. > > +? ThreadsListHandle tlh; > +? JavaThreadIterator jti(tlh.list()); > > > Could there be a wrapper that embeds the ThreadsListHandle, like: > > class JavaThreadsListIterator { > ??? ThreadsListHandle _tlh; > ... > } This issue has been addressed as part of my response to Stefan K's code review comments. I quoted the above comment in that reply so it should be easy to find that resolution... Dan > > Thanks, > Coleen > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn > From daniel.daugherty at oracle.com Wed Nov 8 18:05:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 13:05:57 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: Greetings, Resolving one of the code review comments (from both Stefan K and Coleen) on jdk10-04-full required quite a few changes so it is being done as a standalone patch and corresponding webrevs: Here's the mq comment for the change: ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use ??? JavaThreadIteratorWithHandle. Here is the full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ And here is the delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: > Greetings, > > We have a (eXtra Large) fix for the following bug: > > 8167108 inconsistent handling of SR_lock can lead to crashes > https://bugs.openjdk.java.net/browse/JDK-8167108 > > This fix adds a Safe Memory Reclamation (SMR) mechanism based on > Hazard Pointers to manage JavaThread lifecycle. > > Here's a PDF for the internal wiki that we've been using to describe > and track the work on this project: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf > > > Dan has noticed that the indenting is wrong in some of the code quotes > in the PDF that are not present in the internal wiki. We don't have a > solution for that problem yet. > > Here's the webrev for current JDK10 version of this fix: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full > > This fix has been run through many rounds of JPRT and Mach5 tier[2-5] > testing, additional stress testing on Dan's Solaris X64 server, and > additional testing on Erik and Robbin's machines. > > We welcome comments, suggestions and feedback. > > Daniel Daugherty > Erik Osterlund > Robbin Ehn > From ujwal.vangapally at oracle.com Wed Nov 8 18:34:11 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 9 Nov 2017 00:04:11 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> Message-ID: <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> Thanks for the suggestions Roger, Mandy. below is webrev incorporating review comments. http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.02/ CSR: https://bugs.openjdk.java.net/browse/JDK-8190197 Thanks, Ujwal On 11/7/2017 10:48 PM, Ujwal Vangapally wrote: > Hi Roger, > > kindly see my understanding below. > > > On 11/7/2017 9:10 PM, Roger Riggs wrote: >> Hi Ujwal, >> >> MBeanOperationInfo:163: >> Since the values are fixed, you could more concisely just compare >> impact >=0 and impact <= UNKNOWN. > As there are only 4 constants, I thought it would be better to include > them directly instead of depending on there values. > > If it is a good practice to do it by comparing there values I will do > it that way. >> >> 257/263: I don't see a reason to change the toString in the default >> case for getImpact(). >> > As impact can't have any other value than 4 constants, we don't need > the default case any more. >> >> A suggestion would be to introduce an Enum for the action values and >> the corresponding new >> method; perhaps deprecating the current method (or not). >> The enum would use the same values as currently and so internally the >> implementation does not >> change significantly. > Kindly clarify. > As it changes the constructor signature if we introduce a Enum, > but as we can solve the issue by throwing IAE, do we still need to > introduce Enum and change method signature. > > Thanks, > Ujwal. >> >> $.02, Roger >> >> >> On 11/7/2017 6:05 AM, Ujwal Vangapally wrote: >>> Kindly review the fix for bug below. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8024352 >>> >>> webrev : >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ >>> >>> Thanks, >>> >>> Ujwal. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 8 23:09:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 18:09:41 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: <1c0edbe2-1b9c-dc7e-c610-4ea053831790@oracle.com> The jdk10-05-full bits have passed JPRT testing (hs-tier1 testing) and hs-tier[2-5] testing via Mach 5. No unexpected test failures. Dan On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: > Greetings, > > Resolving one of the code review comments (from both Stefan K and Coleen) > on jdk10-04-full required quite a few changes so it is being done as a > standalone patch and corresponding webrevs: > > Here's the mq comment for the change: > > ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use > ??? JavaThreadIteratorWithHandle. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn >> > > From daniel.fuchs at oracle.com Thu Nov 9 10:07:46 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 9 Nov 2017 10:07:46 +0000 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> Message-ID: Hi Ujwal, Give that there are only 4 legal values to check then maybe you could check all of them in the test (and not simply 2). best regards, -- daniel On 08/11/2017 18:34, Ujwal Vangapally wrote: > Thanks for the suggestions Roger, Mandy. > > below is webrev incorporating review comments. > > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.02/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8190197 > > Thanks, > > Ujwal > > On 11/7/2017 10:48 PM, Ujwal Vangapally wrote: >> Hi Roger, >> >> kindly see my understanding below. >> >> >> On 11/7/2017 9:10 PM, Roger Riggs wrote: >>> Hi Ujwal, >>> >>> MBeanOperationInfo:163: >>> Since the values are fixed, you could more concisely just compare >>> impact >=0 and impact <= UNKNOWN. >> As there are only 4 constants, I thought it would be better to include >> them directly instead of depending on there values. >> >> If it is a good practice to do it by comparing there values I will do >> it that way. >>> >>> 257/263:? I don't see a reason to change the toString in the default >>> case for getImpact(). >>> >> As impact can't have any other value than 4 constants, we don't need >> the default case any more. >>> >>> A suggestion would be to introduce an Enum for the action values and >>> the corresponding new >>> method; perhaps deprecating the current method (or not). >>> The enum would use the same values as currently and so internally the >>> implementation does not >>> change significantly. >> Kindly clarify. >> As it changes the constructor signature if we introduce a Enum, >> but as we can solve the issue by throwing IAE, do we still need to >> introduce Enum and change method signature. >> >> Thanks, >> Ujwal. >>> >>> $.02, Roger >>> >>> >>> On 11/7/2017 6:05 AM, Ujwal Vangapally wrote: >>>> Kindly review the fix for bug below. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8024352 >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Ujwal. >>>> >>>> >>> >> > From ujwal.vangapally at oracle.com Thu Nov 9 10:40:30 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 9 Nov 2017 16:10:30 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> Message-ID: <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Thanks for the Review Daniel, made changes as suggested. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ Ujwal. On 11/9/2017 3:37 PM, Daniel Fuchs wrote: > Hi Ujwal, > > Give that there are only 4 legal values to check then maybe > you could check all of them in the test (and not simply 2). > > best regards, > > -- daniel > > > On 08/11/2017 18:34, Ujwal Vangapally wrote: >> Thanks for the suggestions Roger, Mandy. >> >> below is webrev incorporating review comments. >> >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.02/ >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8190197 >> >> Thanks, >> >> Ujwal >> >> On 11/7/2017 10:48 PM, Ujwal Vangapally wrote: >>> Hi Roger, >>> >>> kindly see my understanding below. >>> >>> >>> On 11/7/2017 9:10 PM, Roger Riggs wrote: >>>> Hi Ujwal, >>>> >>>> MBeanOperationInfo:163: >>>> Since the values are fixed, you could more concisely just compare >>>> impact >=0 and impact <= UNKNOWN. >>> As there are only 4 constants, I thought it would be better to >>> include them directly instead of depending on there values. >>> >>> If it is a good practice to do it by comparing there values I will >>> do it that way. >>>> >>>> 257/263: I don't see a reason to change the toString in the >>>> default case for getImpact(). >>>> >>> As impact can't have any other value than 4 constants, we don't need >>> the default case any more. >>>> >>>> A suggestion would be to introduce an Enum for the action values >>>> and the corresponding new >>>> method; perhaps deprecating the current method (or not). >>>> The enum would use the same values as currently and so internally >>>> the implementation does not >>>> change significantly. >>> Kindly clarify. >>> As it changes the constructor signature if we introduce a Enum, >>> but as we can solve the issue by throwing IAE, do we still need to >>> introduce Enum and change method signature. >>> >>> Thanks, >>> Ujwal. >>>> >>>> $.02, Roger >>>> >>>> >>>> On 11/7/2017 6:05 AM, Ujwal Vangapally wrote: >>>>> Kindly review the fix for bug below. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8024352 >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ujwal. >>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Thu Nov 9 11:34:37 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 9 Nov 2017 11:34:37 +0000 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: <7b5d28b4-cdaa-68d4-ec24-f2416d432bf6@oracle.com> On 09/11/2017 10:40, Ujwal Vangapally wrote: > Thanks for the Review Daniel, made changes as suggested. > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ Looks good to me. -- daniel > > Ujwal. > From yasuenag at gmail.com Thu Nov 9 13:25:58 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 9 Nov 2017 22:25:58 +0900 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: <9073999d-4369-b284-496c-7aab2d0b4dd2@oracle.com> References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> <0138549d-340a-f552-1355-1817b2190426@gmail.com> <9073999d-4369-b284-496c-7aab2d0b4dd2@oracle.com> Message-ID: Hi Jini, Thank you for your comment! I've fixed and uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ > * > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java > > -> Lines 198-212: I feel this commented out code could be removed and > replaced by a call to printLockInfo(), though I am not entirely sure as > to when this printOn() gets exercised. I agree with you to remove these comments. They are insufficient to show all locks like a my first webrev [1]. webrev.04 is implemented to follow HotSpot implementation. Thanks, Yasumasa [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ On 2017/11/09 2:19, Jini George wrote: > Hi Yasumasa, > > Your changes look good to me overall. Some nits: > > * > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java > (lines 138 to 152): > -> It would be nice if you could indent the "case" statements. > > * > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java > -> It would be good if the indentation here for the newly added lines > matches that of the rest of the file. (4 spaces instead of 2). > > * > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java > > -> Lines 198-212: I feel this commented out code could be removed and > replaced by a call to printLockInfo(), though I am not entirely sure as > to when this printOn() gets exercised. > > * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java > -> You can remove these lines: > import java.util.Scanner; > import java.util.stream.Collectors; > import java.io.File; > > Thanks, > Jini (Not a Reviewer). > > > On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/10/09 23:19, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I uploaded new webrev to be adapted to current jdk10/hs: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>> >>> >>> Please review and sponsor it. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I uploaded new webrev to be adapted to jdk10/hs: >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>>> Thanks Jini! >>>>> >>>>> I uploaded new webrev: >>>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>>> >>>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>>> `jhsdb clhsdb`. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/08/24 18:01, Jini George wrote: >>>>>> Apologize for the late reply, Yasumasa. >>>>>> >>>>>> >>>>>>> I think so, but I guess it is difficult. >>>>>>> For example, test for CLHSDB command is provided as >>>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>>> But target process seems to be fixed to "LingeredApp". >>>>>>> Can we change it to another program which generates lock contention? >>>>>> >>>>>> You can take a look at any of the >>>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>>> this. The target process does not have to be be fixed to >>>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>>> test-specific variations built on top of LingeredApp for ease of >>>>>> implementation. >>>>>> >>>>>> Thanks, >>>>>> Jini. From roger.riggs at oracle.com Thu Nov 9 14:22:08 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 9 Nov 2017 09:22:08 -0500 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <7b5d28b4-cdaa-68d4-ec24-f2416d432bf6@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> <7b5d28b4-cdaa-68d4-ec24-f2416d432bf6@oracle.com> Message-ID: <3c0d40ff-2a09-67b7-e7e2-0a1cc3d363e6@oracle.com> +1 Looks good, Thanks, Roger On 11/9/17 6:34 AM, Daniel Fuchs wrote: > On 09/11/2017 10:40, Ujwal Vangapally wrote: >> Thanks for the Review Daniel, made changes as suggested. >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ > > Looks good to me. > > -- daniel > >> >> Ujwal. >> From jini.george at oracle.com Thu Nov 9 14:25:21 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 9 Nov 2017 19:55:21 +0530 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> <0138549d-340a-f552-1355-1817b2190426@gmail.com> <9073999d-4369-b284-496c-7aab2d0b4dd2@oracle.com> Message-ID: Hi Yasumasa, This looks fine to me. Thank you, Jini (Not a Reviewer). On 11/9/2017 6:55 PM, Yasumasa Suenaga wrote: > Hi Jini, > > Thank you for your comment! > I've fixed and uploaded new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ > >> * >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >> >> >> -> Lines 198-212: I feel this commented out code could be removed and >> replaced by a call to printLockInfo(), though I am not entirely sure as >> to when this printOn() gets exercised. > > I agree with you to remove these comments. > They are insufficient to show all locks like a my first webrev [1]. > webrev.04 is implemented to follow HotSpot implementation. > > > Thanks, > > Yasumasa > > > [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ > > > > On 2017/11/09 2:19, Jini George wrote: >> Hi Yasumasa, >> >> Your changes look good to me overall. Some nits: >> >> * >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java >> >> (lines 138 to 152): >> -> It would be nice if you could indent the "case" statements. >> >> * >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java >> >> -> It would be good if the indentation here for the newly added lines >> matches that of the rest of the file. (4 spaces instead of 2). >> >> * >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >> >> >> -> Lines 198-212: I feel this commented out code could be removed and >> replaced by a call to printLockInfo(), though I am not entirely sure as >> to when this printOn() gets exercised. >> >> * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java >> -> You can remove these lines: >> import java.util.Scanner; >> import java.util.stream.Collectors; >> import java.io.File; >> >> Thanks, >> Jini (Not a Reviewer). >> >> >> On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/10/09 23:19, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I uploaded new webrev to be adapted to current jdk10/hs: >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>> >>>> >>>> Please review and sponsor it. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I uploaded new webrev to be adapted to jdk10/hs: >>>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>>>> Thanks Jini! >>>>>> >>>>>> I uploaded new webrev: >>>>>> >>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>>>> >>>>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>>>> `jhsdb clhsdb`. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/08/24 18:01, Jini George wrote: >>>>>>> Apologize for the late reply, Yasumasa. >>>>>>> >>>>>>> >>>>>>>> I think so, but I guess it is difficult. >>>>>>>> For example, test for CLHSDB command is provided as >>>>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>>>> But target process seems to be fixed to "LingeredApp". >>>>>>>> Can we change it to another program which generates lock >>>>>>>> contention? >>>>>>> >>>>>>> You can take a look at any of the >>>>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>>>> this. The target process does not have to be be fixed to >>>>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>>>> test-specific variations built on top of LingeredApp for ease of >>>>>>> implementation. >>>>>>> >>>>>>> Thanks, >>>>>>> Jini. From ujwal.vangapally at oracle.com Thu Nov 9 14:28:59 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 9 Nov 2017 19:58:59 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <3c0d40ff-2a09-67b7-e7e2-0a1cc3d363e6@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> <7b5d28b4-cdaa-68d4-ec24-f2416d432bf6@oracle.com> <3c0d40ff-2a09-67b7-e7e2-0a1cc3d363e6@oracle.com> Message-ID: <169ff1b0-5f58-9475-c25a-a393979f22dd@oracle.com> Thanks for the Review Daniel, Roger. Ujwal On 11/9/2017 7:52 PM, Roger Riggs wrote: > +1 > > Looks good, > > Thanks, Roger > > > On 11/9/17 6:34 AM, Daniel Fuchs wrote: >> On 09/11/2017 10:40, Ujwal Vangapally wrote: >>> Thanks for the Review Daniel, made changes as suggested. >>> >>> webrev : >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ >> >> Looks good to me. >> >> -- daniel >> >>> >>> Ujwal. >>> > From yasuenag at gmail.com Thu Nov 9 14:34:06 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 9 Nov 2017 23:34:06 +0900 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: References: <1734e8a3-5178-2953-2b42-b443177e9cc2@gmail.com> <33bf35e5-7d8b-db21-4209-edd675c42d85@oracle.com> <66c16569-d7bd-3f4c-6dff-b5b27a77d38f@gmail.com> <56759c30-f67c-3f1d-e056-70a090c916b0@gmail.com> <0138549d-340a-f552-1355-1817b2190426@gmail.com> <9073999d-4369-b284-496c-7aab2d0b4dd2@oracle.com> Message-ID: <6768f8b5-427b-fafe-e175-a567bd4ad7fb@gmail.com> Thanks, Jini! I'm waiting for Reviewer and sponsor. Yasumasa On 2017/11/09 23:25, Jini George wrote: > Hi Yasumasa, > > This looks fine to me. > > Thank you, > Jini (Not a Reviewer). > > On 11/9/2017 6:55 PM, Yasumasa Suenaga wrote: >> Hi Jini, >> >> Thank you for your comment! >> I've fixed and uploaded new webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ >> >>> * >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>> >>> -> Lines 198-212: I feel this commented out code could be removed and >>> replaced by a call to printLockInfo(), though I am not entirely sure as >>> to when this printOn() gets exercised. >> >> I agree with you to remove these comments. >> They are insufficient to show all locks like a my first webrev [1]. >> webrev.04 is implemented to follow HotSpot implementation. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ >> >> >> >> On 2017/11/09 2:19, Jini George wrote: >>> Hi Yasumasa, >>> >>> Your changes look good to me overall. Some nits: >>> >>> * >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java >>> (lines 138 to 152): >>> -> It would be nice if you could indent the "case" statements. >>> >>> * >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java >>> -> It would be good if the indentation here for the newly added lines >>> matches that of the rest of the file. (4 spaces instead of 2). >>> >>> * >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>> >>> -> Lines 198-212: I feel this commented out code could be removed and >>> replaced by a call to printLockInfo(), though I am not entirely sure as >>> to when this printOn() gets exercised. >>> >>> * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java >>> -> You can remove these lines: >>> import java.util.Scanner; >>> import java.util.stream.Collectors; >>> import java.io.File; >>> >>> Thanks, >>> Jini (Not a Reviewer). >>> >>> >>> On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review and sponsor it? >>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2017/10/09 23:19, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I uploaded new webrev to be adapted to current jdk10/hs: >>>>> >>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>>> >>>>> >>>>> Please review and sponsor it. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I uploaded new webrev to be adapted to jdk10/hs: >>>>>> >>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>>>>> Thanks Jini! >>>>>>> >>>>>>> I uploaded new webrev: >>>>>>> >>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>>>>> >>>>>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>>>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>>>>> `jhsdb clhsdb`. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/08/24 18:01, Jini George wrote: >>>>>>>> Apologize for the late reply, Yasumasa. >>>>>>>> >>>>>>>> >>>>>>>>> I think so, but I guess it is difficult. >>>>>>>>> For example, test for CLHSDB command is provided as >>>>>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>>>>> But target process seems to be fixed to "LingeredApp". >>>>>>>>> Can we change it to another program which generates lock contention? >>>>>>>> >>>>>>>> You can take a look at any of the >>>>>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>>>>> this. The target process does not have to be be fixed to >>>>>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>>>>> test-specific variations built on top of LingeredApp for ease of >>>>>>>> implementation. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jini. From mandy.chung at oracle.com Thu Nov 9 15:40:48 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 9 Nov 2017 07:40:48 -0800 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: On 11/9/17 2:40 AM, Ujwal Vangapally wrote: > Thanks for the Review Daniel, made changes as suggested. > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ > Looks good. Minor comment: in the new test, it can fold some of the println together e.g. line 81 can be merged with line 39 to include the value being passed.? Similarly for the println in the main method. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ujwal.vangapally at oracle.com Thu Nov 9 17:03:11 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Thu, 9 Nov 2017 22:33:11 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: Thanks for the review Mandy, kindly check if this version is better. webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ Ujwal On 11/9/2017 9:10 PM, mandy chung wrote: > > > On 11/9/17 2:40 AM, Ujwal Vangapally wrote: >> Thanks for the Review Daniel, made changes as suggested. >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ >> > > Looks good. > > Minor comment: in the new test, it can fold some of the println > together e.g. line 81 can be merged with line 39 to include the value > being passed. Similarly for the println in the main method. > > Mandy > From mandy.chung at oracle.com Thu Nov 9 17:13:38 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 9 Nov 2017 09:13:38 -0800 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: On 11/9/17 9:03 AM, Ujwal Vangapally wrote: > Thanks for the review Mandy, > > kindly check if this version is better. > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ Looks okay. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Fri Nov 10 12:38:18 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 10 Nov 2017 18:08:18 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: References: <85633749-9830-dcd5-97a5-411f684776bd@oracle.com> <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> Message-ID: <2268040c-2043-13db-075e-573229ff0c97@oracle.com> Hi, Please find the below webrev with the following changes. 1. All the reads/writes into the password file are synchronized w.r.t threads within the JVM and across multiple JVM processes. It is possible that some edits made to file while the agent is running might be lost and hence added a cautionary note in jmxremote.password.template. 2. Added a new test-case 'testMultipleClients' that validates concurrent read/writes 3. Added an info log when the password file is over-written. http://cr.openjdk.java.net/~hb/5016517/webrev.08/ Please review the latest webrev. Thanks Harsha On Wednesday 08 November 2017 09:29 AM, mandy chung wrote: > > > On 11/7/17 9:04 AM, Harsha Wardhana B wrote: >> >> Hi Mandy, >> >> To summarize the changes, >> >> 1. The header will not contain the file modification timestamp. >> Instead when the password file is modified, a debug log will be >> printed. The log will contain the timestamp. >> >> 2. The password file is now protected from concurrent writes from >> within the JVM. >> >> 3. HashedPasswordManager.authenticate accepts char[] for password >> instead of String. >> > > Thanks for this. That helps. >> Header will be inserted. Apart from that all the comments will be >> retained. > > I think this header can also be taken out.? The comment may already be > copied from the template or deleted on purpose. > >>> Also log a message when the file is overridden - we didn't discuss >>> the format but I think it should include the pathname of the file >>> and the role name of the overridden entries (should it be info >>> level?).? line 308-311 is debug message - is that the one? >> I guess this wasn't discussed. We just output a debug log saying the >> file is overwritten. File name can be mentioned in the log. > > INFO log message seems more appropriate. > > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Nov 10 14:20:36 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Nov 2017 14:20:36 +0000 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: <2268040c-2043-13db-075e-573229ff0c97@oracle.com> References: <83690f04-4cdb-ce11-a744-7d4372ec7500@oracle.com> <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> <2268040c-2043-13db-075e-573229ff0c97@oracle.com> Message-ID: <5aeb8c18-7752-fe0c-d916-122f9c19e17e@oracle.com> Hi Harsha, On 10/11/2017 12:38, Harsha Wardhana B wrote: > Hi, > > Please find the below webrev with the following changes. > > 1. All the reads/writes into the password file are synchronized w.r.t > threads within the JVM and across multiple JVM processes. It is possible > that some edits made to file while the agent is running might be lost > and hence added a cautionary note in jmxremote.password.template. OK - given the complexity of the alternative I believe what you have now should be considered "good enough". We can always revisit later if it proves to cause issues. Thanks for adding the note to the jmxremote.password.template. > 2. Added a new test-case 'testMultipleClients' that validates concurrent > read/writes Thanks for doing that! > > 3. Added an info log when the password file is over-written. > > http://cr.openjdk.java.net/~hb/5016517/webrev.08/ > > Please review the latest webrev. HashPasswordManager: 204 } catch (NoSuchAlgorithmException ex) { 205 if (logger.warningOn()) { 206 logger.warning("authenticate", "Unrecognized hash algorithm : " 207 + userCredentialsMap.get(userName).hashAlgorithm 208 + " - for user : " + userName); 209 } 210 return false; 211 } 212 } else { 213 if (logger.warningOn()) { 214 logger.warning("authenticate", "Unknown user : " + userName); 215 } 216 return false; 217 } and elsewhere in this file: these should not be warnings: debug at the most. 318 if (logger.infoOn()) { 319 logger.info("loadPasswords", 320 "Wrote hashed passwords to file : " + passwordFile); 321 } I think this should be debug as well. The last one might probably stay as a warning but if so: 1. it should be printed only once (and not for every new client that comes) 2. It might need to be internationalized. 322 } else if (logger.warningOn()) { 323 logger.warning("loadPasswords", 324 "Passwords in " + passwordFile + " are in clear and password file is read-only. " 325 + "Passwords cannot be hashed !!!!"); 326 } The rest looks good to me! best regards, -- daniel > > Thanks > Harsha > > On Wednesday 08 November 2017 09:29 AM, mandy chung wrote: >> >> >> On 11/7/17 9:04 AM, Harsha Wardhana B wrote: >>> >>> Hi Mandy, >>> >>> To summarize the changes, >>> >>> 1. The header will not contain the file modification timestamp. >>> Instead when the password file is modified, a debug log will be >>> printed. The log will contain the timestamp. >>> >>> 2. The password file is now protected from concurrent writes from >>> within the JVM. >>> >>> 3. HashedPasswordManager.authenticate accepts char[] for password >>> instead of String. >>> >> >> Thanks for this. That helps. >>> Header will be inserted. Apart from that all the comments will be >>> retained. >> >> I think this header can also be taken out.? The comment may already be >> copied from the template or deleted on purpose. >> >>>> Also log a message when the file is overridden - we didn't discuss >>>> the format but I think it should include the pathname of the file >>>> and the role name of the overridden entries (should it be info >>>> level?).? line 308-311 is debug message - is that the one? >>> I guess this wasn't discussed. We just output a debug log saying the >>> file is overwritten. File name can be mentioned in the log. >> >> INFO log message seems more appropriate. >> >> Mandy > From harsha.wardhana.b at oracle.com Mon Nov 13 05:26:12 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 13 Nov 2017 10:56:12 +0530 Subject: RFE Review : JDK-5016517 - Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent In-Reply-To: <5aeb8c18-7752-fe0c-d916-122f9c19e17e@oracle.com> References: <02f07607-b713-a6ef-4e2c-24d642eb595a@oracle.com> <53972784-d929-6196-ed59-5d466a273b7e@oracle.com> <486455cb-1937-49a9-d55d-664cbdfc4524@oracle.com> <4fc3b0b3-3e6b-3409-ff4c-e748f2b87f3f@oracle.com> <37a59c19-d663-63b0-5524-9c0473ea8359@oracle.com> <4e0878cc-dc07-cc91-5068-6f58004f38f3@oracle.com> <756895b6-3d3c-9027-de97-9a776f896cdb@oracle.com> <2268040c-2043-13db-075e-573229ff0c97@oracle.com> <5aeb8c18-7752-fe0c-d916-122f9c19e17e@oracle.com> Message-ID: Hi Daniel, Maintaining a warning or info log requires internationalization and since java.management module does not have the necessary resource bundles, it becomes complicated to take up that activity as a part of this enhancement.? Hence I have changed all the logs to debug. We can take up changing logging level and internationalization as a separate issue. I have updated the webrev in-place. Please review and let me know if you are okay with it. Thanks Harsha On Friday 10 November 2017 07:50 PM, Daniel Fuchs wrote: > Hi Harsha, > > On 10/11/2017 12:38, Harsha Wardhana B wrote: >> Hi, >> >> Please find the below webrev with the following changes. >> >> 1. All the reads/writes into the password file are synchronized w.r.t >> threads within the JVM and across multiple JVM processes. It is >> possible that some edits made to file while the agent is running >> might be lost and hence added a cautionary note in >> jmxremote.password.template. > > OK - given the complexity of the alternative I believe what you > have now should be considered "good enough". We can always revisit > later if it proves to cause issues. Thanks for adding the note > to the jmxremote.password.template. > >> 2. Added a new test-case 'testMultipleClients' that validates >> concurrent read/writes > > Thanks for doing that! > >> >> 3. Added an info log when the password file is over-written. >> >> http://cr.openjdk.java.net/~hb/5016517/webrev.08/ >> >> Please review the latest webrev. > > HashPasswordManager: > > ?204???????????? } catch (NoSuchAlgorithmException ex) { > ?205???????????????? if (logger.warningOn()) { > ?206???????????????????? logger.warning("authenticate", "Unrecognized > hash algorithm : " > ?207???????????????????????????? + > userCredentialsMap.get(userName).hashAlgorithm > ?208???????????????????????????? + " - for user : " + userName); > ?209???????????????? } > ?210???????????????? return false; > ?211???????????? } > ?212???????? } else { > ?213???????????? if (logger.warningOn()) { > ?214???????????????? logger.warning("authenticate", "Unknown user : " > + userName); > ?215???????????? } > ?216???????????? return false; > ?217???????? } > > and elsewhere in this file: these should not be warnings: debug at > the most. > > ?318???????????????? if (logger.infoOn()) { > ?319???????????????????? logger.info("loadPasswords", > ?320???????????????????????????? "Wrote hashed passwords to file : " + > passwordFile); > ?321???????????????? } > > I think this should be debug as well. > > > The last one might probably stay as a warning but if so: > > ?? 1. it should be printed only once (and not for every > ????? new client that comes) > ?? 2. It might need to be internationalized. > > ?322???????????? } else if (logger.warningOn()) { > ?323???????????????? logger.warning("loadPasswords", > ?324???????????????????????? "Passwords in " + passwordFile + " are in > clear and password file is read-only. " > ?325???????????????????????????????? + "Passwords cannot be hashed > !!!!"); > ?326???????????? } > > The rest looks good to me! > > best regards, > > -- daniel > >> >> Thanks >> Harsha >> >> On Wednesday 08 November 2017 09:29 AM, mandy chung wrote: >>> >>> >>> On 11/7/17 9:04 AM, Harsha Wardhana B wrote: >>>> >>>> Hi Mandy, >>>> >>>> To summarize the changes, >>>> >>>> 1. The header will not contain the file modification timestamp. >>>> Instead when the password file is modified, a debug log will be >>>> printed. The log will contain the timestamp. >>>> >>>> 2. The password file is now protected from concurrent writes from >>>> within the JVM. >>>> >>>> 3. HashedPasswordManager.authenticate accepts char[] for password >>>> instead of String. >>>> >>> >>> Thanks for this. That helps. >>>> Header will be inserted. Apart from that all the comments will be >>>> retained. >>> >>> I think this header can also be taken out.? The comment may already >>> be copied from the template or deleted on purpose. >>> >>>>> Also log a message when the file is overridden - we didn't discuss >>>>> the format but I think it should include the pathname of the file >>>>> and the role name of the overridden entries (should it be info >>>>> level?). line 308-311 is debug message - is that the one? >>>> I guess this wasn't discussed. We just output a debug log saying >>>> the file is overwritten. File name can be mentioned in the log. >>> >>> INFO log message seems more appropriate. >>> >>> Mandy >> > From daniel.daugherty at oracle.com Mon Nov 13 17:30:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 13 Nov 2017 12:30:57 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> Message-ID: <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> Greetings, I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. Here are the updated webrevs: Here's the mq comment for the change: ? Rebase to 2017.10.25 PIT snapshot. Here is the full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ And here is the delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ I ran the above bits throught Mach5 tier[1-5] testing over the holiday weekend. Didn't see any issues in a quick look. Going to take a closer look today. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: > Greetings, > > Resolving one of the code review comments (from both Stefan K and Coleen) > on jdk10-04-full required quite a few changes so it is being done as a > standalone patch and corresponding webrevs: > > Here's the mq comment for the change: > > ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use > ??? JavaThreadIteratorWithHandle. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> We have a (eXtra Large) fix for the following bug: >> >> 8167108 inconsistent handling of SR_lock can lead to crashes >> https://bugs.openjdk.java.net/browse/JDK-8167108 >> >> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >> Hazard Pointers to manage JavaThread lifecycle. >> >> Here's a PDF for the internal wiki that we've been using to describe >> and track the work on this project: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >> >> >> Dan has noticed that the indenting is wrong in some of the code quotes >> in the PDF that are not present in the internal wiki. We don't have a >> solution for that problem yet. >> >> Here's the webrev for current JDK10 version of this fix: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >> >> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >> testing, additional stress testing on Dan's Solaris X64 server, and >> additional testing on Erik and Robbin's machines. >> >> We welcome comments, suggestions and feedback. >> >> Daniel Daugherty >> Erik Osterlund >> Robbin Ehn >> > > From yasuenag at gmail.com Tue Nov 14 00:55:52 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 14 Nov 2017 09:55:52 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached Message-ID: PING: Could you reivew it? We need one more reviewer. > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ Thanks, Yasumasa 2017-11-08 15:38 GMT+09:00 Yasumasa Suenaga : > Hi Serguei, > > I uploaded new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ > >>>> I'd expect a check for some exception name, not for details like: For >>>> input string: "apa". >>> >>> >>> Should we remove this comparison? >> >> >> I don't understand. Why do remove? >> Would it better to check for the exception name instead? > > I've changed to check exception name (NumberFormatException) in > StartManagementAgent.java. > >> I will sponsor this fix and run these tests before the push. > > Thanks! > I'm waiting for second reviewer. > > > Yasumasa > > > 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com > : >> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>> >>> Hi Serguei, >>> >>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>> >>>> Hi Yasumasa, >>>> >>>> The changes looks good. >>>> Thank you for making them! >>> >>> >>> Thanks! >>> >>> >>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>> >>>>> Hi Serguei, >>>>> >>>>> Thank you for your comment! >>>>> I uploaded new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>> >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>> >>>>>> - if (!ex.getMessage().contains("Invalid >>>>>> com.sun.management.jmxremote.port number")) { >>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>> >>>>>> >>>>>> What is the motivation for this change? >>>>>> It seems, the original comparison is better. >>>>> >>>>> >>>>> "ex" is AttachOperationFailedException. >>>>> We can get the result as below when we run StartManagementAgent: >>>>> >>>>> ------------- >>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>> number: apa >>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>> java.lang.NumberFormatException: For input string: "apa" >>>>> [runApplication] at >>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>> ------------- >>>>> >>>>> I think we should check exception message in >>>>> AttachOperationFailedException. >>>>> In fact, jtreg fails at this point in my environment. >>>> >>>> >>>> >>>> I'd expect a check for some exception name, not for details like: For >>>> input string: "apa". >>> >>> >>> Should we remove this comparison? >> >> >> I don't understand. Why do remove? >> Would it better to check for the exception name instead? >> >> >>>>>> What tests did you run to make sure there are no regressions? >>>>> >>>>> >>>>> I've tested the following testcases: >>>>> >>>>> - hotspot/jtreg/serviceability/attach >>>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>>> - jdk/com/sun/tools/attach >>>> >>>> >>>> There are more tests related to dynamic attach in closed, >>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>> Will need to check. >>>> We have to make sure these tests are still passed. >>> >>> >>> I cannot access JPRT and closed testcases because I'm not an Oracle >>> employee. >>> Can you run them with this change? >> >> >> Ok. >> I will sponsor this fix and run these tests before the push. >> >> It seems, another update and one more review is needed. >> >> Thanks, >> Serguei >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> Some comments. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>> >>>>>> - if (!ex.getMessage().contains("Invalid >>>>>> com.sun.management.jmxremote.port number")) { >>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>> >>>>>> >>>>>> What is the motivation for this change? >>>>>> It seems, the original comparison is better. >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>> >>>>>> 37 public void run(CommandExecutor executor) { >>>>>> 38 try{ >>>>>> >>>>>> A space is missed after 'try'. >>>>>> >>>>>> >>>>>> It is odd that all test java classes define exactly the same >>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>> Would it better to defin a common base class with these methods? >>>>>> >>>>>> >>>>>> Otherwise, it looks good. >>>>>> Thank you for taking care about it! >>>>>> >>>>>> What tests did you run to make sure there are no regressions? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>> in >>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>> from target VM. >>>>>>>> >>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>> understand the cause of failure. >>>>>>>> >>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>> testcases: >>>>>>>> >>>>>>>> - hotspot/jtreg/serviceability/attach >>>>>>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>> - jdk/com/sun/tools/attach >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> (I cannot test it on other platforms.) >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>> >>>> >> From yasuenag at gmail.com Tue Nov 14 00:58:17 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 14 Nov 2017 09:58:17 +0900 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects Message-ID: PING: Could you review it? We need a reviewer and sponsor. >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ Thanks, Yasumasa 2017-11-09 23:34 GMT+09:00 Yasumasa Suenaga : > Thanks, Jini! > > I'm waiting for Reviewer and sponsor. > > > Yasumasa > > > > On 2017/11/09 23:25, Jini George wrote: >> >> Hi Yasumasa, >> >> This looks fine to me. >> >> Thank you, >> Jini (Not a Reviewer). >> >> On 11/9/2017 6:55 PM, Yasumasa Suenaga wrote: >>> >>> Hi Jini, >>> >>> Thank you for your comment! >>> I've fixed and uploaded new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ >>> >>>> * >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>>> >>>> -> Lines 198-212: I feel this commented out code could be removed and >>>> replaced by a call to printLockInfo(), though I am not entirely sure as >>>> to when this printOn() gets exercised. >>> >>> >>> I agree with you to remove these comments. >>> They are insufficient to show all locks like a my first webrev [1]. >>> webrev.04 is implemented to follow HotSpot implementation. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ >>> >>> >>> >>> On 2017/11/09 2:19, Jini George wrote: >>>> >>>> Hi Yasumasa, >>>> >>>> Your changes look good to me overall. Some nits: >>>> >>>> * >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java >>>> (lines 138 to 152): >>>> -> It would be nice if you could indent the "case" statements. >>>> >>>> * >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java >>>> -> It would be good if the indentation here for the newly added lines >>>> matches that of the rest of the file. (4 spaces instead of 2). >>>> >>>> * >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>>> >>>> -> Lines 198-212: I feel this commented out code could be removed and >>>> replaced by a call to printLockInfo(), though I am not entirely sure as >>>> to when this printOn() gets exercised. >>>> >>>> * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java >>>> -> You can remove these lines: >>>> import java.util.Scanner; >>>> import java.util.stream.Collectors; >>>> import java.io.File; >>>> >>>> Thanks, >>>> Jini (Not a Reviewer). >>>> >>>> >>>> On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: >>>>> >>>>> PING: Could you review and sponsor it? >>>>> >>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/10/09 23:19, Yasumasa Suenaga wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I uploaded new webrev to be adapted to current jdk10/hs: >>>>>> >>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>>>> >>>>>> >>>>>> Please review and sponsor it. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I uploaded new webrev to be adapted to jdk10/hs: >>>>>>> >>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> Thanks Jini! >>>>>>>> >>>>>>>> I uploaded new webrev: >>>>>>>> >>>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>>>>>> >>>>>>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>>>>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>>>>>> `jhsdb clhsdb`. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/08/24 18:01, Jini George wrote: >>>>>>>>> >>>>>>>>> Apologize for the late reply, Yasumasa. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I think so, but I guess it is difficult. >>>>>>>>>> For example, test for CLHSDB command is provided as >>>>>>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>>>>>> But target process seems to be fixed to "LingeredApp". >>>>>>>>>> Can we change it to another program which generates lock >>>>>>>>>> contention? >>>>>>>>> >>>>>>>>> >>>>>>>>> You can take a look at any of the >>>>>>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>>>>>> this. The target process does not have to be be fixed to >>>>>>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>>>>>> test-specific variations built on top of LingeredApp for ease of >>>>>>>>> implementation. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jini. From sharath.ballal at oracle.com Tue Nov 14 05:01:16 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 13 Nov 2017 21:01:16 -0800 (PST) Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Message-ID: Hello, Pls review the code changes and testcase for the following issue. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 Webrev: http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Tue Nov 14 05:32:24 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 13 Nov 2017 21:32:24 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> Message-ID: My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. Here is the latest webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Tuesday, November 07, 2017 12:09 PM To: David Holmes; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands I have made changes to use the outputAnalyzer (thanks Jini). Latest webrev is : http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ Thanks, Sharath -----Original Message----- From: Sharath Ballal Sent: Sunday, November 05, 2017 10:04 PM To: David Holmes; serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Thanks David for the comments. Reply inline. The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Monday, October 30, 2017 11:15 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Hi Sharath, I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. I have a few comments. On 30/10/2017 2:29 PM, Sharath Ballal wrote: > Hello, > > This webrev has changes for a framework for running the 'jhsdb clhsdb' > commands and verifying the output.? It also has sanity tests for 8 of I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... hsdb> hsdb> hsdb> flags .... ...... ZombieALotInterval = 5 0 hashCode = 5 0 hsdb> hsdb> My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); toolProcess.waitFor(); output = outputAnalyzer.getOutput(); Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? [Sharath Ballal] Launcher can do it. I have made the changes. Can the launcher internalize the management of the LingeredApp? [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. Can the launcher also handle the shouldSAAttach check? [Sharath Ballal] Yes. I have made that change. I can imagine the test logic reducing to a very simple: println(Starting test of ... List cmds = List.of( ...); List expected = List.of(...); List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. [Sharath Ballal] I have done this change. I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. [Sharath Ballal] OK. I have done these changes. It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. or the difference in expected output between: 57 "longConstant jtreg::test 6\n", 58 "longConstant jtreg::test\n", I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? [Sharath Ballal] Yes. I have provided a way to specify the expected/unexpected output per command and check it separately. Thanks, David > the clhsdb commands. > > Pls review the changes. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 > > Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ > > Thanks, > > Sharath > From jini.george at oracle.com Tue Nov 14 08:48:42 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 14 Nov 2017 14:18:42 +0530 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> Message-ID: <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> Thank you very much, David. Here is the revised webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ Have reduced the exitValue checking fragment and included p.destroyForcibly(). Also placed the creation of OutputAnalyzer before waiting for the jhsdb process exit, to avoid jhsdb hangs due to the output stream buffer not being consumed. (Thanks, Sharath!) Thanks, Jini. On 11/6/2017 12:58 PM, David Holmes wrote: > Hi Jini, > > On 3/11/2017 8:51 PM, Jini George wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >> >> I have made changes to validate the test results of each command >> separately, done away with the asserts and have added some more comments. > > This looks much better to me - thanks. This fragment: > > ????????? int exitValue = p.exitValue(); > ????????? OutputAnalyzer output = new OutputAnalyzer(p); > ????????? System.out.println(output.getOutput()); > > ????????? if (exitValue != 0) { > ????????????? throw new Error("clhsdb wasn't run successfully."); > ????????? } > > can be reduced to: > > OutputAnalyzer output = new OutputAnalyzer(p); > output.shouldHaveExitValue(0); > > There's probably no need to print getOutput() as if anything goes wrong > it will be printed by OutputAnalyzer anyway. But that's your choice. > > It may also be advisable to ensure the process is destroyed if you get > an exception here: > > ???????? try { > ???????????? p.waitFor(); > ???????? } catch (InterruptedException ie) { > +??????????? p.destroyForcibly(); > ???????????? throw new Error("Problem awaiting the child process: " + > ie, ie); > ???????? } > > similar to how ProcessTools.executeProcess manages things. > > Thanks, > David > ----- > >> Thank you, >> Jini. >> >> On 10/31/2017 12:32 PM, Jini George wrote: >>> Thank you for the quick review, David. My comments inline: >>> >>> On 10/30/2017 11:18 AM, David Holmes wrote: >>> >>>>> Plus this assumes G1 is being used but Lingered App is started >>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>> were passed through, wouldn't it? >>>> >>>> Okay the above are just examples of "int constants" that will be >>>> printed when you dump all the "int constants". The G1 constant >>>> doesn't indicate (I presume) that G1 is the active GC. >>> >>> Yes, the int constants contain compile time values and there are >>> entries for all the GC types. >>> >>>> As I said to Sharath it would be good to validate the results of >>>> each command separately rather than collectively. >>> >>> Will do. >>> >>> Thanks! >>> - Jini. >>> >>> >>> >>>> Thanks, >>>> David >>>> >>>>> --- >>>>> >>>>> TestType.java >>>>> >>>>> The expected output is not quite so strange, but still could do >>>>> with some commentary. >>>>> >>>>> ?? 90???????? Asserts.assertTrue(output.contains("type >>>>> G1CollectedHeap CollectedHeap")); >>>>> >>>>> Same comment about assuming G1. >>>>> >>>>> Thanks, >>>>> David >>>>> ------ >>>>> >>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>> Hello, >>>>>> >>>>>> We have been working on writing sanity tests for the various jhsdb >>>>>> clhsdb commands of the SA to improve the robustness of the SA. As >>>>>> a part of this, here is a webrev for sanity tests for 3 of the >>>>>> clhsdb commands: >>>>>> >>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>> >>>>>> I would like to request for reviews for this simple addition. >>>>>> >>>>>> Thank you, >>>>>> Jini. From jini.george at oracle.com Tue Nov 14 09:44:22 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 14 Nov 2017 15:14:22 +0530 Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> Message-ID: Hi Sharath, Your changes look fine to me. One nit: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.html * You should be able to remove the following line: 26 import java.util.HashMap; Thanks, Jini (Not a (R)eviewer). On 11/14/2017 11:02 AM, Sharath Ballal wrote: > My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). > > " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." > > Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. > > Here is the latest webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Tuesday, November 07, 2017 12:09 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > I have made changes to use the outputAnalyzer (thanks Jini). > Latest webrev is : http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Sunday, November 05, 2017 10:04 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Thanks David for the comments. Reply inline. > The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, October 30, 2017 11:15 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. > > I have a few comments. > > On 30/10/2017 2:29 PM, Sharath Ballal wrote: >> Hello, >> >> This webrev has changes for a framework for running the 'jhsdb clhsdb' >> commands and verifying the output.? It also has sanity tests for 8 of > > I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? > [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: > => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... > hsdb> > hsdb> > hsdb> flags > .... > ...... > ZombieALotInterval = 5 0 > hashCode = 5 0 > hsdb> > hsdb> > > My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. > OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); > toolProcess.waitFor(); > output = outputAnalyzer.getOutput(); > > Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? > [Sharath Ballal] Launcher can do it. I have made the changes. > > Can the launcher internalize the management of the LingeredApp? > [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. > Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. > > Can the launcher also handle the shouldSAAttach check? > [Sharath Ballal] Yes. I have made that change. > > I can imagine the test logic reducing to a very simple: > > println(Starting test of ... > List cmds = List.of( ...); > List expected = List.of(...); > List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); > > I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. > [Sharath Ballal] I have done this change. > > I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. > [Sharath Ballal] OK. I have done these changes. > > It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. > > or the difference in expected output > between: > > 57 "longConstant jtreg::test 6\n", > 58 "longConstant jtreg::test\n", > > I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? > [Sharath Ballal] Yes. > I have provided a way to specify the expected/unexpected output per command and check it separately. > > Thanks, > David > >> the clhsdb commands. >> >> Pls review the changes. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Tue Nov 14 09:51:59 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 14 Nov 2017 01:51:59 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> Message-ID: Thanks Jini. I have made the change. Thanks, Sharath -----Original Message----- From: Jini George Sent: Tuesday, November 14, 2017 3:14 PM To: Sharath Ballal; David Holmes; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Hi Sharath, Your changes look fine to me. One nit: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.html * You should be able to remove the following line: 26 import java.util.HashMap; Thanks, Jini (Not a (R)eviewer). On 11/14/2017 11:02 AM, Sharath Ballal wrote: > My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). > > " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." > > Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. > > Here is the latest webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Tuesday, November 07, 2017 12:09 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > I have made changes to use the outputAnalyzer (thanks Jini). > Latest webrev is : http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Sunday, November 05, 2017 10:04 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Thanks David for the comments. Reply inline. > The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, October 30, 2017 11:15 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. > > I have a few comments. > > On 30/10/2017 2:29 PM, Sharath Ballal wrote: >> Hello, >> >> This webrev has changes for a framework for running the 'jhsdb clhsdb' >> commands and verifying the output.? It also has sanity tests for 8 of > > I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? > [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: > => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... > hsdb> > hsdb> > hsdb> flags > .... > ...... > ZombieALotInterval = 5 0 > hashCode = 5 0 > hsdb> > hsdb> > > My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. > OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); > toolProcess.waitFor(); > output = outputAnalyzer.getOutput(); > > Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? > [Sharath Ballal] Launcher can do it. I have made the changes. > > Can the launcher internalize the management of the LingeredApp? > [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. > Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. > > Can the launcher also handle the shouldSAAttach check? > [Sharath Ballal] Yes. I have made that change. > > I can imagine the test logic reducing to a very simple: > > println(Starting test of ... > List cmds = List.of( ...); > List expected = List.of(...); > List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); > > I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. > [Sharath Ballal] I have done this change. > > I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. > [Sharath Ballal] OK. I have done these changes. > > It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. > > or the difference in expected output > between: > > 57 "longConstant jtreg::test 6\n", > 58 "longConstant jtreg::test\n", > > I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? > [Sharath Ballal] Yes. > I have provided a way to specify the expected/unexpected output per command and check it separately. > > Thanks, > David > >> the clhsdb commands. >> >> Pls review the changes. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Tue Nov 14 16:31:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 14 Nov 2017 08:31:14 -0800 (PST) Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> Message-ID: <652fe395-467e-4eb7-86af-1fef5f7069fe@default> Hi Jini, Code looks good. Some nits. TestUniverse.java: These lines can be removed 26 import java.io.File; 33 import jdk.test.lib.process.ProcessTools; 84 int exitValue = p.exitValue(); TestType.java: These lines can be removed 32 import jdk.test.lib.process.ProcessTools; 86 int exitValue = p.exitValue(); You may want to add few more strings in the defaultOutputStrings. TestIntConstant.java These lines can be removed 32 import jdk.test.lib.process.ProcessTools; 89 int exitValue = p.exitValue(); You may want to add few more strings in the defaultOutputStrings. Thanks, Sharath (not a reviewer) -----Original Message----- From: Jini George Sent: Tuesday, November 14, 2017 2:19 PM To: David Holmes; serviceability-dev at openjdk.java.net Subject: Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type Thank you very much, David. Here is the revised webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ Have reduced the exitValue checking fragment and included p.destroyForcibly(). Also placed the creation of OutputAnalyzer before waiting for the jhsdb process exit, to avoid jhsdb hangs due to the output stream buffer not being consumed. (Thanks, Sharath!) Thanks, Jini. On 11/6/2017 12:58 PM, David Holmes wrote: > Hi Jini, > > On 3/11/2017 8:51 PM, Jini George wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >> >> I have made changes to validate the test results of each command >> separately, done away with the asserts and have added some more comments. > > This looks much better to me - thanks. This fragment: > > ????????? int exitValue = p.exitValue(); > ????????? OutputAnalyzer output = new OutputAnalyzer(p); > ????????? System.out.println(output.getOutput()); > > ????????? if (exitValue != 0) { > ????????????? throw new Error("clhsdb wasn't run successfully."); > ????????? } > > can be reduced to: > > OutputAnalyzer output = new OutputAnalyzer(p); > output.shouldHaveExitValue(0); > > There's probably no need to print getOutput() as if anything goes > wrong it will be printed by OutputAnalyzer anyway. But that's your choice. > > It may also be advisable to ensure the process is destroyed if you get > an exception here: > > ???????? try { > ???????????? p.waitFor(); > ???????? } catch (InterruptedException ie) { > +??????????? p.destroyForcibly(); > ???????????? throw new Error("Problem awaiting the child process: " + > ie, ie); > ???????? } > > similar to how ProcessTools.executeProcess manages things. > > Thanks, > David > ----- > >> Thank you, >> Jini. >> >> On 10/31/2017 12:32 PM, Jini George wrote: >>> Thank you for the quick review, David. My comments inline: >>> >>> On 10/30/2017 11:18 AM, David Holmes wrote: >>> >>>>> Plus this assumes G1 is being used but Lingered App is started >>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>> were passed through, wouldn't it? >>>> >>>> Okay the above are just examples of "int constants" that will be >>>> printed when you dump all the "int constants". The G1 constant >>>> doesn't indicate (I presume) that G1 is the active GC. >>> >>> Yes, the int constants contain compile time values and there are >>> entries for all the GC types. >>> >>>> As I said to Sharath it would be good to validate the results of >>>> each command separately rather than collectively. >>> >>> Will do. >>> >>> Thanks! >>> - Jini. >>> >>> >>> >>>> Thanks, >>>> David >>>> >>>>> --- >>>>> >>>>> TestType.java >>>>> >>>>> The expected output is not quite so strange, but still could do >>>>> with some commentary. >>>>> >>>>> ?? 90???????? Asserts.assertTrue(output.contains("type >>>>> G1CollectedHeap CollectedHeap")); >>>>> >>>>> Same comment about assuming G1. >>>>> >>>>> Thanks, >>>>> David >>>>> ------ >>>>> >>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>> Hello, >>>>>> >>>>>> We have been working on writing sanity tests for the various >>>>>> jhsdb clhsdb commands of the SA to improve the robustness of the >>>>>> SA. As a part of this, here is a webrev for sanity tests for 3 of >>>>>> the clhsdb commands: >>>>>> >>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>> >>>>>> I would like to request for reviews for this simple addition. >>>>>> >>>>>> Thank you, >>>>>> Jini. From daniel.daugherty at oracle.com Tue Nov 14 21:48:42 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Nov 2017 16:48:42 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> Message-ID: <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> Greetings, I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. (Yes, we're playing chase-the-repo...) Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ Unlike the previous rebase, there were no changes required to the open code to get the rebased bits to build so there is no delta webrev. These bits have been run through JPRT and I've submitted the usual Mach5 tier[1-5] test run... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: > Greetings, > > I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. > > Here are the updated webrevs: > > Here's the mq comment for the change: > > ? Rebase to 2017.10.25 PIT snapshot. > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ > > And here is the delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ > > I ran the above bits throught Mach5 tier[1-5] testing over the holiday > weekend. Didn't see any issues in a quick look. Going to take a closer > look today. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Resolving one of the code review comments (from both Stefan K and >> Coleen) >> on jdk10-04-full required quite a few changes so it is being done as a >> standalone patch and corresponding webrevs: >> >> Here's the mq comment for the change: >> >> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >> ??? JavaThreadIteratorWithHandle. >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >> >> And here is the delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> We have a (eXtra Large) fix for the following bug: >>> >>> 8167108 inconsistent handling of SR_lock can lead to crashes >>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>> >>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>> Hazard Pointers to manage JavaThread lifecycle. >>> >>> Here's a PDF for the internal wiki that we've been using to describe >>> and track the work on this project: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>> >>> >>> Dan has noticed that the indenting is wrong in some of the code quotes >>> in the PDF that are not present in the internal wiki. We don't have a >>> solution for that problem yet. >>> >>> Here's the webrev for current JDK10 version of this fix: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>> >>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>> testing, additional stress testing on Dan's Solaris X64 server, and >>> additional testing on Erik and Robbin's machines. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Daniel Daugherty >>> Erik Osterlund >>> Robbin Ehn >>> >> >> > > From serguei.spitsyn at oracle.com Wed Nov 15 00:40:05 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Nov 2017 16:40:05 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> Message-ID: <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> Hi Yasumasa, It looks good to me. Thanks, Serguei On 11/7/17 22:38, Yasumasa Suenaga wrote: > Hi Serguei, > > I uploaded new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ > >>>> I'd expect a check for some exception name, not for details like: For >>>> input string: "apa". >>> >>> Should we remove this comparison? >> >> I don't understand. Why do remove? >> Would it better to check for the exception name instead? > I've changed to check exception name (NumberFormatException) in > StartManagementAgent.java. > >> I will sponsor this fix and run these tests before the push. > Thanks! > I'm waiting for second reviewer. > > > Yasumasa > > > 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com > : >> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> The changes looks good. >>>> Thank you for making them! >>> >>> Thanks! >>> >>> >>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> Thank you for your comment! >>>>> I uploaded new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>> >>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>> >>>>>> - if (!ex.getMessage().contains("Invalid >>>>>> com.sun.management.jmxremote.port number")) { >>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>> >>>>>> >>>>>> What is the motivation for this change? >>>>>> It seems, the original comparison is better. >>>>> >>>>> "ex" is AttachOperationFailedException. >>>>> We can get the result as below when we run StartManagementAgent: >>>>> >>>>> ------------- >>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>> number: apa >>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>> java.lang.NumberFormatException: For input string: "apa" >>>>> [runApplication] at >>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>> ------------- >>>>> >>>>> I think we should check exception message in >>>>> AttachOperationFailedException. >>>>> In fact, jtreg fails at this point in my environment. >>>> >>>> >>>> I'd expect a check for some exception name, not for details like: For >>>> input string: "apa". >>> >>> Should we remove this comparison? >> >> I don't understand. Why do remove? >> Would it better to check for the exception name instead? >> >> >>>>>> What tests did you run to make sure there are no regressions? >>>>> >>>>> I've tested the following testcases: >>>>> >>>>> - hotspot/jtreg/serviceability/attach >>>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>>> - jdk/com/sun/tools/attach >>>> >>>> There are more tests related to dynamic attach in closed, >>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>> Will need to check. >>>> We have to make sure these tests are still passed. >>> >>> I cannot access JPRT and closed testcases because I'm not an Oracle >>> employee. >>> Can you run them with this change? >> >> Ok. >> I will sponsor this fix and run these tests before the push. >> >> It seems, another update and one more review is needed. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> Serguei >>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Some comments. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>> >>>>>> - if (!ex.getMessage().contains("Invalid >>>>>> com.sun.management.jmxremote.port number")) { >>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>> >>>>>> >>>>>> What is the motivation for this change? >>>>>> It seems, the original comparison is better. >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>> >>>>>> 37 public void run(CommandExecutor executor) { >>>>>> 38 try{ >>>>>> >>>>>> A space is missed after 'try'. >>>>>> >>>>>> >>>>>> It is odd that all test java classes define exactly the same >>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>> Would it better to defin a common base class with these methods? >>>>>> >>>>>> >>>>>> Otherwise, it looks good. >>>>>> Thank you for taking care about it! >>>>>> >>>>>> What tests did you run to make sure there are no regressions? >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>> PING: Could you review and sponsor it? >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>> in >>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>> from target VM. >>>>>>>> >>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>> understand the cause of failure. >>>>>>>> >>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>> testcases: >>>>>>>> >>>>>>>> - hotspot/jtreg/serviceability/attach >>>>>>>> - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>> - jdk/com/sun/tools/attach >>>>>>>> >>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>> (I cannot test it on other platforms.) >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> From david.holmes at oracle.com Wed Nov 15 01:30:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 11:30:43 +1000 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <652fe395-467e-4eb7-86af-1fef5f7069fe@default> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> <652fe395-467e-4eb7-86af-1fef5f7069fe@default> Message-ID: <8feda117-fc7a-b0c6-f614-b0c77574b1bb@oracle.com> Hi Jini, In addition to Sharath's comments please add @bug and @summary items to each test header. Thanks, David ----- On 15/11/2017 2:31 AM, Sharath Ballal wrote: > Hi Jini, > > Code looks good. Some nits. > > TestUniverse.java: > > These lines can be removed > 26 import java.io.File; > 33 import jdk.test.lib.process.ProcessTools; > 84 int exitValue = p.exitValue(); > > TestType.java: > > These lines can be removed > 32 import jdk.test.lib.process.ProcessTools; > 86 int exitValue = p.exitValue(); > > You may want to add few more strings in the defaultOutputStrings. > > TestIntConstant.java > > These lines can be removed > 32 import jdk.test.lib.process.ProcessTools; > 89 int exitValue = p.exitValue(); > > You may want to add few more strings in the defaultOutputStrings. > > Thanks, > Sharath (not a reviewer) > > > -----Original Message----- > From: Jini George > Sent: Tuesday, November 14, 2017 2:19 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: Re: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type > > Thank you very much, David. Here is the revised webrev: > > http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ > > Have reduced the exitValue checking fragment and included p.destroyForcibly(). Also placed the creation of OutputAnalyzer before waiting for the jhsdb process exit, to avoid jhsdb hangs due to the output stream buffer not being consumed. (Thanks, Sharath!) > > Thanks, > Jini. > > On 11/6/2017 12:58 PM, David Holmes wrote: >> Hi Jini, >> >> On 3/11/2017 8:51 PM, Jini George wrote: >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >>> >>> I have made changes to validate the test results of each command >>> separately, done away with the asserts and have added some more comments. >> >> This looks much better to me - thanks. This fragment: >> >> ????????? int exitValue = p.exitValue(); >> ????????? OutputAnalyzer output = new OutputAnalyzer(p); >> ????????? System.out.println(output.getOutput()); >> >> ????????? if (exitValue != 0) { >> ????????????? throw new Error("clhsdb wasn't run successfully."); >> ????????? } >> >> can be reduced to: >> >> OutputAnalyzer output = new OutputAnalyzer(p); >> output.shouldHaveExitValue(0); >> >> There's probably no need to print getOutput() as if anything goes >> wrong it will be printed by OutputAnalyzer anyway. But that's your choice. >> >> It may also be advisable to ensure the process is destroyed if you get >> an exception here: >> >> ???????? try { >> ???????????? p.waitFor(); >> ???????? } catch (InterruptedException ie) { >> +??????????? p.destroyForcibly(); >> ???????????? throw new Error("Problem awaiting the child process: " + >> ie, ie); >> ???????? } >> >> similar to how ProcessTools.executeProcess manages things. >> >> Thanks, >> David >> ----- >> >>> Thank you, >>> Jini. >>> >>> On 10/31/2017 12:32 PM, Jini George wrote: >>>> Thank you for the quick review, David. My comments inline: >>>> >>>> On 10/30/2017 11:18 AM, David Holmes wrote: >>>> >>>>>> Plus this assumes G1 is being used but Lingered App is started >>>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>>> were passed through, wouldn't it? >>>>> >>>>> Okay the above are just examples of "int constants" that will be >>>>> printed when you dump all the "int constants". The G1 constant >>>>> doesn't indicate (I presume) that G1 is the active GC. >>>> >>>> Yes, the int constants contain compile time values and there are >>>> entries for all the GC types. >>>> >>>>> As I said to Sharath it would be good to validate the results of >>>>> each command separately rather than collectively. >>>> >>>> Will do. >>>> >>>> Thanks! >>>> - Jini. >>>> >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> --- >>>>>> >>>>>> TestType.java >>>>>> >>>>>> The expected output is not quite so strange, but still could do >>>>>> with some commentary. >>>>>> >>>>>> ?? 90???????? Asserts.assertTrue(output.contains("type >>>>>> G1CollectedHeap CollectedHeap")); >>>>>> >>>>>> Same comment about assuming G1. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ------ >>>>>> >>>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>>> Hello, >>>>>>> >>>>>>> We have been working on writing sanity tests for the various >>>>>>> jhsdb clhsdb commands of the SA to improve the robustness of the >>>>>>> SA. As a part of this, here is a webrev for sanity tests for 3 of >>>>>>> the clhsdb commands: >>>>>>> >>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>>> >>>>>>> I would like to request for reviews for this simple addition. >>>>>>> >>>>>>> Thank you, >>>>>>> Jini. From david.holmes at oracle.com Wed Nov 15 01:55:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 11:55:51 +1000 Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> Message-ID: <1af98ba5-6296-b728-616f-a1af93009972@oracle.com> Hi Sharath, This is looking very good. A few comments below. On 14/11/2017 3:32 PM, Sharath Ballal wrote: > My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). > > " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." > > Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. > > Here is the latest webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ General comments: Please add @bug to each test header. I would not expect you to need this in each test? * @modules java.base Style nit: you're using an unusual indentation for code like: 57 List cmds = List.of( 58 "flags", "flags -nd", 59 "flags UseJVMCICompiler", "flags MaxFDLimit", 60 "flags MaxJavaStackTraceDepth"); and 63 expStrMap.put("flags", List.of( 64 "UseJVMCICompiler = true", 65 "MaxFDLimit = false", but it's readable so I won't insist on any changes. --- test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java The @param names don't match the actual args on run/runCmd. 78 private String runCmd(List commands, 79 Map> expectedStrMap, 80 Map> unExpectedStrMap) Indent is wrong on 79 and 80: Map should line up with List on 78. 144 public String run(long lingeredAppPid, List commands, 145 Map> expectedStrMap, 146 Map> UnExpectedStrMap) Indent is wrong. --- test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java You should use @requires to exclude execution on OS X rather than a Platform check in the test. Thanks, David > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Tuesday, November 07, 2017 12:09 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > I have made changes to use the outputAnalyzer (thanks Jini). > Latest webrev is : http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Sunday, November 05, 2017 10:04 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Thanks David for the comments. Reply inline. > The new webrev is at http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, October 30, 2017 11:15 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. > > I have a few comments. > > On 30/10/2017 2:29 PM, Sharath Ballal wrote: >> Hello, >> >> This webrev has changes for a framework for running the 'jhsdb clhsdb' >> commands and verifying the output.? It also has sanity tests for 8 of > > I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? > [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: > => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... > hsdb> > hsdb> > hsdb> flags > .... > ...... > ZombieALotInterval = 5 0 > hashCode = 5 0 > hsdb> > hsdb> > > My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. > OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); > toolProcess.waitFor(); > output = outputAnalyzer.getOutput(); > > Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? > [Sharath Ballal] Launcher can do it. I have made the changes. > > Can the launcher internalize the management of the LingeredApp? > [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. > Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. > > Can the launcher also handle the shouldSAAttach check? > [Sharath Ballal] Yes. I have made that change. > > I can imagine the test logic reducing to a very simple: > > println(Starting test of ... > List cmds = List.of( ...); > List expected = List.of(...); > List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // static method println("test PASSED"); > > I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. > [Sharath Ballal] I have done this change. > > I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. > [Sharath Ballal] OK. I have done these changes. > > It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. > > or the difference in expected output > between: > > 57 "longConstant jtreg::test 6\n", > 58 "longConstant jtreg::test\n", > > I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? > [Sharath Ballal] Yes. > I have provided a way to specify the expected/unexpected output per command and check it separately. > > Thanks, > David > >> the clhsdb commands. >> >> Pls review the changes. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >> >> Thanks, >> >> Sharath >> From jini.george at oracle.com Wed Nov 15 05:27:58 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 15 Nov 2017 10:57:58 +0530 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: <8feda117-fc7a-b0c6-f614-b0c77574b1bb@oracle.com> References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> <652fe395-467e-4eb7-86af-1fef5f7069fe@default> <8feda117-fc7a-b0c6-f614-b0c77574b1bb@oracle.com> Message-ID: Thank you, Sharath and David. The revised webrev after addressing the comments are at: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.03/ Thanks, Jini. On 11/15/2017 7:00 AM, David Holmes wrote: > Hi Jini, > > In addition to Sharath's comments please add @bug and @summary items to > each test header. > > Thanks, > David > ----- > > On 15/11/2017 2:31 AM, Sharath Ballal wrote: >> Hi Jini, >> >> Code looks good.? Some nits. >> >> TestUniverse.java: >> >> These lines can be removed >> ??? 26 import java.io.File; >> ??? 33 import jdk.test.lib.process.ProcessTools; >> ??? 84???????? int exitValue = p.exitValue(); >> >> TestType.java: >> >> These lines can be removed >> ??? 32 import jdk.test.lib.process.ProcessTools; >> ??? 86???????? int exitValue = p.exitValue(); >> >> You may want to add few more strings in the defaultOutputStrings. >> >> TestIntConstant.java >> >> These lines can be removed >> ??? 32 import jdk.test.lib.process.ProcessTools; >> ??? 89???????? int exitValue = p.exitValue(); >> >> You may want to add few more strings in the defaultOutputStrings. >> >> Thanks, >> Sharath (not a reviewer) >> >> >> -----Original Message----- >> From: Jini George >> Sent: Tuesday, November 14, 2017 2:19 PM >> To: David Holmes; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: (small): JDK-8190307: SA: Sanity tests for the >> clhsdb commands: universe, intconstant, type >> >> Thank you very much, David. Here is the revised webrev: >> >> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ >> >> Have reduced the exitValue checking fragment and included >> p.destroyForcibly(). Also placed the creation of OutputAnalyzer before >> waiting for the jhsdb process exit, to avoid jhsdb hangs due to the >> output stream buffer not being consumed. (Thanks, Sharath!) >> >> Thanks, >> Jini. >> >> On 11/6/2017 12:58 PM, David Holmes wrote: >>> Hi Jini, >>> >>> On 3/11/2017 8:51 PM, Jini George wrote: >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >>>> >>>> I have made changes to validate the test results of each command >>>> separately, done away with the asserts and have added some more >>>> comments. >>> >>> This looks much better to me - thanks. This fragment: >>> >>> ? ????????? int exitValue = p.exitValue(); >>> ? ????????? OutputAnalyzer output = new OutputAnalyzer(p); >>> ? ????????? System.out.println(output.getOutput()); >>> >>> ? ????????? if (exitValue != 0) { >>> ? ????????????? throw new Error("clhsdb wasn't run successfully."); >>> ? ????????? } >>> >>> can be reduced to: >>> >>> OutputAnalyzer output = new OutputAnalyzer(p); >>> output.shouldHaveExitValue(0); >>> >>> There's probably no need to print getOutput() as if anything goes >>> wrong it will be printed by OutputAnalyzer anyway. But that's your >>> choice. >>> >>> It may also be advisable to ensure the process is destroyed if you get >>> an exception here: >>> >>> ? ???????? try { >>> ? ???????????? p.waitFor(); >>> ? ???????? } catch (InterruptedException ie) { >>> +??????????? p.destroyForcibly(); >>> ? ???????????? throw new Error("Problem awaiting the child process: " + >>> ie, ie); >>> ? ???????? } >>> >>> similar to how ProcessTools.executeProcess manages things. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thank you, >>>> Jini. >>>> >>>> On 10/31/2017 12:32 PM, Jini George wrote: >>>>> Thank you for the quick review, David. My comments inline: >>>>> >>>>> On 10/30/2017 11:18 AM, David Holmes wrote: >>>>> >>>>>>> Plus this assumes G1 is being used but Lingered App is started >>>>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>>>> were passed through, wouldn't it? >>>>>> >>>>>> Okay the above are just examples of "int constants" that will be >>>>>> printed when you dump all the "int constants". The G1 constant >>>>>> doesn't indicate (I presume) that G1 is the active GC. >>>>> >>>>> Yes, the int constants contain compile time values and there are >>>>> entries for all the GC types. >>>>> >>>>>> As I said to Sharath it would be good to validate the results of >>>>>> each command separately rather than collectively. >>>>> >>>>> Will do. >>>>> >>>>> Thanks! >>>>> - Jini. >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> --- >>>>>>> >>>>>>> TestType.java >>>>>>> >>>>>>> The expected output is not quite so strange, but still could do >>>>>>> with some commentary. >>>>>>> >>>>>>> ??? 90???????? Asserts.assertTrue(output.contains("type >>>>>>> G1CollectedHeap CollectedHeap")); >>>>>>> >>>>>>> Same comment about assuming G1. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ------ >>>>>>> >>>>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> We have been working on writing sanity tests for the various >>>>>>>> jhsdb clhsdb commands of the SA to improve the robustness of the >>>>>>>> SA. As a part of this, here is a webrev for sanity tests for 3 of >>>>>>>> the clhsdb commands: >>>>>>>> >>>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>>>> >>>>>>>> I would like to request for reviews for this simple addition. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Jini. From serguei.spitsyn at oracle.com Wed Nov 15 07:38:42 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Nov 2017 23:38:42 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> Message-ID: <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> Hi Yasumasa, Do the new tests pass in your runs? In my runs 3 of 4 tests are failed with the errors like this: ?109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' ?110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' ?111 Command returned with exit code 0 ?112 ---------------- stdout ---------------- ?113 21951: ?114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. ?115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory ?116 Good news is that the attach-related tests from closed repository are passed. Thanks, Serguei On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > It looks good to me. > > Thanks, > Serguei > > > On 11/7/17 22:38, Yasumasa Suenaga wrote: >> Hi Serguei, >> >> I uploaded new webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >> >>>>> I'd expect a check for some exception name, not for details like: For >>>>> input string: "apa". >>>> >>>> Should we remove this comparison? >>> >>> I don't understand. Why do remove? >>> Would it better to check for the exception name instead? >> I've changed to check exception name (NumberFormatException) in >> StartManagementAgent.java. >> >>> I will sponsor this fix and run these tests before the push. >> Thanks! >> I'm waiting for second reviewer. >> >> >> Yasumasa >> >> >> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >> : >>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> The changes looks good. >>>>> Thank you for making them! >>>> >>>> Thanks! >>>> >>>> >>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for your comment! >>>>>> I uploaded new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>> >>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>> >>>>>>> >>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>> >>>>>>> >>>>>>> ??? What is the motivation for this change? >>>>>>> ??? It seems, the original comparison is better. >>>>>> >>>>>> "ex" is AttachOperationFailedException. >>>>>> We can get the result as below when we run StartManagementAgent: >>>>>> >>>>>> ------------- >>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>> number: apa >>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>> [runApplication]??????? at >>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>> >>>>>> ------------- >>>>>> >>>>>> I think we should check exception message in >>>>>> AttachOperationFailedException. >>>>>> In fact, jtreg fails at this point in my environment. >>>>> >>>>> >>>>> I'd expect a check for some exception name, not for details like: For >>>>> input string: "apa". >>>> >>>> Should we remove this comparison? >>> >>> I don't understand. Why do remove? >>> Would it better to check for the exception name instead? >>> >>> >>>>>>> What tests did you run to make sure there are no regressions? >>>>>> >>>>>> I've tested the following testcases: >>>>>> >>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>> ?? - jdk/com/sun/tools/attach >>>>> >>>>> There are more tests related to dynamic attach in closed, >>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>> I'm not sure, if they are included into any of the Mach5 testing >>>>> levels. >>>>> Will need to check. >>>>> We have to make sure these tests are still passed. >>>> >>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>> employee. >>>> Can you run them with this change? >>> >>> Ok. >>> I will sponsor this fix and run these tests before the push. >>> >>> It seems, another update and one more review is needed. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Some comments. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>> >>>>>>> >>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>> >>>>>>> >>>>>>> ??? What is the motivation for this change? >>>>>>> ??? It seems, the original comparison is better. >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>> >>>>>>> >>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>> ??? 38???????? try{ >>>>>>> >>>>>>> ??? A space is missed after 'try'. >>>>>>> >>>>>>> >>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>> ??? Would it better to defin a common base class with these >>>>>>> methods? >>>>>>> >>>>>>> >>>>>>> Otherwise, it looks good. >>>>>>> Thank you for taking care about it! >>>>>>> >>>>>>> What tests did you run to make sure there are no regressions? >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>> PING: Could you review and sponsor it? >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load >>>>>>>>> dcmd, we >>>>>>>>> will get "Command executed successfully". However, it implies >>>>>>>>> error >>>>>>>>> in >>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>> This message is from JCmd.java when jcmd does not receive any >>>>>>>>> output >>>>>>>>> from target VM. >>>>>>>>> >>>>>>>>> I think HotSopt/jcmd should return useful error message to >>>>>>>>> users to >>>>>>>>> understand the cause of failure. >>>>>>>>> >>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>> testcases: >>>>>>>>> >>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>> >>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> > From sharath.ballal at oracle.com Wed Nov 15 09:58:57 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 15 Nov 2017 01:58:57 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: <1af98ba5-6296-b728-616f-a1af93009972@oracle.com> References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> <1af98ba5-6296-b728-616f-a1af93009972@oracle.com> Message-ID: Thanks David. Here is the revised webrev after addressing the comments: http://cr.openjdk.java.net/~sballal/8190198/webrev.04/ Thanks, Sharath -----Original Message----- From: David Holmes Sent: Wednesday, November 15, 2017 7:26 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands Hi Sharath, This is looking very good. A few comments below. On 14/11/2017 3:32 PM, Sharath Ballal wrote: > My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). > > " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." > > Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. > > Here is the latest webrev: > http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ General comments: Please add @bug to each test header. I would not expect you to need this in each test? * @modules java.base Style nit: you're using an unusual indentation for code like: 57 List cmds = List.of( 58 "flags", "flags -nd", 59 "flags UseJVMCICompiler", "flags MaxFDLimit", 60 "flags MaxJavaStackTraceDepth"); and 63 expStrMap.put("flags", List.of( 64 "UseJVMCICompiler = true", 65 "MaxFDLimit = false", but it's readable so I won't insist on any changes. --- test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java The @param names don't match the actual args on run/runCmd. 78 private String runCmd(List commands, 79 Map> expectedStrMap, 80 Map> unExpectedStrMap) Indent is wrong on 79 and 80: Map should line up with List on 78. 144 public String run(long lingeredAppPid, List commands, 145 Map> expectedStrMap, 146 Map> UnExpectedStrMap) Indent is wrong. --- test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java You should use @requires to exclude execution on OS X rather than a Platform check in the test. Thanks, David > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Tuesday, November 07, 2017 12:09 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb > clhsdb' commands tests and testcases for some of the commands > > I have made changes to use the outputAnalyzer (thanks Jini). > Latest webrev is : > http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ > > Thanks, > Sharath > > > -----Original Message----- > From: Sharath Ballal > Sent: Sunday, November 05, 2017 10:04 PM > To: David Holmes; serviceability-dev at openjdk.java.net > Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb > clhsdb' commands tests and testcases for some of the commands > > Thanks David for the comments. Reply inline. > The new webrev is at > http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ > > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Monday, October 30, 2017 11:15 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb > clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. > > I have a few comments. > > On 30/10/2017 2:29 PM, Sharath Ballal wrote: >> Hello, >> >> This webrev has changes for a framework for running the 'jhsdb clhsdb' >> commands and verifying the output.? It also has sanity tests for 8 of > > I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? > [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: > => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... > hsdb> > hsdb> > hsdb> flags > .... > ...... > ZombieALotInterval = 5 0 > hashCode = 5 0 > hsdb> > hsdb> > > My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. > OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); > toolProcess.waitFor(); > output = outputAnalyzer.getOutput(); > > Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? > [Sharath Ballal] Launcher can do it. I have made the changes. > > Can the launcher internalize the management of the LingeredApp? > [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. > Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. > > Can the launcher also handle the shouldSAAttach check? > [Sharath Ballal] Yes. I have made that change. > > I can imagine the test logic reducing to a very simple: > > println(Starting test of ... > List cmds = List.of( ...); > List expected = List.of(...); > List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, > expected, unexpected); // static method println("test PASSED"); > > I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. > [Sharath Ballal] I have done this change. > > I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. > [Sharath Ballal] OK. I have done these changes. > > It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. > > or the difference in expected output > between: > > 57 "longConstant jtreg::test 6\n", > 58 "longConstant jtreg::test\n", > > I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? > [Sharath Ballal] Yes. > I have provided a way to specify the expected/unexpected output per command and check it separately. > > Thanks, > David > >> the clhsdb commands. >> >> Pls review the changes. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >> >> Thanks, >> >> Sharath >> From yasuenag at gmail.com Wed Nov 15 12:15:28 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 15 Nov 2017 21:15:28 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> Message-ID: Hi Serguei, > Do the new tests pass in your runs? Of course. It seems not to exist jtreg native libraries. I've tested as below: $ make build-test-hotspot-jtreg-native $ cd test $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach > Good news is that the attach-related tests from closed repository are passed. Thanks! Yasumasa On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Do the new tests pass in your runs? > > In my runs 3 of 4 tests are failed with the errors like this: > > ?109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' > ?110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' > ?111 Command returned with exit code 0 > ?112 ---------------- stdout ---------------- > ?113 21951: > ?114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. > ?115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory > ?116 > > > Good news is that the attach-related tests from closed repository are passed. > > > Thanks, > Serguei > > > > On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> It looks good to me. >> >> Thanks, >> Serguei >> >> >> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>> I uploaded new webrev: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>> >>>>>> I'd expect a check for some exception name, not for details like: For >>>>>> input string: "apa". >>>>> >>>>> Should we remove this comparison? >>>> >>>> I don't understand. Why do remove? >>>> Would it better to check for the exception name instead? >>> I've changed to check exception name (NumberFormatException) in >>> StartManagementAgent.java. >>> >>>> I will sponsor this fix and run these tests before the push. >>> Thanks! >>> I'm waiting for second reviewer. >>> >>> >>> Yasumasa >>> >>> >>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>> : >>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> The changes looks good. >>>>>> Thank you for making them! >>>>> >>>>> Thanks! >>>>> >>>>> >>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Thank you for your comment! >>>>>>> I uploaded new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>> >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>> >>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>> >>>>>>>> >>>>>>>> ??? What is the motivation for this change? >>>>>>>> ??? It seems, the original comparison is better. >>>>>>> >>>>>>> "ex" is AttachOperationFailedException. >>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>> >>>>>>> ------------- >>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>> number: apa >>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>> [runApplication]??????? at >>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>> ------------- >>>>>>> >>>>>>> I think we should check exception message in >>>>>>> AttachOperationFailedException. >>>>>>> In fact, jtreg fails at this point in my environment. >>>>>> >>>>>> >>>>>> I'd expect a check for some exception name, not for details like: For >>>>>> input string: "apa". >>>>> >>>>> Should we remove this comparison? >>>> >>>> I don't understand. Why do remove? >>>> Would it better to check for the exception name instead? >>>> >>>> >>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>> >>>>>>> I've tested the following testcases: >>>>>>> >>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>> ?? - jdk/com/sun/tools/attach >>>>>> >>>>>> There are more tests related to dynamic attach in closed, >>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>>>> Will need to check. >>>>>> We have to make sure these tests are still passed. >>>>> >>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>> employee. >>>>> Can you run them with this change? >>>> >>>> Ok. >>>> I will sponsor this fix and run these tests before the push. >>>> >>>> It seems, another update and one more review is needed. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Some comments. >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>> >>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>> >>>>>>>> >>>>>>>> ??? What is the motivation for this change? >>>>>>>> ??? It seems, the original comparison is better. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>> >>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>> ??? 38???????? try{ >>>>>>>> >>>>>>>> ??? A space is missed after 'try'. >>>>>>>> >>>>>>>> >>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>> ??? Would it better to defin a common base class with these methods? >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, it looks good. >>>>>>>> Thank you for taking care about it! >>>>>>>> >>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>>>> in >>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>>>> from target VM. >>>>>>>>>> >>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>>>> understand the cause of failure. >>>>>>>>>> >>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>> testcases: >>>>>>>>>> >>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>> >>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >> > From david.holmes at oracle.com Wed Nov 15 12:56:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 22:56:35 +1000 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> Message-ID: <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: > Hi Serguei, > >> Do the new tests pass in your runs? > > Of course. > It seems not to exist jtreg native libraries. > I've tested as below: > > ? $ make build-test-hotspot-jtreg-native > ? $ cd test > ? $ $JT_HOME/bin/jtreg -ignore:quiet > -nativepath://support/test/hotspot/jtreg/native/lib > hotspot/jtreg/serviceability/attach > hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach Please check that: make test-image followed by jtreg -nativepath:/images/test/hotspot/jtreg/native also works. Thanks, David > >> Good news is that the attach-related tests from closed repository are >> passed. > > Thanks! > > > Yasumasa > > > On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> Do the new tests pass in your runs? >> >> In my runs 3 of 4 tests are failed with the errors like this: >> >> ??109 Running DCMD 'JVMTI.agent_load >> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >> through 'PidJcmdExecutor' >> ??110 Executing command >> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >> 21951, JVMTI.agent_load >> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >> >> ??111 Command returned with exit code 0 >> ??112 ---------------- stdout ---------------- >> ??113 21951: >> ??114 >> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >> was not loaded. >> ??115 >> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >> cannot open shared object file: No such file or directory >> ??116 >> >> >> Good news is that the attach-related tests from closed repository are >> passed. >> >> >> Thanks, >> Serguei >> >> >> >> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> It looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>> Hi Serguei, >>>> >>>> I uploaded new webrev: >>>> >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>> >>>>>>> I'd expect a check for some exception name, not for details like: >>>>>>> For >>>>>>> input string: "apa". >>>>>> >>>>>> Should we remove this comparison? >>>>> >>>>> I don't understand. Why do remove? >>>>> Would it better to check for the exception name instead? >>>> I've changed to check exception name (NumberFormatException) in >>>> StartManagementAgent.java. >>>> >>>>> I will sponsor this fix and run these tests before the push. >>>> Thanks! >>>> I'm waiting for second reviewer. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>> : >>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> The changes looks good. >>>>>>> Thank you for making them! >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> Thank you for your comment! >>>>>>>> I uploaded new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? What is the motivation for this change? >>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>> >>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>> >>>>>>>> ------------- >>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>> number: apa >>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>> [runApplication]??????? at >>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>> >>>>>>>> ------------- >>>>>>>> >>>>>>>> I think we should check exception message in >>>>>>>> AttachOperationFailedException. >>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>> >>>>>>> >>>>>>> I'd expect a check for some exception name, not for details like: >>>>>>> For >>>>>>> input string: "apa". >>>>>> >>>>>> Should we remove this comparison? >>>>> >>>>> I don't understand. Why do remove? >>>>> Would it better to check for the exception name instead? >>>>> >>>>> >>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>> >>>>>>>> I've tested the following testcases: >>>>>>>> >>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>> >>>>>>> There are more tests related to dynamic attach in closed, >>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>> I'm not sure, if they are included into any of the Mach5 testing >>>>>>> levels. >>>>>>> Will need to check. >>>>>>> We have to make sure these tests are still passed. >>>>>> >>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>> employee. >>>>>> Can you run them with this change? >>>>> >>>>> Ok. >>>>> I will sponsor this fix and run these tests before the push. >>>>> >>>>> It seems, another update and one more review is needed. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Some comments. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>> >>>>>>>>> >>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? What is the motivation for this change? >>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>> ??? 38???????? try{ >>>>>>>>> >>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>> >>>>>>>>> >>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>> ??? Would it better to defin a common base class with these >>>>>>>>> methods? >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise, it looks good. >>>>>>>>> Thank you for taking care about it! >>>>>>>>> >>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load >>>>>>>>>>> dcmd, we >>>>>>>>>>> will get "Command executed successfully". However, it implies >>>>>>>>>>> error >>>>>>>>>>> in >>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any >>>>>>>>>>> output >>>>>>>>>>> from target VM. >>>>>>>>>>> >>>>>>>>>>> I think HotSopt/jcmd should return useful error message to >>>>>>>>>>> users to >>>>>>>>>>> understand the cause of failure. >>>>>>>>>>> >>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>>> testcases: >>>>>>>>>>> >>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>> >>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> >> From ujwal.vangapally at oracle.com Wed Nov 15 13:09:02 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Wed, 15 Nov 2017 18:39:02 +0530 Subject: RFR : JDK-8191313 - deprecate RMIConnectorServer.CREDENTIAL_TYPES Message-ID: <90d2599b-adc9-2772-3f89-c8792fe9a636@oracle.com> kindly review the changes for bug below. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8191313 webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8191313/webrev.00/ CSR : https://bugs.openjdk.java.net/browse/JDK-8191314 Thanks, Ujwal. From ujwal.vangapally at oracle.com Wed Nov 15 13:18:46 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Wed, 15 Nov 2017 18:48:46 +0530 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: kindly review the updated webrev including changes to MBeanInfoHashCodeNPETest.java webrev : http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.05/ Thanks, Ujwal. On 11/9/2017 10:33 PM, Ujwal Vangapally wrote: > Thanks for the review Mandy, > > kindly check if this version is better. > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ > > Ujwal > > > On 11/9/2017 9:10 PM, mandy chung wrote: >> >> >> On 11/9/17 2:40 AM, Ujwal Vangapally wrote: >>> Thanks for the Review Daniel, made changes as suggested. >>> >>> webrev : >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ >>> >> >> Looks good. >> >> Minor comment: in the new test, it can fold some of the println >> together e.g. line 81 can be merged with line 39 to include the value >> being passed. Similarly for the println in the main method. >> >> Mandy >> > From daniel.fuchs at oracle.com Wed Nov 15 15:09:13 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Nov 2017 15:09:13 +0000 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: Hi Ujwal, Still looks good to me. best regards, -- daniel On 15/11/2017 13:18, Ujwal Vangapally wrote: > kindly review the updated webrev including changes to > MBeanInfoHashCodeNPETest.java > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.05/ > > Thanks, > > Ujwal. > > > On 11/9/2017 10:33 PM, Ujwal Vangapally wrote: >> Thanks for the review Mandy, >> >> kindly check if this version is better. >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ >> >> Ujwal >> >> >> On 11/9/2017 9:10 PM, mandy chung wrote: >>> >>> >>> On 11/9/17 2:40 AM, Ujwal Vangapally wrote: >>>> Thanks for the Review Daniel, made changes as suggested. >>>> >>>> webrev : >>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ >>>> >>> >>> Looks good. >>> >>> Minor comment: in the new test, it can fold some of the println >>> together e.g. line 81 can be merged with line 39 to include the value >>> being passed.? Similarly for the println in the main method. >>> >>> Mandy >>> >> > From Roger.Riggs at Oracle.com Wed Nov 15 15:11:55 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Nov 2017 10:11:55 -0500 Subject: RFR : JDK-8024352 - MBeanOperationInfo accepts any int value as "impact" In-Reply-To: References: <5fa0def9-db2c-9ace-5813-116e843b6c75@oracle.com> <11f7077d-1cac-01fd-29d1-31509af906ed@Oracle.com> <093b2b51-b202-3f83-9ded-ae51d85fe574@oracle.com> <80e4ba7f-2086-b2b9-4c5d-21788fccb46f@oracle.com> <60464b7c-8583-c282-8324-1500f15e1a9a@oracle.com> Message-ID: <71766075-126c-87c1-f137-8b434b269d21@Oracle.com> +1 On 11/15/2017 10:09 AM, Daniel Fuchs wrote: > Hi Ujwal, > > Still looks good to me. > > best regards, > > -- daniel > > On 15/11/2017 13:18, Ujwal Vangapally wrote: >> kindly review the updated webrev including changes to >> MBeanInfoHashCodeNPETest.java >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.05/ >> >> Thanks, >> >> Ujwal. >> >> >> On 11/9/2017 10:33 PM, Ujwal Vangapally wrote: >>> Thanks for the review Mandy, >>> >>> kindly check if this version is better. >>> >>> webrev : >>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.04/ >>> >>> Ujwal >>> >>> >>> On 11/9/2017 9:10 PM, mandy chung wrote: >>>> >>>> >>>> On 11/9/17 2:40 AM, Ujwal Vangapally wrote: >>>>> Thanks for the Review Daniel, made changes as suggested. >>>>> >>>>> webrev : >>>>> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8024352/webrev.03/ >>>>> >>>>> >>>> >>>> Looks good. >>>> >>>> Minor comment: in the new test, it can fold some of the println >>>> together e.g. line 81 can be merged with line 39 to include the >>>> value being passed.? Similarly for the println in the main method. >>>> >>>> Mandy >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Wed Nov 15 15:24:25 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Nov 2017 10:24:25 -0500 Subject: RFR : JDK-8191313 - deprecate RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <90d2599b-adc9-2772-3f89-c8792fe9a636@oracle.com> References: <90d2599b-adc9-2772-3f89-c8792fe9a636@oracle.com> Message-ID: <8e872821-5ac6-1958-d3b3-ff888d7ef15e@Oracle.com> Hi Ujwal, Looks fine. (There may be a bit of confusion because in the webrev it looks like the value is being added and deprecated. The field is present in JDK 9 and this is formalizing the intention to remove it after JDK 1). (I cleaned up the csr a bit to remove extraneous information in the changset). Thanks, Roger On 11/15/2017 8:09 AM, Ujwal Vangapally wrote: > kindly review the changes for bug below. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8191313 > > webrev : > http://cr.openjdk.java.net/~uvangapally/webrev/2017/8191313/webrev.00/ > > CSR : https://bugs.openjdk.java.net/browse/JDK-8191314 > > Thanks, > > Ujwal. > From ujwal.vangapally at oracle.com Wed Nov 15 16:02:10 2017 From: ujwal.vangapally at oracle.com (Ujwal Vangapally) Date: Wed, 15 Nov 2017 21:32:10 +0530 Subject: RFR : JDK-8191313 - deprecate RMIConnectorServer.CREDENTIAL_TYPES In-Reply-To: <8e872821-5ac6-1958-d3b3-ff888d7ef15e@Oracle.com> References: <90d2599b-adc9-2772-3f89-c8792fe9a636@oracle.com> <8e872821-5ac6-1958-d3b3-ff888d7ef15e@Oracle.com> Message-ID: Thanks for the review and edit's in CSR Roger :-) Ujwal. On 11/15/2017 8:54 PM, Roger Riggs wrote: > Hi Ujwal, > > Looks fine. > > (There may be a bit of confusion because in the webrev it looks like > the value is being added and deprecated. > The field is present in JDK 9 and this is formalizing the intention to > remove it after JDK 1). > > (I cleaned up the csr a bit to remove extraneous information in the > changset). > > Thanks, Roger > > > On 11/15/2017 8:09 AM, Ujwal Vangapally wrote: >> kindly review the changes for bug below. >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8191313 >> >> webrev : >> http://cr.openjdk.java.net/~uvangapally/webrev/2017/8191313/webrev.00/ >> >> CSR : https://bugs.openjdk.java.net/browse/JDK-8191314 >> >> Thanks, >> >> Ujwal. >> > From serguei.spitsyn at oracle.com Wed Nov 15 18:34:47 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Nov 2017 10:34:47 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> Message-ID: Hi Yasumasa and David, On 11/15/17 04:56, David Holmes wrote: > On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >> Hi Serguei, >> >>> Do the new tests pass in your runs? >> >> Of course. >> It seems not to exist jtreg native libraries. >> I've tested as below: >> >> ?? $ make build-test-hotspot-jtreg-native >> ?? $ cd test >> ?? $ $JT_HOME/bin/jtreg -ignore:quiet >> -nativepath://support/test/hotspot/jtreg/native/lib >> hotspot/jtreg/serviceability/attach >> hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach Thanks. I missed to add the -nativepath flag, sorry. > Please check that: > > make test-image > > followed by jtreg > -nativepath:/images/test/hotspot/jtreg/native > > also works. It fails with the error: ? 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' ? 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]' ? 65 Command returned with exit code 0 ? 66 ---------------- stdout ---------------- ? 67 28407: ? 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded. ? 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory ? 70 It seems, the '/lib' folder is added to the nativepath. Yasumasa, could you, double check it please? I'm using the jtreg: ? /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg which is: % ls -l /java/re/jtreg/4.2/promoted/latest lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ Thanks, Serguei > > Thanks, > David > >> >>> Good news is that the attach-related tests from closed repository >>> are passed. >> >> Thanks! >> >> >> Yasumasa >> >> >> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> Do the new tests pass in your runs? >>> >>> In my runs 3 of 4 tests are failed with the errors like this: >>> >>> ??109 Running DCMD 'JVMTI.agent_load >>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >>> through 'PidJcmdExecutor' >>> ??110 Executing command >>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>> 21951, JVMTI.agent_load >>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>> >>> ??111 Command returned with exit code 0 >>> ??112 ---------------- stdout ---------------- >>> ??113 21951: >>> ??114 >>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >>> was not loaded. >>> ??115 >>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >>> cannot open shared object file: No such file or directory >>> ??116 >>> >>> >>> Good news is that the attach-related tests from closed repository >>> are passed. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> It looks good to me. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>> I uploaded new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>> >>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>> like: For >>>>>>>> input string: "apa". >>>>>>> >>>>>>> Should we remove this comparison? >>>>>> >>>>>> I don't understand. Why do remove? >>>>>> Would it better to check for the exception name instead? >>>>> I've changed to check exception name (NumberFormatException) in >>>>> StartManagementAgent.java. >>>>> >>>>>> I will sponsor this fix and run these tests before the push. >>>>> Thanks! >>>>> I'm waiting for second reviewer. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>> : >>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> The changes looks good. >>>>>>>> Thank you for making them! >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> Thank you for your comment! >>>>>>>>> I uploaded new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>> >>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>> >>>>>>>>> ------------- >>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>> number: apa >>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>> [runApplication]??????? at >>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>> >>>>>>>>> ------------- >>>>>>>>> >>>>>>>>> I think we should check exception message in >>>>>>>>> AttachOperationFailedException. >>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>> >>>>>>>> >>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>> like: For >>>>>>>> input string: "apa". >>>>>>> >>>>>>> Should we remove this comparison? >>>>>> >>>>>> I don't understand. Why do remove? >>>>>> Would it better to check for the exception name instead? >>>>>> >>>>>> >>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>> >>>>>>>>> I've tested the following testcases: >>>>>>>>> >>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>> >>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>> I'm not sure, if they are included into any of the Mach5 >>>>>>>> testing levels. >>>>>>>> Will need to check. >>>>>>>> We have to make sure these tests are still passed. >>>>>>> >>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>> employee. >>>>>>> Can you run them with this change? >>>>>> >>>>>> Ok. >>>>>> I will sponsor this fix and run these tests before the push. >>>>>> >>>>>> It seems, another update and one more review is needed. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Some comments. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>> ??? 38???????? try{ >>>>>>>>>> >>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>> ??? Would it better to defin a common base class with these >>>>>>>>>> methods? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Otherwise, it looks good. >>>>>>>>>> Thank you for taking care about it! >>>>>>>>>> >>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> If we try to attach invalid JVMTI agent via >>>>>>>>>>>> JVMTI.agent_load dcmd, we >>>>>>>>>>>> will get "Command executed successfully". However, it >>>>>>>>>>>> implies error >>>>>>>>>>>> in >>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive >>>>>>>>>>>> any output >>>>>>>>>>>> from target VM. >>>>>>>>>>>> >>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to >>>>>>>>>>>> users to >>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following >>>>>>>>>>>> jtreg >>>>>>>>>>>> testcases: >>>>>>>>>>>> >>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>> >>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>> >>> From daniel.daugherty at oracle.com Wed Nov 15 20:32:13 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Nov 2017 15:32:13 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> Message-ID: <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> Greetings, Robbin rebased the project last night/this morning to merge with Thread Local Handshakes (TLH) and also picked up additional changesets up thru: > Changeset: fa736014cf28 > Author: cjplummer > Date: 2017-11-14 18:08 -0800 > URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 > > 8191049: Add alternate version of pns() that is callable from within hotspot source > Summary: added pns2() to debug.cpp > Reviewed-by: stuefe, gthornbr This is the first time we've rebased the project to bits that are this fresh (< 12 hours old at rebase time). We've done this because we think we're done with this project and are in the final review-change-retest cycle(s)... In other words, we're not planning on making any more major changes for this project... :-) *** Time for code reviewers to chime in on this thread! *** Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ Here's is the delta webrev from the 2017.11.10 rebase: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ Dan has submitted the bits for the usual Mach5 tier[1-5] testing (and the new baseline also)... We're expecting this round to be a little noisier than usual because we did not rebase on a PIT snapshot so the new baseline has not been through Jesper's usual care-and-feeding of integration_blockers, etc. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: > Greetings, > > I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. > (Yes, we're playing chase-the-repo...) > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ > > Unlike the previous rebase, there were no changes required to the > open code to get the rebased bits to build so there is no delta > webrev. > > These bits have been run through JPRT and I've submitted the usual > Mach5 tier[1-5] test run... > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >> >> Here are the updated webrevs: >> >> Here's the mq comment for the change: >> >> ? Rebase to 2017.10.25 PIT snapshot. >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >> >> And here is the delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >> >> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >> weekend. Didn't see any issues in a quick look. Going to take a closer >> look today. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Resolving one of the code review comments (from both Stefan K and >>> Coleen) >>> on jdk10-04-full required quite a few changes so it is being done as a >>> standalone patch and corresponding webrevs: >>> >>> Here's the mq comment for the change: >>> >>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>> ??? JavaThreadIteratorWithHandle. >>> >>> Here is the full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>> >>> And here is the delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> We have a (eXtra Large) fix for the following bug: >>>> >>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>> >>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>> Hazard Pointers to manage JavaThread lifecycle. >>>> >>>> Here's a PDF for the internal wiki that we've been using to describe >>>> and track the work on this project: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>> >>>> >>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>> in the PDF that are not present in the internal wiki. We don't have a >>>> solution for that problem yet. >>>> >>>> Here's the webrev for current JDK10 version of this fix: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>> >>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>> additional testing on Erik and Robbin's machines. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Daniel Daugherty >>>> Erik Osterlund >>>> Robbin Ehn >>>> >>> >>> >> >> > > From david.holmes at oracle.com Thu Nov 16 02:11:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 12:11:15 +1000 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> Message-ID: Hi Serguei, > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' There should not be any "/lib/" in that path David On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa and David, > > > On 11/15/17 04:56, David Holmes wrote: >> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>> Hi Serguei, >>> >>>> Do the new tests pass in your runs? >>> >>> Of course. >>> It seems not to exist jtreg native libraries. >>> I've tested as below: >>> >>> ?? $ make build-test-hotspot-jtreg-native >>> ?? $ cd test >>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet >>> -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach >>> hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach > > Thanks. > I missed to add the -nativepath flag, sorry. > >> Please check that: >> >> make test-image >> >> followed by jtreg >> -nativepath:/images/test/hotspot/jtreg/native >> >> also works. > > It fails with the error: > > ? 63 Running DCMD 'JVMTI.agent_load > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' > through 'PidJcmdExecutor' > ? 64 Executing command > '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, > 28407, JVMTI.agent_load > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg > /native/lib/libException.so]' > ? 65 Command returned with exit code 0 > ? 66 ---------------- stdout ---------------- > ? 67 28407: > ? 68 > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so > was not loaded. > ? 69 > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: > cannot open shared object file: No such file or directory > ? 70 > > > It seems, the '/lib' folder is added to the nativepath. > > Yasumasa, could you, double check it please? > > I'm using the jtreg: > ? /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg > > which is: > > % ls -l /java/re/jtreg/4.2/promoted/latest > lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest > -> fcs/b10/ > > > Thanks, > Serguei > > >> >> Thanks, >> David >> >>> >>>> Good news is that the attach-related tests from closed repository >>>> are passed. >>> >>> Thanks! >>> >>> >>> Yasumasa >>> >>> >>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> Do the new tests pass in your runs? >>>> >>>> In my runs 3 of 4 tests are failed with the errors like this: >>>> >>>> ??109 Running DCMD 'JVMTI.agent_load >>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >>>> through 'PidJcmdExecutor' >>>> ??110 Executing command >>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>> 21951, JVMTI.agent_load >>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>> >>>> ??111 Command returned with exit code 0 >>>> ??112 ---------------- stdout ---------------- >>>> ??113 21951: >>>> ??114 >>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >>>> was not loaded. >>>> ??115 >>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >>>> cannot open shared object file: No such file or directory >>>> ??116 >>>> >>>> >>>> Good news is that the attach-related tests from closed repository >>>> are passed. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> It looks good to me. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> I uploaded new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>> >>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>> like: For >>>>>>>>> input string: "apa". >>>>>>>> >>>>>>>> Should we remove this comparison? >>>>>>> >>>>>>> I don't understand. Why do remove? >>>>>>> Would it better to check for the exception name instead? >>>>>> I've changed to check exception name (NumberFormatException) in >>>>>> StartManagementAgent.java. >>>>>> >>>>>>> I will sponsor this fix and run these tests before the push. >>>>>> Thanks! >>>>>> I'm waiting for second reviewer. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>> : >>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> The changes looks good. >>>>>>>>> Thank you for making them! >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> Thank you for your comment! >>>>>>>>>> I uploaded new webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>> >>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>>> >>>>>>>>>> ------------- >>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>>> number: apa >>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>> [runApplication]??????? at >>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>> >>>>>>>>>> ------------- >>>>>>>>>> >>>>>>>>>> I think we should check exception message in >>>>>>>>>> AttachOperationFailedException. >>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>> like: For >>>>>>>>> input string: "apa". >>>>>>>> >>>>>>>> Should we remove this comparison? >>>>>>> >>>>>>> I don't understand. Why do remove? >>>>>>> Would it better to check for the exception name instead? >>>>>>> >>>>>>> >>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>> >>>>>>>>>> I've tested the following testcases: >>>>>>>>>> >>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>> >>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>> I'm not sure, if they are included into any of the Mach5 >>>>>>>>> testing levels. >>>>>>>>> Will need to check. >>>>>>>>> We have to make sure these tests are still passed. >>>>>>>> >>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>>> employee. >>>>>>>> Can you run them with this change? >>>>>>> >>>>>>> Ok. >>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>> >>>>>>> It seems, another update and one more review is needed. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> Some comments. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>> >>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>> ??? Would it better to defin a common base class with these >>>>>>>>>>> methods? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>> >>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> If we try to attach invalid JVMTI agent via >>>>>>>>>>>>> JVMTI.agent_load dcmd, we >>>>>>>>>>>>> will get "Command executed successfully". However, it >>>>>>>>>>>>> implies error >>>>>>>>>>>>> in >>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive >>>>>>>>>>>>> any output >>>>>>>>>>>>> from target VM. >>>>>>>>>>>>> >>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to >>>>>>>>>>>>> users to >>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following >>>>>>>>>>>>> jtreg >>>>>>>>>>>>> testcases: >>>>>>>>>>>>> >>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>> >>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>> >>>> > From david.holmes at oracle.com Thu Nov 16 02:46:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 12:46:53 +1000 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> <652fe395-467e-4eb7-86af-1fef5f7069fe@default> <8feda117-fc7a-b0c6-f614-b0c77574b1bb@oracle.com> Message-ID: On 15/11/2017 3:27 PM, Jini George wrote: > Thank you, Sharath and David. The revised webrev after addressing the > comments are at: > > http://cr.openjdk.java.net/~jgeorge/8190307/webrev.03/ Please put all the informational tags first: @test @bug @summary You didn't delete the int exitValue = p.exitValue(); lines. No need to see an updated webrev with these fixes. Thanks, David > Thanks, > Jini. > > On 11/15/2017 7:00 AM, David Holmes wrote: >> Hi Jini, >> >> In addition to Sharath's comments please add @bug and @summary items >> to each test header. >> >> Thanks, >> David >> ----- >> >> On 15/11/2017 2:31 AM, Sharath Ballal wrote: >>> Hi Jini, >>> >>> Code looks good.? Some nits. >>> >>> TestUniverse.java: >>> >>> These lines can be removed >>> ??? 26 import java.io.File; >>> ??? 33 import jdk.test.lib.process.ProcessTools; >>> ??? 84???????? int exitValue = p.exitValue(); >>> >>> TestType.java: >>> >>> These lines can be removed >>> ??? 32 import jdk.test.lib.process.ProcessTools; >>> ??? 86???????? int exitValue = p.exitValue(); >>> >>> You may want to add few more strings in the defaultOutputStrings. >>> >>> TestIntConstant.java >>> >>> These lines can be removed >>> ??? 32 import jdk.test.lib.process.ProcessTools; >>> ??? 89???????? int exitValue = p.exitValue(); >>> >>> You may want to add few more strings in the defaultOutputStrings. >>> >>> Thanks, >>> Sharath (not a reviewer) >>> >>> >>> -----Original Message----- >>> From: Jini George >>> Sent: Tuesday, November 14, 2017 2:19 PM >>> To: David Holmes; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: (small): JDK-8190307: SA: Sanity tests for the >>> clhsdb commands: universe, intconstant, type >>> >>> Thank you very much, David. Here is the revised webrev: >>> >>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ >>> >>> Have reduced the exitValue checking fragment and included >>> p.destroyForcibly(). Also placed the creation of OutputAnalyzer >>> before waiting for the jhsdb process exit, to avoid jhsdb hangs due >>> to the output stream buffer not being consumed. (Thanks, Sharath!) >>> >>> Thanks, >>> Jini. >>> >>> On 11/6/2017 12:58 PM, David Holmes wrote: >>>> Hi Jini, >>>> >>>> On 3/11/2017 8:51 PM, Jini George wrote: >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >>>>> >>>>> I have made changes to validate the test results of each command >>>>> separately, done away with the asserts and have added some more >>>>> comments. >>>> >>>> This looks much better to me - thanks. This fragment: >>>> >>>> ? ????????? int exitValue = p.exitValue(); >>>> ? ????????? OutputAnalyzer output = new OutputAnalyzer(p); >>>> ? ????????? System.out.println(output.getOutput()); >>>> >>>> ? ????????? if (exitValue != 0) { >>>> ? ????????????? throw new Error("clhsdb wasn't run successfully."); >>>> ? ????????? } >>>> >>>> can be reduced to: >>>> >>>> OutputAnalyzer output = new OutputAnalyzer(p); >>>> output.shouldHaveExitValue(0); >>>> >>>> There's probably no need to print getOutput() as if anything goes >>>> wrong it will be printed by OutputAnalyzer anyway. But that's your >>>> choice. >>>> >>>> It may also be advisable to ensure the process is destroyed if you get >>>> an exception here: >>>> >>>> ? ???????? try { >>>> ? ???????????? p.waitFor(); >>>> ? ???????? } catch (InterruptedException ie) { >>>> +??????????? p.destroyForcibly(); >>>> ? ???????????? throw new Error("Problem awaiting the child process: " + >>>> ie, ie); >>>> ? ???????? } >>>> >>>> similar to how ProcessTools.executeProcess manages things. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thank you, >>>>> Jini. >>>>> >>>>> On 10/31/2017 12:32 PM, Jini George wrote: >>>>>> Thank you for the quick review, David. My comments inline: >>>>>> >>>>>> On 10/30/2017 11:18 AM, David Holmes wrote: >>>>>> >>>>>>>> Plus this assumes G1 is being used but Lingered App is started >>>>>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>>>>> were passed through, wouldn't it? >>>>>>> >>>>>>> Okay the above are just examples of "int constants" that will be >>>>>>> printed when you dump all the "int constants". The G1 constant >>>>>>> doesn't indicate (I presume) that G1 is the active GC. >>>>>> >>>>>> Yes, the int constants contain compile time values and there are >>>>>> entries for all the GC types. >>>>>> >>>>>>> As I said to Sharath it would be good to validate the results of >>>>>>> each command separately rather than collectively. >>>>>> >>>>>> Will do. >>>>>> >>>>>> Thanks! >>>>>> - Jini. >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> TestType.java >>>>>>>> >>>>>>>> The expected output is not quite so strange, but still could do >>>>>>>> with some commentary. >>>>>>>> >>>>>>>> ??? 90???????? Asserts.assertTrue(output.contains("type >>>>>>>> G1CollectedHeap CollectedHeap")); >>>>>>>> >>>>>>>> Same comment about assuming G1. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ------ >>>>>>>> >>>>>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> We have been working on writing sanity tests for the various >>>>>>>>> jhsdb clhsdb commands of the SA to improve the robustness of the >>>>>>>>> SA. As a part of this, here is a webrev for sanity tests for 3 of >>>>>>>>> the clhsdb commands: >>>>>>>>> >>>>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>>>>> >>>>>>>>> I would like to request for reviews for this simple addition. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Jini. From david.holmes at oracle.com Thu Nov 16 02:51:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 12:51:50 +1000 Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> <1af98ba5-6296-b728-616f-a1af93009972@oracle.com> Message-ID: <5ed6286d-d8f1-1681-56fa-2d471635ca75@oracle.com> That looks fine. Thanks, David On 15/11/2017 7:58 PM, Sharath Ballal wrote: > > Thanks David. Here is the revised webrev after addressing the comments: > > http://cr.openjdk.java.net/~sballal/8190198/webrev.04/ > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Wednesday, November 15, 2017 7:26 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > This is looking very good. > > A few comments below. > > On 14/11/2017 3:32 PM, Sharath Ballal wrote: >> My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). >> >> " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." >> >> Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. >> >> Here is the latest webrev: >> http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ > > General comments: > > Please add @bug to each test header. > > I would not expect you to need this in each test? > > * @modules java.base > > Style nit: you're using an unusual indentation for code like: > > 57 List cmds = List.of( > 58 "flags", "flags -nd", > 59 "flags UseJVMCICompiler", "flags MaxFDLimit", > 60 "flags MaxJavaStackTraceDepth"); > > and > > 63 expStrMap.put("flags", List.of( > 64 "UseJVMCICompiler = true", > 65 "MaxFDLimit = false", > > but it's readable so I won't insist on any changes. > > --- > > test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java > > The @param names don't match the actual args on run/runCmd. > > 78 private String runCmd(List commands, > 79 Map> expectedStrMap, > 80 Map> unExpectedStrMap) > > Indent is wrong on 79 and 80: Map should line up with List on 78. > > 144 public String run(long lingeredAppPid, List commands, > 145 Map> > expectedStrMap, > 146 Map> > UnExpectedStrMap) > > Indent is wrong. > > --- > > test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java > test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java > > You should use @requires to exclude execution on OS X rather than a Platform check in the test. > > Thanks, > David > > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Tuesday, November 07, 2017 12:09 PM >> To: David Holmes; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> I have made changes to use the outputAnalyzer (thanks Jini). >> Latest webrev is : >> http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Sunday, November 05, 2017 10:04 PM >> To: David Holmes; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> Thanks David for the comments. Reply inline. >> The new webrev is at >> http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, October 30, 2017 11:15 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> Hi Sharath, >> >> I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. >> >> I have a few comments. >> >> On 30/10/2017 2:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> This webrev has changes for a framework for running the 'jhsdb clhsdb' >>> commands and verifying the output.? It also has sanity tests for 8 of >> >> I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? >> [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: >> => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... >> hsdb> >> hsdb> >> hsdb> flags >> .... >> ...... >> ZombieALotInterval = 5 0 >> hashCode = 5 0 >> hsdb> >> hsdb> >> >> My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. >> OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); >> toolProcess.waitFor(); >> output = outputAnalyzer.getOutput(); >> >> Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? >> [Sharath Ballal] Launcher can do it. I have made the changes. >> >> Can the launcher internalize the management of the LingeredApp? >> [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. >> Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. >> >> Can the launcher also handle the shouldSAAttach check? >> [Sharath Ballal] Yes. I have made that change. >> >> I can imagine the test logic reducing to a very simple: >> >> println(Starting test of ... >> List cmds = List.of( ...); >> List expected = List.of(...); >> List unexpected = Listd.of(...); ClhsdbLauncher.run(cmds, >> expected, unexpected); // static method println("test PASSED"); >> >> I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. >> [Sharath Ballal] I have done this change. >> >> I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. >> [Sharath Ballal] OK. I have done these changes. >> >> It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. >> >> or the difference in expected output >> between: >> >> 57 "longConstant jtreg::test 6\n", >> 58 "longConstant jtreg::test\n", >> >> I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? >> [Sharath Ballal] Yes. >> I have provided a way to specify the expected/unexpected output per command and check it separately. >> >> Thanks, >> David >> >>> the clhsdb commands. >>> >>> Pls review the changes. >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >>> >>> Thanks, >>> >>> Sharath >>> From jini.george at oracle.com Thu Nov 16 03:04:16 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 16 Nov 2017 08:34:16 +0530 Subject: RFR: (small): JDK-8190307: SA: Sanity tests for the clhsdb commands: universe, intconstant, type In-Reply-To: References: <48edce44-1ec4-260d-a653-76afe4887aa9@oracle.com> <5bbebc60-33a8-771e-af65-8a5e6ffd9f81@oracle.com> <1bacd0fa-1661-1469-698e-0d3ce3f92a89@oracle.com> <7eb971dd-185b-0eef-edc3-f25985821ad9@oracle.com> <7aa21e36-aefa-929a-9b29-76fabf264469@oracle.com> <652fe395-467e-4eb7-86af-1fef5f7069fe@default> <8feda117-fc7a-b0c6-f614-b0c77574b1bb@oracle.com> Message-ID: Thank you very much, David. - Jini. On 11/16/2017 8:16 AM, David Holmes wrote: > On 15/11/2017 3:27 PM, Jini George wrote: >> Thank you, Sharath and David. The revised webrev after addressing the >> comments are at: >> >> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.03/ > > Please put all the informational tags first: > > @test > @bug > @summary > > You didn't delete the > > ?? int exitValue = p.exitValue(); > > lines. > > No need to see an updated webrev with these fixes. > > Thanks, > David > > >> Thanks, >> Jini. >> >> On 11/15/2017 7:00 AM, David Holmes wrote: >>> Hi Jini, >>> >>> In addition to Sharath's comments please add @bug and @summary items >>> to each test header. >>> >>> Thanks, >>> David >>> ----- >>> >>> On 15/11/2017 2:31 AM, Sharath Ballal wrote: >>>> Hi Jini, >>>> >>>> Code looks good.? Some nits. >>>> >>>> TestUniverse.java: >>>> >>>> These lines can be removed >>>> ??? 26 import java.io.File; >>>> ??? 33 import jdk.test.lib.process.ProcessTools; >>>> ??? 84???????? int exitValue = p.exitValue(); >>>> >>>> TestType.java: >>>> >>>> These lines can be removed >>>> ??? 32 import jdk.test.lib.process.ProcessTools; >>>> ??? 86???????? int exitValue = p.exitValue(); >>>> >>>> You may want to add few more strings in the defaultOutputStrings. >>>> >>>> TestIntConstant.java >>>> >>>> These lines can be removed >>>> ??? 32 import jdk.test.lib.process.ProcessTools; >>>> ??? 89???????? int exitValue = p.exitValue(); >>>> >>>> You may want to add few more strings in the defaultOutputStrings. >>>> >>>> Thanks, >>>> Sharath (not a reviewer) >>>> >>>> >>>> -----Original Message----- >>>> From: Jini George >>>> Sent: Tuesday, November 14, 2017 2:19 PM >>>> To: David Holmes; serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR: (small): JDK-8190307: SA: Sanity tests for the >>>> clhsdb commands: universe, intconstant, type >>>> >>>> Thank you very much, David. Here is the revised webrev: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.02/ >>>> >>>> Have reduced the exitValue checking fragment and included >>>> p.destroyForcibly(). Also placed the creation of OutputAnalyzer >>>> before waiting for the jhsdb process exit, to avoid jhsdb hangs due >>>> to the output stream buffer not being consumed. (Thanks, Sharath!) >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 11/6/2017 12:58 PM, David Holmes wrote: >>>>> Hi Jini, >>>>> >>>>> On 3/11/2017 8:51 PM, Jini George wrote: >>>>>> Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~jgeorge/8190307/webrev.01/ >>>>>> >>>>>> I have made changes to validate the test results of each command >>>>>> separately, done away with the asserts and have added some more >>>>>> comments. >>>>> >>>>> This looks much better to me - thanks. This fragment: >>>>> >>>>> ? ????????? int exitValue = p.exitValue(); >>>>> ? ????????? OutputAnalyzer output = new OutputAnalyzer(p); >>>>> ? ????????? System.out.println(output.getOutput()); >>>>> >>>>> ? ????????? if (exitValue != 0) { >>>>> ? ????????????? throw new Error("clhsdb wasn't run successfully."); >>>>> ? ????????? } >>>>> >>>>> can be reduced to: >>>>> >>>>> OutputAnalyzer output = new OutputAnalyzer(p); >>>>> output.shouldHaveExitValue(0); >>>>> >>>>> There's probably no need to print getOutput() as if anything goes >>>>> wrong it will be printed by OutputAnalyzer anyway. But that's your >>>>> choice. >>>>> >>>>> It may also be advisable to ensure the process is destroyed if you get >>>>> an exception here: >>>>> >>>>> ? ???????? try { >>>>> ? ???????????? p.waitFor(); >>>>> ? ???????? } catch (InterruptedException ie) { >>>>> +??????????? p.destroyForcibly(); >>>>> ? ???????????? throw new Error("Problem awaiting the child process: >>>>> " + >>>>> ie, ie); >>>>> ? ???????? } >>>>> >>>>> similar to how ProcessTools.executeProcess manages things. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thank you, >>>>>> Jini. >>>>>> >>>>>> On 10/31/2017 12:32 PM, Jini George wrote: >>>>>>> Thank you for the quick review, David. My comments inline: >>>>>>> >>>>>>> On 10/30/2017 11:18 AM, David Holmes wrote: >>>>>>> >>>>>>>>> Plus this assumes G1 is being used but Lingered App is started >>>>>>>>> using the test run vmOptions AFAICS so it would use whatever GC >>>>>>>>> were passed through, wouldn't it? >>>>>>>> >>>>>>>> Okay the above are just examples of "int constants" that will be >>>>>>>> printed when you dump all the "int constants". The G1 constant >>>>>>>> doesn't indicate (I presume) that G1 is the active GC. >>>>>>> >>>>>>> Yes, the int constants contain compile time values and there are >>>>>>> entries for all the GC types. >>>>>>> >>>>>>>> As I said to Sharath it would be good to validate the results of >>>>>>>> each command separately rather than collectively. >>>>>>> >>>>>>> Will do. >>>>>>> >>>>>>> Thanks! >>>>>>> - Jini. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> TestType.java >>>>>>>>> >>>>>>>>> The expected output is not quite so strange, but still could do >>>>>>>>> with some commentary. >>>>>>>>> >>>>>>>>> ??? 90???????? Asserts.assertTrue(output.contains("type >>>>>>>>> G1CollectedHeap CollectedHeap")); >>>>>>>>> >>>>>>>>> Same comment about assuming G1. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> On 30/10/2017 1:44 PM, Jini George wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> We have been working on writing sanity tests for the various >>>>>>>>>> jhsdb clhsdb commands of the SA to improve the robustness of the >>>>>>>>>> SA. As a part of this, here is a webrev for sanity tests for 3 of >>>>>>>>>> the clhsdb commands: >>>>>>>>>> >>>>>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190307 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8190307/webrev.00/ >>>>>>>>>> >>>>>>>>>> I would like to request for reviews for this simple addition. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Jini. From sharath.ballal at oracle.com Thu Nov 16 03:53:03 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 15 Nov 2017 19:53:03 -0800 (PST) Subject: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands In-Reply-To: <5ed6286d-d8f1-1681-56fa-2d471635ca75@oracle.com> References: <6824f2b2-0afb-24ea-5996-0942272570c3@oracle.com> <7aee2719-c91b-4361-ac42-fd54aaa2b553@default> <1af98ba5-6296-b728-616f-a1af93009972@oracle.com> <5ed6286d-d8f1-1681-56fa-2d471635ca75@oracle.com> Message-ID: Thanks David. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Thursday, November 16, 2017 8:22 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb clhsdb' commands tests and testcases for some of the commands That looks fine. Thanks, David On 15/11/2017 7:58 PM, Sharath Ballal wrote: > > Thanks David. Here is the revised webrev after addressing the comments: > > http://cr.openjdk.java.net/~sballal/8190198/webrev.04/ > > Thanks, > Sharath > > > -----Original Message----- > From: David Holmes > Sent: Wednesday, November 15, 2017 7:26 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb > clhsdb' commands tests and testcases for some of the commands > > Hi Sharath, > > This is looking very good. > > A few comments below. > > On 14/11/2017 3:32 PM, Sharath Ballal wrote: >> My changes with using the outputAnalyzer were creating timeouts. This was seen with testcases creating more output. As per the documentation of Process class this is expected as I was creating the outputAnalyzer after doing Process.waitFor(). >> >> " Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the process may cause the process to block, or even deadlock." >> >> Hence I made changes to create the outputAnalyzer before Process.waitFor(). outputAnalyzer takes care of creating threads and reading the process output and error and hence we should not have the same problem. The tests are passing on Mach5. >> >> Here is the latest webrev: >> http://cr.openjdk.java.net/~sballal/8190198/webrev.03/ > > General comments: > > Please add @bug to each test header. > > I would not expect you to need this in each test? > > * @modules java.base > > Style nit: you're using an unusual indentation for code like: > > 57 List cmds = List.of( > 58 "flags", "flags -nd", > 59 "flags UseJVMCICompiler", "flags MaxFDLimit", > 60 "flags MaxJavaStackTraceDepth"); > > and > > 63 expStrMap.put("flags", List.of( > 64 "UseJVMCICompiler = true", > 65 "MaxFDLimit = false", > > but it's readable so I won't insist on any changes. > > --- > > test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java > > The @param names don't match the actual args on run/runCmd. > > 78 private String runCmd(List commands, > 79 Map> expectedStrMap, > 80 Map> unExpectedStrMap) > > Indent is wrong on 79 and 80: Map should line up with List on 78. > > 144 public String run(long lingeredAppPid, List commands, > 145 Map> > expectedStrMap, > 146 Map> > UnExpectedStrMap) > > Indent is wrong. > > --- > > test/hotspot/jtreg/serviceability/sa/ClhsdbPmap.java > test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java > > You should use @requires to exclude execution on OS X rather than a Platform check in the test. > > Thanks, > David > > >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Tuesday, November 07, 2017 12:09 PM >> To: David Holmes; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> I have made changes to use the outputAnalyzer (thanks Jini). >> Latest webrev is : >> http://cr.openjdk.java.net/~sballal/8190198/webrev.02/ >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: Sharath Ballal >> Sent: Sunday, November 05, 2017 10:04 PM >> To: David Holmes; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> Thanks David for the comments. Reply inline. >> The new webrev is at >> http://cr.openjdk.java.net/~sballal/8190198/webrev.01/ >> >> >> Thanks, >> Sharath >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, October 30, 2017 11:15 AM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8190198 - SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands >> >> Hi Sharath, >> >> I think you and Jini need to coordinate your current proposed changes. :) [Sharath Ballal] Jini is aware of these changes. She will modify the testcases later to use the new Launcher. >> >> I have a few comments. >> >> On 30/10/2017 2:29 PM, Sharath Ballal wrote: >>> Hello, >>> >>> This webrev has changes for a framework for running the 'jhsdb clhsdb' >>> commands and verifying the output.? It also has sanity tests for 8 >>> of >> >> I can't help but think the launcher should be able to utilize OutputAnalyzer. ?? >> [Sharath Ballal] clhsdb is an interactive command line tool. After launching clhsdb, we get a prompt. Further commands are typed on the prompt, finally we quit the tool. Example: >> => sudo /home/sharath/java/src/java10/hs_8189061/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --pid 8306 Attaching to process 8306, please wait... >> hsdb> >> hsdb> >> hsdb> flags >> .... >> ...... >> ZombieALotInterval = 5 0 >> hashCode = 5 0 >> hsdb> >> hsdb> >> >> My understanding is that OutputAnalyzer does not work with such cases (an earlier clhsdb testcase also does not use outputAnalyzer, open/test/jdk/sun/tools/jhsdb/BasicLauncherTest.java). I tried creating OutputAnalyzer after running the commands as shown below but the testcase times out. >> OutputAnalyzer outputAnalyzer = new OutputAnalyzer(toolProcess); >> toolProcess.waitFor(); >> output = outputAnalyzer.getOutput(); >> >> Do you require the input commands to include the "quit"? Is there a reason the launcher couldn't handle that itself? >> [Sharath Ballal] Launcher can do it. I have made the changes. >> >> Can the launcher internalize the management of the LingeredApp? >> [Sharath Ballal] LingeredApp can be derived and the subclass can add more specific things as per the testcase. For examples pls see DeadlockDetectionTest.java and LingeredAppWithDeadlock.java and other similar classes in the same directory. >> Hence I have left it up to the user to create an instance of LingeredApp and pass the pid as an argument. >> >> Can the launcher also handle the shouldSAAttach check? >> [Sharath Ballal] Yes. I have made that change. >> >> I can imagine the test logic reducing to a very simple: >> >> println(Starting test of ... >> List cmds = List.of( ...); >> List expected = List.of(...); List unexpected = >> Listd.of(...); ClhsdbLauncher.run(cmds, expected, unexpected); // >> static method println("test PASSED"); >> >> I don't see why the test classes should be subclasses of the Clhsdblauncher class - the tests are not launchers themselves. The launcher class is just a utility class that should have public rather than protected methods. >> [Sharath Ballal] I have done this change. >> >> I'm not sure the approach of sending a set of commands, and having a set of expected outputs is the right/best way to test this. I would expect to see a check of the expected outcome for each command ie send a command, check the result, send the next command, etc. Or if you can put/detect delimiters in the output you could still send all the commands and then bulk process the output. But the present approach allows for the commands to actually do the wrong things, as long as the expected output appears somewhere. >> [Sharath Ballal] OK. I have done these changes. >> >> It also unclear what output corresponds to what command and why. Eg in the longConstant test it is not obvious why you expect to see markOopDesc::epoch_mask_in_place, [Sharath Ballal] markOopDesc::epoch_mask_in_place is one of the longConstants that is printed by longConstant command. >> >> or the difference in expected output >> between: >> >> 57 "longConstant jtreg::test 6\n", >> 58 "longConstant jtreg::test\n", >> >> I'm guessing the first silently declares and sets a variable, while the second reads it back - is that right? >> [Sharath Ballal] Yes. >> I have provided a way to specify the expected/unexpected output per command and check it separately. >> >> Thanks, >> David >> >>> the clhsdb commands. >>> >>> Pls review the changes. >>> >>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8190198 >>> >>> Webrev: http://cr.openjdk.java.net/~sballal/8190198/webrev.00/ >>> >>> Thanks, >>> >>> Sharath >>> From chris.plummer at oracle.com Thu Nov 16 04:16:18 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Nov 2017 20:16:18 -0800 Subject: RFR(S): 8186540: [TESTBUG] serviceability/dcmd/jvmti/LoadAgentDcmdTest.java failed to clean up files in agentvm mode Message-ID: <20045a53-e135-3bb6-e209-4e1e15e84cfb@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 16 04:28:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 14:28:59 +1000 Subject: RFR(S): 8186540: [TESTBUG] serviceability/dcmd/jvmti/LoadAgentDcmdTest.java failed to clean up files in agentvm mode In-Reply-To: <20045a53-e135-3bb6-e209-4e1e15e84cfb@oracle.com> References: <20045a53-e135-3bb6-e209-4e1e15e84cfb@oracle.com> Message-ID: Looks fine. Thanks, David On 16/11/2017 2:16 PM, Chris Plummer wrote: > Hello, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8186540 > http://cr.openjdk.java.net/~cjplummer/8186540/webrev.00/ > > The fix is to use "othervm" mode to avoid issues with the agent.jar file > not being closed when jtreg does cleanup on exit. > > thanks, > > Chris > From serguei.spitsyn at oracle.com Thu Nov 16 06:18:49 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Nov 2017 22:18:49 -0800 Subject: RFR(S): 8186540: [TESTBUG] serviceability/dcmd/jvmti/LoadAgentDcmdTest.java failed to clean up files in agentvm mode In-Reply-To: References: <20045a53-e135-3bb6-e209-4e1e15e84cfb@oracle.com> Message-ID: +1 Thanks, Serguei On 11/15/17 20:28, David Holmes wrote: > Looks fine. > > Thanks, > David > > On 16/11/2017 2:16 PM, Chris Plummer wrote: >> Hello, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8186540 >> http://cr.openjdk.java.net/~cjplummer/8186540/webrev.00/ >> >> The fix is to use "othervm" mode to avoid issues with the agent.jar >> file not being closed when jtreg does cleanup on exit. >> >> thanks, >> >> Chris >> From chris.plummer at oracle.com Thu Nov 16 06:35:10 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 Nov 2017 22:35:10 -0800 Subject: RFR(S): 8186540: [TESTBUG] serviceability/dcmd/jvmti/LoadAgentDcmdTest.java failed to clean up files in agentvm mode In-Reply-To: References: <20045a53-e135-3bb6-e209-4e1e15e84cfb@oracle.com> Message-ID: <5b2198d6-f034-0056-0c0b-2ff8f9b45fc8@oracle.com> Thanks David and Serguei! Chris On 11/15/17 10:18 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Thanks, > Serguei > > > On 11/15/17 20:28, David Holmes wrote: >> Looks fine. >> >> Thanks, >> David >> >> On 16/11/2017 2:16 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8186540 >>> http://cr.openjdk.java.net/~cjplummer/8186540/webrev.00/ >>> >>> The fix is to use "othervm" mode to avoid issues with the agent.jar >>> file not being closed when jtreg does cleanup on exit. >>> >>> thanks, >>> >>> Chris >>> > From serguei.spitsyn at oracle.com Thu Nov 16 06:43:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Nov 2017 22:43:43 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Nov 16 07:29:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 17:29:00 +1000 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> Message-ID: On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: > On 11/15/17 18:11, David Holmes wrote: >> Hi Serguei, >> >> > >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >> >> >> There should not be any "/lib/" in that path > > Right, it should not be. The test logic is adding it in AttachFailedTestBase.java: 45 return Paths.get(System.getProperty("test.nativepath"), "lib", libname) 46 .toAbsolutePath() 47 .toString(); but it shouldn't. David ----- > This is the script I'm using to run the tests: > > #!/bin/sh > > REPO=/var/tmp/sspitsyn/jdk.attach > IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images > export JAVA_HOME=${IMAGES}/jdk > export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native > export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native > echo "JAVA_HOME = $JAVA_HOME" > > /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg > -nativepath:${NATIVE_PATH} \ > $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed > > > This is a part of log with the reported error from the AttachException.jtr: > > [TestNG] Running: > ? serviceability/dcmd/jvmti/AttachFailed/AttachException.java > > Running DCMD 'JVMTI.agent_load > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' > through 'PidJcmdExecutor' > Executing command > '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, > 8689, JVMTI.agent_load > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' > Command returned with exit code 0 > ---------------- stdout ---------------- > 8689: > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so > was not loaded. > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: > cannot open shared object file: No such file or directory > > > These are the locations of the libException.so: > build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so > build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so > > > The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" > but pass with the "export > NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". > > > When the "export > NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used > the log has this line: > > Running DCMD 'JVMTI.agent_load > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' > through 'JMXExecutor' > > > Apparently, the sub-directory name "/lib" is added to the path. > > > Thanks, > Serguei > > >> David >> >> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa and David, >>> >>> >>> On 11/15/17 04:56, David Holmes wrote: >>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>> Hi Serguei, >>>>> >>>>>> Do the new tests pass in your runs? >>>>> >>>>> Of course. >>>>> It seems not to exist jtreg native libraries. >>>>> I've tested as below: >>>>> >>>>> ?? $ make build-test-hotspot-jtreg-native >>>>> ?? $ cd test >>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet >>>>> -nativepath://support/test/hotspot/jtreg/native/lib >>>>> hotspot/jtreg/serviceability/attach >>>>> hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>> >>> Thanks. >>> I missed to add the -nativepath flag, sorry. >>> >>>> Please check that: >>>> >>>> make test-image >>>> >>>> followed by jtreg >>>> -nativepath:/images/test/hotspot/jtreg/native >>>> >>>> also works. >>> >>> It fails with the error: >>> >>> ?? 63 Running DCMD 'JVMTI.agent_load >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>> through 'PidJcmdExecutor' >>> ?? 64 Executing command >>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>> 28407, JVMTI.agent_load >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg >>> /native/lib/libException.so]' >>> ?? 65 Command returned with exit code 0 >>> ?? 66 ---------------- stdout ---------------- >>> ?? 67 28407: >>> ?? 68 >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so >>> was not loaded. >>> ?? 69 >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: >>> cannot open shared object file: No such file or directory >>> ?? 70 >>> >>> >>> It seems, the '/lib' folder is added to the nativepath. >>> >>> Yasumasa, could you, double check it please? >>> >>> I'm using the jtreg: >>> ?? /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>> >>> which is: >>> >>> % ls -l /java/re/jtreg/4.2/promoted/latest >>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 >>> /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>>> Good news is that the attach-related tests from closed repository >>>>>> are passed. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> Do the new tests pass in your runs? >>>>>> >>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>> >>>>>> ??109 Running DCMD 'JVMTI.agent_load >>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >>>>>> through 'PidJcmdExecutor' >>>>>> ??110 Executing command >>>>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>>>> 21951, JVMTI.agent_load >>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>> >>>>>> ??111 Command returned with exit code 0 >>>>>> ??112 ---------------- stdout ---------------- >>>>>> ??113 21951: >>>>>> ??114 >>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >>>>>> was not loaded. >>>>>> ??115 >>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >>>>>> cannot open shared object file: No such file or directory >>>>>> ??116 >>>>>> >>>>>> >>>>>> Good news is that the attach-related tests from closed repository >>>>>> are passed. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> It looks good to me. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> I uploaded new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>> >>>>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>>>> like: For >>>>>>>>>>> input string: "apa". >>>>>>>>>> >>>>>>>>>> Should we remove this comparison? >>>>>>>>> >>>>>>>>> I don't understand. Why do remove? >>>>>>>>> Would it better to check for the exception name instead? >>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>> StartManagementAgent.java. >>>>>>>> >>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>> Thanks! >>>>>>>> I'm waiting for second reviewer. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>> : >>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> The changes looks good. >>>>>>>>>>> Thank you for making them! >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>> >>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>> We can get the result as below when we run >>>>>>>>>>>> StartManagementAgent: >>>>>>>>>>>> >>>>>>>>>>>> ------------- >>>>>>>>>>>> [runApplication] Error: Invalid >>>>>>>>>>>> com.sun.management.jmxremote.port >>>>>>>>>>>> number: apa >>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>> >>>>>>>>>>>> ------------- >>>>>>>>>>>> >>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>>>> like: For >>>>>>>>>>> input string: "apa". >>>>>>>>>> >>>>>>>>>> Should we remove this comparison? >>>>>>>>> >>>>>>>>> I don't understand. Why do remove? >>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>> >>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>> >>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>> >>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 >>>>>>>>>>> testing levels. >>>>>>>>>>> Will need to check. >>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>> >>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an >>>>>>>>>> Oracle >>>>>>>>>> employee. >>>>>>>>>> Can you run them with this change? >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>> >>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> Some comments. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>> >>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ??? It is odd that all test java classes define exactly the >>>>>>>>>>>>> same >>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>> ??? Would it better to defin a common base class with these >>>>>>>>>>>>> methods? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>> >>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via >>>>>>>>>>>>>>> JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>> will get "Command executed successfully". However, it >>>>>>>>>>>>>>> implies error >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive >>>>>>>>>>>>>>> any output >>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message >>>>>>>>>>>>>>> to users to >>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following >>>>>>>>>>>>>>> jtreg >>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>> >>>>>> >>> > From serguei.spitsyn at oracle.com Thu Nov 16 07:49:42 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 Nov 2017 23:49:42 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> Message-ID: <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> On 11/15/17 23:29, David Holmes wrote: > On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >> On 11/15/17 18:11, David Holmes wrote: >>> Hi Serguei, >>> >>> > >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>> >>> >>> There should not be any "/lib/" in that path >> >> Right, it should not be. > > The test logic is adding it in AttachFailedTestBase.java: > > ? 45???????? return Paths.get(System.getProperty("test.nativepath"), > "lib", libname) > ? 46???????????????????? .toAbsolutePath() > ? 47???????????????????? .toString(); > > but it shouldn't. Nice catch! I looked right to these lines and overlooked it. :) Thanks, Serguei > > David > ----- > > >> This is the script I'm using to run the tests: >> >> #!/bin/sh >> >> REPO=/var/tmp/sspitsyn/jdk.attach >> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >> export JAVA_HOME=${IMAGES}/jdk >> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >> echo "JAVA_HOME = $JAVA_HOME" >> >> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg >> -nativepath:${NATIVE_PATH} \ >> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >> >> >> This is a part of log with the reported error from the >> AttachException.jtr: >> >> [TestNG] Running: >> ?? serviceability/dcmd/jvmti/AttachFailed/AttachException.java >> >> Running DCMD 'JVMTI.agent_load >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >> through 'PidJcmdExecutor' >> Executing command >> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >> 8689, JVMTI.agent_load >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >> Command returned with exit code 0 >> ---------------- stdout ---------------- >> 8689: >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so >> was not loaded. >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: >> cannot open shared object file: No such file or directory >> >> >> These are the locations of the libException.so: >> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >> >> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >> >> >> >> The tests fail with the >> "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >> but pass with the "export >> NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >> >> >> When the "export >> NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >> the log has this line: >> >> Running DCMD 'JVMTI.agent_load >> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' >> through 'JMXExecutor' >> >> >> Apparently, the sub-directory name "/lib" is added to the path. >> >> >> Thanks, >> Serguei >> >> >>> David >>> >>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa and David, >>>> >>>> >>>> On 11/15/17 04:56, David Holmes wrote: >>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>> Hi Serguei, >>>>>> >>>>>>> Do the new tests pass in your runs? >>>>>> >>>>>> Of course. >>>>>> It seems not to exist jtreg native libraries. >>>>>> I've tested as below: >>>>>> >>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>> ?? $ cd test >>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet >>>>>> -nativepath://support/test/hotspot/jtreg/native/lib >>>>>> hotspot/jtreg/serviceability/attach >>>>>> hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>> >>>> Thanks. >>>> I missed to add the -nativepath flag, sorry. >>>> >>>>> Please check that: >>>>> >>>>> make test-image >>>>> >>>>> followed by jtreg >>>>> -nativepath:/images/test/hotspot/jtreg/native >>>>> >>>>> also works. >>>> >>>> It fails with the error: >>>> >>>> ?? 63 Running DCMD 'JVMTI.agent_load >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>> through 'PidJcmdExecutor' >>>> ?? 64 Executing command >>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>> 28407, JVMTI.agent_load >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg >>>> /native/lib/libException.so]' >>>> ?? 65 Command returned with exit code 0 >>>> ?? 66 ---------------- stdout ---------------- >>>> ?? 67 28407: >>>> ?? 68 >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so >>>> was not loaded. >>>> ?? 69 >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: >>>> cannot open shared object file: No such file or directory >>>> ?? 70 >>>> >>>> >>>> It seems, the '/lib' folder is added to the nativepath. >>>> >>>> Yasumasa, could you, double check it please? >>>> >>>> I'm using the jtreg: >>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>> >>>> which is: >>>> >>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 >>>> /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>>> Good news is that the attach-related tests from closed >>>>>>> repository are passed. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Do the new tests pass in your runs? >>>>>>> >>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>> >>>>>>> ??109 Running DCMD 'JVMTI.agent_load >>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >>>>>>> through 'PidJcmdExecutor' >>>>>>> ??110 Executing command >>>>>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>>>>> 21951, JVMTI.agent_load >>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>> >>>>>>> ??111 Command returned with exit code 0 >>>>>>> ??112 ---------------- stdout ---------------- >>>>>>> ??113 21951: >>>>>>> ??114 >>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >>>>>>> was not loaded. >>>>>>> ??115 >>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >>>>>>> cannot open shared object file: No such file or directory >>>>>>> ??116 >>>>>>> >>>>>>> >>>>>>> Good news is that the attach-related tests from closed >>>>>>> repository are passed. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> It looks good to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> I uploaded new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>> >>>>>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>>>>> like: For >>>>>>>>>>>> input string: "apa". >>>>>>>>>>> >>>>>>>>>>> Should we remove this comparison? >>>>>>>>>> >>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>> StartManagementAgent.java. >>>>>>>>> >>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>> Thanks! >>>>>>>>> I'm waiting for second reviewer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>> : >>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> The changes looks good. >>>>>>>>>>>> Thank you for making them! >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>> >>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>> We can get the result as below when we run >>>>>>>>>>>>> StartManagementAgent: >>>>>>>>>>>>> >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> [runApplication] Error: Invalid >>>>>>>>>>>>> com.sun.management.jmxremote.port >>>>>>>>>>>>> number: apa >>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>> >>>>>>>>>>>>> ------------- >>>>>>>>>>>>> >>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'd expect a check for some exception name, not for details >>>>>>>>>>>> like: For >>>>>>>>>>>> input string: "apa". >>>>>>>>>>> >>>>>>>>>>> Should we remove this comparison? >>>>>>>>>> >>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>> What tests did you run to make sure there are no >>>>>>>>>>>>>> regressions? >>>>>>>>>>>>> >>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>> >>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>> >>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 >>>>>>>>>>>> testing levels. >>>>>>>>>>>> Will need to check. >>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>> >>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an >>>>>>>>>>> Oracle >>>>>>>>>>> employee. >>>>>>>>>>> Can you run them with this change? >>>>>>>>>> >>>>>>>>>> Ok. >>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>> >>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>> >>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly >>>>>>>>>>>>>> the same >>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>> ??? Would it better to defin a common base class with >>>>>>>>>>>>>> these methods? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>> >>>>>>>>>>>>>> What tests did you run to make sure there are no >>>>>>>>>>>>>> regressions? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via >>>>>>>>>>>>>>>> JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>> will get "Command executed successfully". However, it >>>>>>>>>>>>>>>> implies error >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not >>>>>>>>>>>>>>>> receive any output >>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message >>>>>>>>>>>>>>>> to users to >>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as >>>>>>>>>>>>>>>> following jtreg >>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>>> >> From yasuenag at gmail.com Thu Nov 16 12:09:43 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 16 Nov 2017 21:09:43 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> Message-ID: <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> Hi David, Serguei, >> The test logic is adding it in AttachFailedTestBase.java: >> >> 45 return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >> 46 .toAbsolutePath() >> 47 .toString(); Thanks! I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ I've tested it as below. It works fine: $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed $ echo $NATIVE_PATH //images/test/hotspot/jtreg/native Thanks, Yasumasa On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote: > On 11/15/17 23:29, David Holmes wrote: >> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >>> On 11/15/17 18:11, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>> >>>> There should not be any "/lib/" in that path >>> >>> Right, it should not be. >> >> The test logic is adding it in AttachFailedTestBase.java: >> >> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >> ? 46???????????????????? .toAbsolutePath() >> ? 47???????????????????? .toString(); >> >> but it shouldn't. > > Nice catch! > I looked right to these lines and overlooked it. :) > > Thanks, > Serguei > >> >> David >> ----- >> >> >>> This is the script I'm using to run the tests: >>> >>> #!/bin/sh >>> >>> REPO=/var/tmp/sspitsyn/jdk.attach >>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >>> export JAVA_HOME=${IMAGES}/jdk >>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >>> echo "JAVA_HOME = $JAVA_HOME" >>> >>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg -nativepath:${NATIVE_PATH} \ >>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>> >>> >>> This is a part of log with the reported error from the AttachException.jtr: >>> >>> [TestNG] Running: >>> ?? serviceability/dcmd/jvmti/AttachFailed/AttachException.java >>> >>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>> Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 8689, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >>> Command returned with exit code 0 >>> ---------------- stdout ---------------- >>> 8689: >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so was not loaded. >>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: cannot open shared object file: No such file or directory >>> >>> >>> These are the locations of the libException.so: >>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >>> >>> >>> The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >>> but pass with the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >>> >>> >>> When the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >>> the log has this line: >>> >>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' through 'JMXExecutor' >>> >>> >>> Apparently, the sub-directory name "/lib" is added to the path. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> David >>>> >>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa and David, >>>>> >>>>> >>>>> On 11/15/17 04:56, David Holmes wrote: >>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>>> Do the new tests pass in your runs? >>>>>>> >>>>>>> Of course. >>>>>>> It seems not to exist jtreg native libraries. >>>>>>> I've tested as below: >>>>>>> >>>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>>> ?? $ cd test >>>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>>> >>>>> Thanks. >>>>> I missed to add the -nativepath flag, sorry. >>>>> >>>>>> Please check that: >>>>>> >>>>>> make test-image >>>>>> >>>>>> followed by jtreg -nativepath:/images/test/hotspot/jtreg/native >>>>>> >>>>>> also works. >>>>> >>>>> It fails with the error: >>>>> >>>>> ?? 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>> ?? 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]' >>>>> ?? 65 Command returned with exit code 0 >>>>> ?? 66 ---------------- stdout ---------------- >>>>> ?? 67 28407: >>>>> ?? 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded. >>>>> ?? 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory >>>>> ?? 70 >>>>> >>>>> >>>>> It seems, the '/lib' folder is added to the nativepath. >>>>> >>>>> Yasumasa, could you, double check it please? >>>>> >>>>> I'm using the jtreg: >>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>>> >>>>> which is: >>>>> >>>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Do the new tests pass in your runs? >>>>>>>> >>>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>>> >>>>>>>> ??109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>> ??110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>>> ??111 Command returned with exit code 0 >>>>>>>> ??112 ---------------- stdout ---------------- >>>>>>>> ??113 21951: >>>>>>>> ??114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. >>>>>>>> ??115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>> ??116 >>>>>>>> >>>>>>>> >>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> It looks good to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> I uploaded new webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>>> >>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>> >>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>> >>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>>> StartManagementAgent.java. >>>>>>>>>> >>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>> Thanks! >>>>>>>>>> I'm waiting for second reviewer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>>> : >>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> The changes looks good. >>>>>>>>>>>>> Thank you for making them! >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>> >>>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>>>>>>> number: apa >>>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>> >>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>> >>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>>> >>>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>>>>>>>>>>> Will need to check. >>>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>>> >>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>>>>>>> employee. >>>>>>>>>>>> Can you run them with this change? >>>>>>>>>>> >>>>>>>>>>> Ok. >>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>> >>>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>>> ??? Would it better to defin a common base class with these methods? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Fri Nov 17 00:25:27 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 16:25:27 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Nov 17 00:34:32 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 16 Nov 2017 16:34:32 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Nov 17 00:56:45 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 16:56:45 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Nov 17 01:01:07 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 17:01:07 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: <7f36328d-ef73-1f0b-d89a-4522b4ff4eea@oracle.com> An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri Nov 17 01:27:12 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 16 Nov 2017 20:27:12 -0500 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <7f36328d-ef73-1f0b-d89a-4522b4ff4eea@oracle.com> References: <7f36328d-ef73-1f0b-d89a-4522b4ff4eea@oracle.com> Message-ID: <8d1f39e2-3227-c167-2727-578922505b3e@oracle.com> Also reviewed the CSR. Added a comment about one typo/grammar change, but it's finalized so I did not actually make the change. Dan On 11/16/17 8:01 PM, serguei.spitsyn at oracle.com wrote: > Chris, > > I've also moved the statements about compatibility risk from the > "Description" section > to the "Compatibility Risk Description" special section. > > Thanks, > Serguei > > > On 11/16/17 16:56, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> Thank you a lot for looking at the CSR. >> >> >> On 11/16/17 16:34, Chris Plummer wrote: >>> Hi Serguei, >>> >>> I've read through it and it looks fine except for one minor thing: >>> >>> "The solution is to clear all bound NotifyFramePop requests when a >>> stack frame is popped." >>> >>> I think this could be made more clear. It makes it sound like you >>> clear *all* NotifyFramePop requests the first time *any* frame is >>> popped. >>> >> >> I've changed it to: >> ? "The solution is to clear the NotifyFramePop requests related to >> the popped frame when a stack frame is popped." >> >> Does is sound better? >> >> >>> This is the first time I've dealt with a CSR. What do I need to do >>> to mark it reviewed? >> >> It is the first time for me too. :) >> I think, you have to add yourself to the reviewed-by list. >> I've just added you to this list. >> Also, it could be Ok to add comments. >> >> Thanks, >> Serguei >> >> >> >>> >>> thanks, >>> >>> Chris >>> >>> On 11/16/17 4:25 PM, serguei.spitsyn at oracle.com wrote: >>>> Dan and Chris >>>> >>>> Could one of you, please, review the CSR for 8187289: >>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>> >>>> Bug is: >>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>>> >>>> Approved webrev: >>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>> >>>> >>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>>> does not need an update. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Nov 17 01:38:10 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 17:38:10 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <8d1f39e2-3227-c167-2727-578922505b3e@oracle.com> References: <7f36328d-ef73-1f0b-d89a-4522b4ff4eea@oracle.com> <8d1f39e2-3227-c167-2727-578922505b3e@oracle.com> Message-ID: <9d524bb8-f65e-326c-02a1-d68106012a1c@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Nov 17 01:51:26 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 11:51:26 +1000 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: > Dan and Chris > > Could one of you, please, review the CSR for 8187289: > https://bugs-stage.openjdk.java.net/browse/JDK-8191098 > > Bug is: > https://bugs-stage.openjdk.java.net/browse/JDK-8187289 The links above should not be to bugs-stage! David > Approved webrev: > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ > > > This CSR covers a change in behavior, not in the JVMTI spec. > We decided that the JVMTI NotifyFramePop is intuitive enough and does > not need an update. > > Thanks, > Serguei > > > From david.holmes at oracle.com Fri Nov 17 01:53:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 11:53:30 +1000 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> The CSR needs to be created again from the real bug report. Everyone will need to re-review and re-add any necessary comments. David On 17/11/2017 11:51 AM, David Holmes wrote: > On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >> Dan and Chris >> >> Could one of you, please, review the CSR for 8187289: >> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >> >> Bug is: >> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 > > The links above should not be to bugs-stage! > > David > >> Approved webrev: >> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >> >> >> >> This CSR covers a change in behavior, not in the JVMTI spec. >> We decided that the JVMTI NotifyFramePop is intuitive enough and does >> not need an update. >> >> Thanks, >> Serguei >> >> >> From serguei.spitsyn at oracle.com Fri Nov 17 02:00:19 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 18:00:19 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> Message-ID: <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> Hi David, I've to leave now for a couple of hours. I've created the CSR from the real bug report, but don't know anything about the bugs-stage. A link "csr for" was auto-added when the CSR was created. Thanks, Serguei On 11/16/17 17:53, David Holmes wrote: > The CSR needs to be created again from the real bug report. Everyone > will need to re-review and re-add any necessary comments. > > David > > On 17/11/2017 11:51 AM, David Holmes wrote: >> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>> Dan and Chris >>> >>> Could one of you, please, review the CSR for 8187289: >>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>> >>> Bug is: >>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >> >> The links above should not be to bugs-stage! >> >> David >> >>> Approved webrev: >>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>> >>> >>> >>> This CSR covers a change in behavior, not in the JVMTI spec. >>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>> does not need an update. >>> >>> Thanks, >>> Serguei >>> >>> >>> From david.holmes at oracle.com Fri Nov 17 02:23:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 12:23:39 +1000 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> Message-ID: <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> On 17/11/2017 12:00 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > I've to leave now for a couple of hours. > I've created the CSR from the real bug report, but don't know anything > about the bugs-stage. > A link "csr for" was auto-added when the CSR was created. You must have done that while looking at the bug on bugs-stage. The real bug: https://bugs.openjdk.java.net/browse/JDK-8187289 has no CSR. David > Thanks, > Serguei > > > On 11/16/17 17:53, David Holmes wrote: >> The CSR needs to be created again from the real bug report. Everyone >> will need to re-review and re-add any necessary comments. >> >> David >> >> On 17/11/2017 11:51 AM, David Holmes wrote: >>> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>>> Dan and Chris >>>> >>>> Could one of you, please, review the CSR for 8187289: >>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>> >>>> Bug is: >>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>> >>> The links above should not be to bugs-stage! >>> >>> David >>> >>>> Approved webrev: >>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>> >>>> >>>> >>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>>> does not need an update. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> > From serguei.spitsyn at oracle.com Fri Nov 17 05:40:15 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 21:40:15 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> Message-ID: On 11/16/17 18:23, David Holmes wrote: > On 17/11/2017 12:00 PM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> I've to leave now for a couple of hours. >> I've created the CSR from the real bug report, but don't know >> anything about the bugs-stage. >> A link "csr for" was auto-added when the CSR was created. > > You must have done that while looking at the bug on bugs-stage. Most likely. But it is unclear how I've got there. :( > The real bug: > > https://bugs.openjdk.java.net/browse/JDK-8187289 Ok. I'll create the CSR once more. Thank you for catching this problem, David! Thanks, Serguei > has no CSR. > > David > >> Thanks, >> Serguei >> >> >> On 11/16/17 17:53, David Holmes wrote: >>> The CSR needs to be created again from the real bug report. Everyone >>> will need to re-review and re-add any necessary comments. >>> >>> David >>> >>> On 17/11/2017 11:51 AM, David Holmes wrote: >>>> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>>>> Dan and Chris >>>>> >>>>> Could one of you, please, review the CSR for 8187289: >>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>>> >>>>> Bug is: >>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>>> >>>> The links above should not be to bugs-stage! >>>> >>>> David >>>> >>>>> Approved webrev: >>>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>>> >>>>> >>>>> >>>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>>>> does not need an update. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >> From serguei.spitsyn at oracle.com Fri Nov 17 05:51:16 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 21:51:16 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> Message-ID: <90e7a20e-e6b3-19ca-68bc-64a82fe093a2@oracle.com> On 11/16/17 21:40, serguei.spitsyn at oracle.com wrote: > On 11/16/17 18:23, David Holmes wrote: >> On 17/11/2017 12:00 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> I've to leave now for a couple of hours. >>> I've created the CSR from the real bug report, but don't know >>> anything about the bugs-stage. >>> A link "csr for" was auto-added when the CSR was created. >> >> You must have done that while looking at the bug on bugs-stage. > > Most likely. > But it is unclear how I've got there. :( > > >> The real bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8187289 > > Ok. > I'll create the CSR once more. The CSR is: ? https://bugs.openjdk.java.net/browse/JDK-8191467 I've added Chris and Dan as reviewers and changed the state to "Proposed". Not sure, how it should switch to the "Pended" state. Thanks, Serguei > Thank you for catching this problem, David! > > Thanks, > Serguei > > >> has no CSR. >> >> David >> >>> Thanks, >>> Serguei >>> >>> >>> On 11/16/17 17:53, David Holmes wrote: >>>> The CSR needs to be created again from the real bug report. >>>> Everyone will need to re-review and re-add any necessary comments. >>>> >>>> David >>>> >>>> On 17/11/2017 11:51 AM, David Holmes wrote: >>>>> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Dan and Chris >>>>>> >>>>>> Could one of you, please, review the CSR for 8187289: >>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>>>> >>>>>> Bug is: >>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>>>> >>>>> The links above should not be to bugs-stage! >>>>> >>>>> David >>>>> >>>>>> Approved webrev: >>>>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>>>> >>>>>> >>>>>> >>>>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>>>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>>>>> does not need an update. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>> > From david.holmes at oracle.com Fri Nov 17 06:08:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 16:08:09 +1000 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <90e7a20e-e6b3-19ca-68bc-64a82fe093a2@oracle.com> References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> <90e7a20e-e6b3-19ca-68bc-64a82fe093a2@oracle.com> Message-ID: On 17/11/2017 3:51 PM, serguei.spitsyn at oracle.com wrote: > The CSR is: > ? https://bugs.openjdk.java.net/browse/JDK-8191467 > > I've added Chris and Dan as reviewers and changed the state to "Proposed". Did you intend to fast-track it? If so it should have been "Finalized" not "Proposed". > Not sure, how it should switch to the "Pended" state. That for CSR group use [1]: Pended: The chair or other CSR member has identified an issue with the proposal that needs to be addressed before the proposal can be approved. David [1] https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request > > Thanks, > Serguei > > >> Thank you for catching this problem, David! >> >> Thanks, >> Serguei >> >> >>> has no CSR. >>> >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 11/16/17 17:53, David Holmes wrote: >>>>> The CSR needs to be created again from the real bug report. >>>>> Everyone will need to re-review and re-add any necessary comments. >>>>> >>>>> David >>>>> >>>>> On 17/11/2017 11:51 AM, David Holmes wrote: >>>>>> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Dan and Chris >>>>>>> >>>>>>> Could one of you, please, review the CSR for 8187289: >>>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>>>>> >>>>>>> Bug is: >>>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>>>>> >>>>>> The links above should not be to bugs-stage! >>>>>> >>>>>> David >>>>>> >>>>>>> Approved webrev: >>>>>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>>>>> We decided that the JVMTI NotifyFramePop is intuitive enough and >>>>>>> does not need an update. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>> >> > From serguei.spitsyn at oracle.com Fri Nov 17 06:38:11 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Nov 2017 22:38:11 -0800 Subject: CSR review request for: 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: <10e6f61c-38fb-e5dc-d659-b1728efeafae@oracle.com> <27a193f1-5940-e197-015f-0930dcc798fc@oracle.com> <9f022ce5-9d6a-3e88-332e-5fce68e514d4@oracle.com> <90e7a20e-e6b3-19ca-68bc-64a82fe093a2@oracle.com> Message-ID: On 11/16/17 22:08, David Holmes wrote: > On 17/11/2017 3:51 PM, serguei.spitsyn at oracle.com wrote: >> The CSR is: >> ?? https://bugs.openjdk.java.net/browse/JDK-8191467 >> >> I've added Chris and Dan as reviewers and changed the state to >> "Proposed". > > Did you intend to fast-track it? If so it should have been "Finalized" > not "Proposed". It feels like this CSR is a good candidate for fast-tracking but I'm not completely sure. >> Not sure, how it should switch to the "Pended" state. > > That for CSR group use [1]: > > Pended: The chair or other CSR member has identified an issue with the > proposal that needs to be addressed before the proposal can be approved. > > David > > [1] https://wiki.openjdk.java.net/display/csr/Fields+of+a+CSR+Request Ok, thanks! Thanks, Serguei >> Thanks, >> Serguei >> >> >>> Thank you for catching this problem, David! >>> >>> Thanks, >>> Serguei >>> >>> >>>> has no CSR. >>>> >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 11/16/17 17:53, David Holmes wrote: >>>>>> The CSR needs to be created again from the real bug report. >>>>>> Everyone will need to re-review and re-add any necessary comments. >>>>>> >>>>>> David >>>>>> >>>>>> On 17/11/2017 11:51 AM, David Holmes wrote: >>>>>>> On 17/11/2017 10:25 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Dan and Chris >>>>>>>> >>>>>>>> Could one of you, please, review the CSR for 8187289: >>>>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8191098 >>>>>>>> >>>>>>>> Bug is: >>>>>>>> https://bugs-stage.openjdk.java.net/browse/JDK-8187289 >>>>>>> >>>>>>> The links above should not be to bugs-stage! >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Approved webrev: >>>>>>>> http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This CSR covers a change in behavior, not in the JVMTI spec. >>>>>>>> We decided that the JVMTI NotifyFramePop is intuitive enough >>>>>>>> and does not need an update. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>> >> From goetz.lindenmaier at sap.com Fri Nov 17 11:23:04 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Nov 2017 11:23:04 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help Message-ID: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> Hi, please review this change. I also filed a CSR for this: http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 See the webrev for a detailed description of the changes. If required, I'll make break-out changes to be reviewed separately. I had posted a RFR before, but improved the change to give a more complete overview of currently supported flags for the CSR: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html Best regards, Goetz. From jonathan.gibbons at oracle.com Fri Nov 17 18:29:52 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 17 Nov 2017 10:29:52 -0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> Message-ID: <5A0F2AA0.8020906@oracle.com> Goetz, I understand why you might want to ensure that a basic set of help options is supported, but I don't understand why that justifies removing older options, like "-help" for many tools. In addition, I notice the CSR says: > *Compatibility Risk Description:* > Only new flags are > added, none removed. But that is not true, since your edits for javac and javadoc remove the option completely. Also, in the CSR, look for these typos: serveral deperecation OpenJdk (should be OpenJDK) Also, I note that you've changed localized resource files. The usual procedure is to never touch those files, since they get updated later by Oracle's localization team. -- Jon On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote: > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > See the webrev for a detailed description of the changes. > > If required, I'll make break-out changes to be reviewed separately. > > I had posted a RFR before, but improved the change to > give a more complete overview of currently supported flags > for the CSR: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html > > Best regards, > Goetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.field at oracle.com Fri Nov 17 19:06:57 2017 From: robert.field at oracle.com (Robert Field) Date: Fri, 17 Nov 2017 11:06:57 -0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> Message-ID: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com> JShell changes ? The code change is fine. The help change in the properties file is not consistent with the other items, note: --help-extra, -X Print help on? so this should be: ?help, -h, -? Or, if there is a tool-wide standard, then the ?help-extra entry should be changed. The tests of ??help? should be updated to include the now documented ?-h? and ?-?? As Jon noted, the _ja and _zh_CN properties should not be touched. -Robert > On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz wrote: > > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > See the webrev for a detailed description of the changes. > > If required, I'll make break-out changes to be reviewed separately. > > I had posted a RFR before, but improved the change to > give a more complete overview of currently supported flags > for the CSR: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html > > Best regards, > Goetz. > From Alan.Bateman at oracle.com Sat Nov 18 08:41:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 18 Nov 2017 08:41:47 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> Message-ID: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com> On 17/11/2017 11:23, Lindenmaier, Goetz wrote: > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > See the webrev for a detailed description of the changes. > A question for Jon Gibbons: In JEP 293 the guideline is that tools should support `--help`. Do you think this should be expanded to include `-help`, and `-?` (and maybe `-h` where it make sense)? As regards the webrev then the changes to the localized resources can be dropped. As Jon noted, we don't usually edit these directly as they are bulk updated/replaced by translation drops that usually happen late in each release. It's not clear to me that it's wroth trying to update the JAXB, JAX-WS, and CORBA tools. One reason the corresponding tool modules are deprecated-for-removal and there is a draft JEP to remove them completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to change as they are owned by upstream projects on the Java EE github - any changes to the code in these modules needs to coordinated to avoid having a fork here. -Alan [1] http://openjdk.java.net/jeps/8189188 From weijun.wang at oracle.com Sun Nov 19 00:28:01 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 19 Nov 2017 08:28:01 +0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> Message-ID: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted. Is there a timetable to add "--" support to all tools? Thanks Max > On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz wrote: > > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > See the webrev for a detailed description of the changes. > > If required, I'll make break-out changes to be reviewed separately. > > I had posted a RFR before, but improved the change to > give a more complete overview of currently supported flags > for the CSR: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html > > Best regards, > Goetz. > From daniel.daugherty at oracle.com Sun Nov 19 01:49:43 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 18 Nov 2017 20:49:43 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> Message-ID: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Greetings, Testing of the last round of changes revealed a hang in one of the new TLH tests. Robbin has fixed the hang, updated the existing TLH test, and added another TLH test for good measure. Here is the updated full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ Here is the updated delta webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are no unexpected failures. We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: > Greetings, > > Robbin rebased the project last night/this morning to merge with Thread > Local Handshakes (TLH) and also picked up additional changesets up thru: > >> Changeset: fa736014cf28 >> Author:??? cjplummer >> Date:????? 2017-11-14 18:08 -0800 >> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >> >> 8191049: Add alternate version of pns() that is callable from within >> hotspot source >> Summary: added pns2() to debug.cpp >> Reviewed-by: stuefe, gthornbr > > This is the first time we've rebased the project to bits that are this > fresh (< 12 hours old at rebase time). We've done this because we think > we're done with this project and are in the final review-change-retest > cycle(s)... In other words, we're not planning on making any more major > changes for this project... :-) > > *** Time for code reviewers to chime in on this thread! *** > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ > > Here's is the delta webrev from the 2017.11.10 rebase: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ > > Dan has submitted the bits for the usual Mach5 tier[1-5] testing > (and the new baseline also)... > > We're expecting this round to be a little noisier than usual because > we did not rebase on a PIT snapshot so the new baseline has not been > through Jesper's usual care-and-feeding of integration_blockers, etc. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >> (Yes, we're playing chase-the-repo...) >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >> >> Unlike the previous rebase, there were no changes required to the >> open code to get the rebased bits to build so there is no delta >> webrev. >> >> These bits have been run through JPRT and I've submitted the usual >> Mach5 tier[1-5] test run... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>> >>> Here are the updated webrevs: >>> >>> Here's the mq comment for the change: >>> >>> ? Rebase to 2017.10.25 PIT snapshot. >>> >>> Here is the full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>> >>> And here is the delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>> >>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>> weekend. Didn't see any issues in a quick look. Going to take a closer >>> look today. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Resolving one of the code review comments (from both Stefan K and >>>> Coleen) >>>> on jdk10-04-full required quite a few changes so it is being done as a >>>> standalone patch and corresponding webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>> ??? JavaThreadIteratorWithHandle. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> We have a (eXtra Large) fix for the following bug: >>>>> >>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>> >>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>> >>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>> and track the work on this project: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>> >>>>> >>>>> Dan has noticed that the indenting is wrong in some of the code >>>>> quotes >>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>> solution for that problem yet. >>>>> >>>>> Here's the webrev for current JDK10 version of this fix: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>> >>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>> additional testing on Erik and Robbin's machines. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Daniel Daugherty >>>>> Erik Osterlund >>>>> Robbin Ehn >>>>> >>>> >>>> >>> >>> >> >> > > From yasuenag at gmail.com Sun Nov 19 13:37:14 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 19 Nov 2017 22:37:14 +0900 Subject: PING: RFR: 8185796: jstack and clhsdb jstack should show lock objects In-Reply-To: References: Message-ID: PING: Could you review it? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ I want to merge this change to jdk 10. So I need a reviewer and sponsor. Yasumasa On 2017/11/14 9:58, Yasumasa Suenaga wrote: > PING: > Could you review it? We need a reviewer and sponsor. > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ > > > Thanks, > > Yasumasa > > > 2017-11-09 23:34 GMT+09:00 Yasumasa Suenaga : >> Thanks, Jini! >> >> I'm waiting for Reviewer and sponsor. >> >> >> Yasumasa >> >> >> >> On 2017/11/09 23:25, Jini George wrote: >>> >>> Hi Yasumasa, >>> >>> This looks fine to me. >>> >>> Thank you, >>> Jini (Not a Reviewer). >>> >>> On 11/9/2017 6:55 PM, Yasumasa Suenaga wrote: >>>> >>>> Hi Jini, >>>> >>>> Thank you for your comment! >>>> I've fixed and uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.04/ >>>> >>>>> * >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>>>> >>>>> -> Lines 198-212: I feel this commented out code could be removed and >>>>> replaced by a call to printLockInfo(), though I am not entirely sure as >>>>> to when this printOn() gets exercised. >>>> >>>> >>>> I agree with you to remove these comments. >>>> They are insufficient to show all locks like a my first webrev [1]. >>>> webrev.04 is implemented to follow HotSpot implementation. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.00/ >>>> >>>> >>>> >>>> On 2017/11/09 2:19, Jini George wrote: >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> Your changes look good to me overall. Some nits: >>>>> >>>>> * >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/BasicType.java >>>>> (lines 138 to 152): >>>>> -> It would be nice if you could indent the "case" statements. >>>>> >>>>> * >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java >>>>> -> It would be good if the indentation here for the newly added lines >>>>> matches that of the rest of the file. (4 spaces instead of 2). >>>>> >>>>> * >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java >>>>> >>>>> -> Lines 198-212: I feel this commented out code could be removed and >>>>> replaced by a call to printLockInfo(), though I am not entirely sure as >>>>> to when this printOn() gets exercised. >>>>> >>>>> * test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java >>>>> -> You can remove these lines: >>>>> import java.util.Scanner; >>>>> import java.util.stream.Collectors; >>>>> import java.io.File; >>>>> >>>>> Thanks, >>>>> Jini (Not a Reviewer). >>>>> >>>>> >>>>> On 11/1/2017 6:28 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> PING: Could you review and sponsor it? >>>>>> >>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2017/10/09 23:19, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I uploaded new webrev to be adapted to current jdk10/hs: >>>>>>> >>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.03/ >>>>>>> >>>>>>> >>>>>>> Please review and sponsor it. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2017/09/27 0:31, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I uploaded new webrev to be adapted to jdk10/hs: >>>>>>>> >>>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.02/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/08/24 22:59, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> Thanks Jini! >>>>>>>>> >>>>>>>>> I uploaded new webrev: >>>>>>>>> >>>>>>>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8185796/webrev.01/ >>>>>>>>> >>>>>>>>> This webrev has been ported print_lock_info() to JavaVFrame.java, >>>>>>>>> and I've added new testcase for `jhsdb jstack` and jstack command on >>>>>>>>> `jhsdb clhsdb`. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017/08/24 18:01, Jini George wrote: >>>>>>>>>> >>>>>>>>>> Apologize for the late reply, Yasumasa. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I think so, but I guess it is difficult. >>>>>>>>>>> For example, test for CLHSDB command is provided as >>>>>>>>>>> test/serviceability/sa/TestPrintMdo.java . >>>>>>>>>>> But target process seems to be fixed to "LingeredApp". >>>>>>>>>>> Can we change it to another program which generates lock >>>>>>>>>>> contention? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You can take a look at any of the >>>>>>>>>> hotspot/test/serviceability/sa/LingeredAppWith*.java files for >>>>>>>>>> this. The target process does not have to be be fixed to >>>>>>>>>> LingeredApp -- in these LingeredAppWith* cases, the targets are >>>>>>>>>> test-specific variations built on top of LingeredApp for ease of >>>>>>>>>> implementation. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jini. From yasuenag at gmail.com Sun Nov 19 13:38:49 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 19 Nov 2017 22:38:49 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> Message-ID: <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> PING: Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ I want to merge this change to jdk 10. So I need a second reviewer. Yasumasa On 2017/11/16 21:09, Yasumasa Suenaga wrote: > Hi David, Serguei, > >>> The test logic is adding it in AttachFailedTestBase.java: >>> >>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>> ? 46???????????????????? .toAbsolutePath() >>> ? 47???????????????????? .toString(); > > Thanks! > I've fixed it in new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ > > > I've tested it as below. It works fine: > > $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed > $ echo $NATIVE_PATH > //images/test/hotspot/jtreg/native > > > Thanks, > > Yasumasa > > > On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote: >> On 11/15/17 23:29, David Holmes wrote: >>> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >>>> On 11/15/17 18:11, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>> >>>>> There should not be any "/lib/" in that path >>>> >>>> Right, it should not be. >>> >>> The test logic is adding it in AttachFailedTestBase.java: >>> >>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>> ? 46???????????????????? .toAbsolutePath() >>> ? 47???????????????????? .toString(); >>> >>> but it shouldn't. >> >> Nice catch! >> I looked right to these lines and overlooked it. :) >> >> Thanks, >> Serguei >> >>> >>> David >>> ----- >>> >>> >>>> This is the script I'm using to run the tests: >>>> >>>> #!/bin/sh >>>> >>>> REPO=/var/tmp/sspitsyn/jdk.attach >>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >>>> export JAVA_HOME=${IMAGES}/jdk >>>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >>>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >>>> echo "JAVA_HOME = $JAVA_HOME" >>>> >>>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg -nativepath:${NATIVE_PATH} \ >>>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>>> >>>> >>>> This is a part of log with the reported error from the AttachException.jtr: >>>> >>>> [TestNG] Running: >>>> ?? serviceability/dcmd/jvmti/AttachFailed/AttachException.java >>>> >>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>> Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 8689, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >>>> Command returned with exit code 0 >>>> ---------------- stdout ---------------- >>>> 8689: >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so was not loaded. >>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: cannot open shared object file: No such file or directory >>>> >>>> >>>> These are the locations of the libException.so: >>>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >>>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >>>> >>>> >>>> The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >>>> but pass with the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >>>> >>>> >>>> When the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >>>> the log has this line: >>>> >>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' through 'JMXExecutor' >>>> >>>> >>>> Apparently, the sub-directory name "/lib" is added to the path. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> David >>>>> >>>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa and David, >>>>>> >>>>>> >>>>>> On 11/15/17 04:56, David Holmes wrote: >>>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>>> Do the new tests pass in your runs? >>>>>>>> >>>>>>>> Of course. >>>>>>>> It seems not to exist jtreg native libraries. >>>>>>>> I've tested as below: >>>>>>>> >>>>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>>>> ?? $ cd test >>>>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>>>> >>>>>> Thanks. >>>>>> I missed to add the -nativepath flag, sorry. >>>>>> >>>>>>> Please check that: >>>>>>> >>>>>>> make test-image >>>>>>> >>>>>>> followed by jtreg -nativepath:/images/test/hotspot/jtreg/native >>>>>>> >>>>>>> also works. >>>>>> >>>>>> It fails with the error: >>>>>> >>>>>> ?? 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>>> ?? 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]' >>>>>> ?? 65 Command returned with exit code 0 >>>>>> ?? 66 ---------------- stdout ---------------- >>>>>> ?? 67 28407: >>>>>> ?? 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded. >>>>>> ?? 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory >>>>>> ?? 70 >>>>>> >>>>>> >>>>>> It seems, the '/lib' folder is added to the nativepath. >>>>>> >>>>>> Yasumasa, could you, double check it please? >>>>>> >>>>>> I'm using the jtreg: >>>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>>>> >>>>>> which is: >>>>>> >>>>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Do the new tests pass in your runs? >>>>>>>>> >>>>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>>>> >>>>>>>>> ??109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>>> ??110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>>>> ??111 Command returned with exit code 0 >>>>>>>>> ??112 ---------------- stdout ---------------- >>>>>>>>> ??113 21951: >>>>>>>>> ??114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. >>>>>>>>> ??115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>>> ??116 >>>>>>>>> >>>>>>>>> >>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> It looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>>>> >>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>> >>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>> >>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>>>> StartManagementAgent.java. >>>>>>>>>>> >>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>> Thanks! >>>>>>>>>>> I'm waiting for second reviewer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>>>> : >>>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The changes looks good. >>>>>>>>>>>>>> Thank you for making them! >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>>>>>>>> number: apa >>>>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>> >>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>> >>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>>>>>>>>>>>> Will need to check. >>>>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>>>> >>>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>>>>>>>> employee. >>>>>>>>>>>>> Can you run them with this change? >>>>>>>>>>>> >>>>>>>>>>>> Ok. >>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>> >>>>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>>>> ??? Would it better to defin a common base class with these methods? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >> From jonathan.gibbons at oracle.com Sun Nov 19 18:12:17 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 19 Nov 2017 10:12:17 -0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> Message-ID: <00717f78-f393-b406-da71-423c17acaf21@oracle.com> We are already in a hybrid world of old-style and new-style options :-( All the new module-related options added in JDK 9 are "new style", following the guidelines of JEP 293. It does not make sense to add "--" to some of the older tools, that may be going away at some point, and while we may be able to add the ability for other tools to accept "--" options, we have to be careful about removing support for existing options. -- Jon On 11/18/17 4:28 PM, Weijun Wang wrote: > I am OK with all commands supporting --help, but I am not sure if every tool should show it on the help screen if the tools's other options are still using the old single-"-" style. It looks like the tools are half-converted. > > Is there a timetable to add "--" support to all tools? > > Thanks > Max > >> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> please review this change. I also filed a CSR for this: >> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 >> >> See the webrev for a detailed description of the changes. >> >> If required, I'll make break-out changes to be reviewed separately. >> >> I had posted a RFR before, but improved the change to >> give a more complete overview of currently supported flags >> for the CSR: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html >> >> Best regards, >> Goetz. >> From david.holmes at oracle.com Sun Nov 19 21:41:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Nov 2017 07:41:19 +1000 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> References: <476c075a-38b5-cc36-9b7b-cdbb981e8d69@gmail.com> <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> Message-ID: Hi Yasumasa, I've been trying to leave these reviews to serviceability folk ... I've gone back through the original RFR from September last year to see what we did and what was left. The current proposal raises some concern for me - and IIRC Dmitry was also concerned about it last time: printing of the pending exception. If we print the pending exception we will report an error and throw AgentLoadException, even if execution of the OnAttach function returned JNI_OK. If that exception was not critical to the success of the loading the agent, and the agent was just sloppy about clearing it, then it will now fail to load - which would be a compatibility concern. Further, if the exception indicates an error and the OnAttach function returns JNI_ERR then we won't report that cleanly because the printing of the exception will prevent matching with "return code: -1". My own feeling is that it is up to the OnAttach function to properly deal with pending exceptions: report and/or clear them. The VM side just has to clear any pending exception to avoid it causing problems for later code. Some specific comments: HotSpotVirtualMachine.java The regex code seems overkill for the basic parsing you are doing. You just need to see if the strings starts with "return code: " and then parse the next bit as an integer to get the return code. --- test/jdk/com/sun/tools/attach/StartManagementAgent.java The reporting of NumberFormatException may be accurate in terms of the low-level exception, but "Invalid com.sun.management.jmxremote.port number" was much clearer. This makes me wonder about whether the code that previously produced "Invalid com.sun.management.jmxremote.port number" needs updating if this change proceeds. (And alao makes me wonder about the impact of the change in general.) --- Sorry - not the quick second review you were looking for. David ----- On 19/11/2017 11:38 PM, Yasumasa Suenaga wrote: > PING: > > Could you review it? > >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ > > I want to merge this change to jdk 10. So I need a second reviewer. > > > Yasumasa > > > > On 2017/11/16 21:09, Yasumasa Suenaga wrote: >> Hi David, Serguei, >> >>>> The test logic is adding it in AttachFailedTestBase.java: >>>> >>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), >>>> "lib", libname) >>>> ? 46???????????????????? .toAbsolutePath() >>>> ? 47???????????????????? .toString(); >> >> Thanks! >> I've fixed it in new webrev: >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ >> >> >> I've tested it as below. It works fine: >> >> $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH >> hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >> $ echo $NATIVE_PATH >> //images/test/hotspot/jtreg/native >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote: >>> On 11/15/17 23:29, David Holmes wrote: >>>> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 11/15/17 18:11, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> > >>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>>> >>>>>> >>>>>> There should not be any "/lib/" in that path >>>>> >>>>> Right, it should not be. >>>> >>>> The test logic is adding it in AttachFailedTestBase.java: >>>> >>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), >>>> "lib", libname) >>>> ? 46???????????????????? .toAbsolutePath() >>>> ? 47???????????????????? .toString(); >>>> >>>> but it shouldn't. >>> >>> Nice catch! >>> I looked right to these lines and overlooked it. :) >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> This is the script I'm using to run the tests: >>>>> >>>>> #!/bin/sh >>>>> >>>>> REPO=/var/tmp/sspitsyn/jdk.attach >>>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >>>>> export JAVA_HOME=${IMAGES}/jdk >>>>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >>>>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >>>>> echo "JAVA_HOME = $JAVA_HOME" >>>>> >>>>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg >>>>> -nativepath:${NATIVE_PATH} \ >>>>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>>>> >>>>> >>>>> This is a part of log with the reported error from the >>>>> AttachException.jtr: >>>>> >>>>> [TestNG] Running: >>>>> ?? serviceability/dcmd/jvmti/AttachFailed/AttachException.java >>>>> >>>>> Running DCMD 'JVMTI.agent_load >>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>> through 'PidJcmdExecutor' >>>>> Executing command >>>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>>> 8689, JVMTI.agent_load >>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >>>>> >>>>> Command returned with exit code 0 >>>>> ---------------- stdout ---------------- >>>>> 8689: >>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so >>>>> was not loaded. >>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: >>>>> cannot open shared object file: No such file or directory >>>>> >>>>> >>>>> These are the locations of the libException.so: >>>>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >>>>> >>>>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >>>>> >>>>> >>>>> >>>>> The tests fail with the >>>>> "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >>>>> but pass with the "export >>>>> NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >>>>> >>>>> >>>>> When the "export >>>>> NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >>>>> the log has this line: >>>>> >>>>> Running DCMD 'JVMTI.agent_load >>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' >>>>> through 'JMXExecutor' >>>>> >>>>> >>>>> Apparently, the sub-directory name "/lib" is added to the path. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> David >>>>>> >>>>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa and David, >>>>>>> >>>>>>> >>>>>>> On 11/15/17 04:56, David Holmes wrote: >>>>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>> >>>>>>>>> Of course. >>>>>>>>> It seems not to exist jtreg native libraries. >>>>>>>>> I've tested as below: >>>>>>>>> >>>>>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>>>>> ?? $ cd test >>>>>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet >>>>>>>>> -nativepath://support/test/hotspot/jtreg/native/lib >>>>>>>>> hotspot/jtreg/serviceability/attach >>>>>>>>> hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>>>>> >>>>>>> Thanks. >>>>>>> I missed to add the -nativepath flag, sorry. >>>>>>> >>>>>>>> Please check that: >>>>>>>> >>>>>>>> make test-image >>>>>>>> >>>>>>>> followed by jtreg >>>>>>>> -nativepath:/images/test/hotspot/jtreg/native >>>>>>>> >>>>>>>> also works. >>>>>>> >>>>>>> It fails with the error: >>>>>>> >>>>>>> ?? 63 Running DCMD 'JVMTI.agent_load >>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>>>> through 'PidJcmdExecutor' >>>>>>> ?? 64 Executing command >>>>>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>>>>> 28407, JVMTI.agent_load >>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg >>>>>>> /native/lib/libException.so]' >>>>>>> ?? 65 Command returned with exit code 0 >>>>>>> ?? 66 ---------------- stdout ---------------- >>>>>>> ?? 67 28407: >>>>>>> ?? 68 >>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so >>>>>>> was not loaded. >>>>>>> ?? 69 >>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: >>>>>>> cannot open shared object file: No such file or directory >>>>>>> ?? 70 >>>>>>> >>>>>>> >>>>>>> It seems, the '/lib' folder is added to the nativepath. >>>>>>> >>>>>>> Yasumasa, could you, double check it please? >>>>>>> >>>>>>> I'm using the jtreg: >>>>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>>>>> >>>>>>> which is: >>>>>>> >>>>>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>>>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 >>>>>>> /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>>> Good news is that the attach-related tests from closed >>>>>>>>>> repository are passed. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>>> >>>>>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>>>>> >>>>>>>>>> ??109 Running DCMD 'JVMTI.agent_load >>>>>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' >>>>>>>>>> through 'PidJcmdExecutor' >>>>>>>>>> ??110 Executing command >>>>>>>>>> '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, >>>>>>>>>> 21951, JVMTI.agent_load >>>>>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>>>>> >>>>>>>>>> ??111 Command returned with exit code 0 >>>>>>>>>> ??112 ---------------- stdout ---------------- >>>>>>>>>> ??113 21951: >>>>>>>>>> ??114 >>>>>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so >>>>>>>>>> was not loaded. >>>>>>>>>> ??115 >>>>>>>>>> /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: >>>>>>>>>> cannot open shared object file: No such file or directory >>>>>>>>>> ??116 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Good news is that the attach-related tests from closed >>>>>>>>>> repository are passed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> It looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>>>>> >>>>>>>>>>>>>>> I'd expect a check for some exception name, not for >>>>>>>>>>>>>>> details like: For >>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>> >>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>>>>> StartManagementAgent.java. >>>>>>>>>>>> >>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>> Thanks! >>>>>>>>>>>> I'm waiting for second reviewer. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>>>>> : >>>>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The changes looks good. >>>>>>>>>>>>>>> Thank you for making them! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>>>>> We can get the result as below when we run >>>>>>>>>>>>>>>> StartManagementAgent: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>> [runApplication] Error: Invalid >>>>>>>>>>>>>>>> com.sun.management.jmxremote.port >>>>>>>>>>>>>>>> number: apa >>>>>>>>>>>>>>>> [runApplication] >>>>>>>>>>>>>>>> jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd expect a check for some exception name, not for >>>>>>>>>>>>>>> details like: For >>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>> >>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>> >>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What tests did you run to make sure there are no >>>>>>>>>>>>>>>>> regressions? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 >>>>>>>>>>>>>>> testing levels. >>>>>>>>>>>>>>> Will need to check. >>>>>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not >>>>>>>>>>>>>> an Oracle >>>>>>>>>>>>>> employee. >>>>>>>>>>>>>> Can you run them with this change? >>>>>>>>>>>>> >>>>>>>>>>>>> Ok. >>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>>> >>>>>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: >>>>>>>>>>>>>>>>> \"apa\"")) { >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly >>>>>>>>>>>>>>>>> the same >>>>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>>>>> ??? Would it better to defin a common base class with >>>>>>>>>>>>>>>>> these methods? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What tests did you run to make sure there are no >>>>>>>>>>>>>>>>> regressions? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via >>>>>>>>>>>>>>>>>>> JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it >>>>>>>>>>>>>>>>>>> implies error >>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not >>>>>>>>>>>>>>>>>>> receive any output >>>>>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error >>>>>>>>>>>>>>>>>>> message to users to >>>>>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as >>>>>>>>>>>>>>>>>>> following jtreg >>>>>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>> From david.holmes at oracle.com Mon Nov 20 05:51:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Nov 2017 15:51:06 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> Hi Dan, Figured I'd better cast an eye over this again before it gets pushed :) Only one thing (repeated many times) jumped out at me and apologies if this has already been debated back and forth. I missed the exchange where the for loop iteration was rewritten into this unusual form: for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = jtiwh.next(); ) { On first reading I expect most people would mistake the control expression for the iteration-expression due to the next(). I didn't even know the control expression could introduce a local variable! I find this really hard to read stylistically and far too cute/clever for its own good. It also violates the style rules regarding implicit boolean checks. I know Stefan proposed this as he did not like the alternate (in a few places): + { + ThreadsListHandle tlh; + JavaThreadIterator jti(tlh.list()); + for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { ... + } but it seems to me the iterator code has evolved since then and only a couple of places need a distinct TLH separate from the actual iterator object. So I'm more in favour of the more classic for-loop, with the iterator declared before the loop. Or even convert to while loops, as this iterator seems more suited to that. Other than that just a couple of comments on variable type choices, and a few typos spotted below. Thanks, David --- src/hotspot/share/runtime/globals.hpp 2476 diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, \ 2477 "Enable Thread SMR extra validity checks") \ 2478 \ 2479 diagnostic(bool, EnableThreadSMRStatistics, true, \ 2480 "Enable Thread SMR Statistics") \ Indent of strings is off by 3 spaces. --- src/hotspot/share/runtime/handshake.cpp 140 // There is assumption in code that Threads_lock should be lock 200 // There is assumption in code that Threads_lock should be lock lock -> locked 146 // handshake_process_by_vmthread will check the semaphore for us again Needs period at end. 148 // should be okey since the new thread will not have an operation. okey -> okay 151 // We can't warn here is since the thread do cancel_handshake after it have been removed I think: // We can't warn here since the thread does cancel_handshake after it has been removed 152 // from ThreadsList. So we should just keep looping here until while below return negative. from -> from the Needs period at end. 204 // A new thread on the ThreadsList will not have an operation. Change period to comma, and ... 205 // Hence is skipped in handshake_process_by_vmthread. Hence is -> hence it is --- src/hotspot/share/runtime/thread.cpp 1482 // dcubed - Looks like the Threads_lock is for stable access 1483 // to _jvmci_old_thread_counters and _jvmci_counters. Does this comment need revisiting? 3451 volatile jint ... Why are you using jint for field types here? (Surprised Coleen hasn't spotted them! ;-) ). 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; 3457 long Threads::_smr_java_thread_list_free_cnt = 0; long? If you really want 64-bit counters here you won't get them on Windows with that declaration. If you really want variable sized counters I suggest uintptr_t; otherwise uint64_t. ---- On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: > Greetings, > > Testing of the last round of changes revealed a hang in one of the new > TLH tests. Robbin has fixed the hang, updated the existing TLH test, and > added another TLH test for good measure. > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ > > Here is the updated delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ > > Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are > no unexpected failures. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Robbin rebased the project last night/this morning to merge with Thread >> Local Handshakes (TLH) and also picked up additional changesets up thru: >> >>> Changeset: fa736014cf28 >>> Author:??? cjplummer >>> Date:????? 2017-11-14 18:08 -0800 >>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>> >>> 8191049: Add alternate version of pns() that is callable from within >>> hotspot source >>> Summary: added pns2() to debug.cpp >>> Reviewed-by: stuefe, gthornbr >> >> This is the first time we've rebased the project to bits that are this >> fresh (< 12 hours old at rebase time). We've done this because we think >> we're done with this project and are in the final review-change-retest >> cycle(s)... In other words, we're not planning on making any more major >> changes for this project... :-) >> >> *** Time for code reviewers to chime in on this thread! *** >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >> >> Here's is the delta webrev from the 2017.11.10 rebase: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >> (and the new baseline also)... >> >> We're expecting this round to be a little noisier than usual because >> we did not rebase on a PIT snapshot so the new baseline has not been >> through Jesper's usual care-and-feeding of integration_blockers, etc. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>> (Yes, we're playing chase-the-repo...) >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>> >>> Unlike the previous rebase, there were no changes required to the >>> open code to get the rebased bits to build so there is no delta >>> webrev. >>> >>> These bits have been run through JPRT and I've submitted the usual >>> Mach5 tier[1-5] test run... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>> >>>> Here are the updated webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? Rebase to 2017.10.25 PIT snapshot. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>> >>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>> look today. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Resolving one of the code review comments (from both Stefan K and >>>>> Coleen) >>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>> standalone patch and corresponding webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>> ??? JavaThreadIteratorWithHandle. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> We have a (eXtra Large) fix for the following bug: >>>>>> >>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>> >>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>> >>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>> and track the work on this project: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>> >>>>>> >>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>> quotes >>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>> solution for that problem yet. >>>>>> >>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>> >>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>> additional testing on Erik and Robbin's machines. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Daniel Daugherty >>>>>> Erik Osterlund >>>>>> Robbin Ehn >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From yasuenag at gmail.com Mon Nov 20 07:54:28 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 20 Nov 2017 16:54:28 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> Message-ID: <8749717a-f6d1-62c9-a2cc-427304ea5f35@gmail.com> Hi David, > My own feeling is that it is up to the OnAttach function to properly deal with pending exceptions: report and/or clear them. The VM side just has to clear any pending exception to avoid it causing problems for later code. I removed the change to print pending exceptions in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.04/ > test/jdk/com/sun/tools/attach/StartManagementAgent.java > > The reporting of NumberFormatException may be accurate in terms of the low-level exception, but "Invalid com.sun.management.jmxremote.port number" was much clearer. This makes me wonder about whether the code that previously produced "Invalid com.sun.management.jmxremote.port number" needs updating if this change proceeds. (And alao makes me wonder about the impact of the change in general.) I tested StartManagementAgent.java without this change, and I got failure as below: -------------- JavaTest Message: Test threw exception: com.sun.tools.attach.AttachOperationFailedE xception: java.lang.RuntimeException: jdk.internal.agent.AgentConfigurationError: j ava.lang.NumberFormatException: For input string: "apa" JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: com.sun.tools.attach.AttachOperationFailedExc eption: java.lang.RuntimeException: jdk.internal.agent.AgentConfigurationError: jav a.lang.NumberFormatException: For input string: "apa" -------------- Should we change this testcase whatever this change is not accepted? Thanks, Yasumasa On 2017/11/20 6:41, David Holmes wrote: > Hi Yasumasa, > > I've been trying to leave these reviews to serviceability folk ... > > I've gone back through the original RFR from September last year to see what we did and what was left. > > The current proposal raises some concern for me - and IIRC Dmitry was also concerned about it last time: printing of the pending exception. If we print the pending exception we will report an error and throw AgentLoadException, even if execution of the OnAttach function returned JNI_OK. If that exception was not critical to the success of the loading the agent, and the agent was just sloppy about clearing it, then it will now fail to load - which would be a compatibility concern. > > Further, if the exception indicates an error and the OnAttach function returns JNI_ERR then we won't report that cleanly because the printing of the exception will prevent matching with "return code: -1". > > My own feeling is that it is up to the OnAttach function to properly deal with pending exceptions: report and/or clear them. The VM side just has to clear any pending exception to avoid it causing problems for later code. > > Some specific comments: > > HotSpotVirtualMachine.java > > The regex code seems overkill for the basic parsing you are doing. You just need to see if the strings starts with "return code: " and then parse the next bit as an integer to get the return code. > > --- > > ?test/jdk/com/sun/tools/attach/StartManagementAgent.java > > The reporting of NumberFormatException may be accurate in terms of the low-level exception, but "Invalid com.sun.management.jmxremote.port number" was much clearer. This makes me wonder about whether the code that previously produced "Invalid com.sun.management.jmxremote.port number" needs updating if this change proceeds. (And alao makes me wonder about the impact of the change in general.) > > --- > > Sorry - not the quick second review you were looking for. > > David > ----- > > On 19/11/2017 11:38 PM, Yasumasa Suenaga wrote: >> PING: >> >> Could you review it? >> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ >> >> I want to merge this change to jdk 10. So I need a second reviewer. >> >> >> Yasumasa >> >> >> >> On 2017/11/16 21:09, Yasumasa Suenaga wrote: >>> Hi David, Serguei, >>> >>>>> The test logic is adding it in AttachFailedTestBase.java: >>>>> >>>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>>>> ? 46???????????????????? .toAbsolutePath() >>>>> ? 47???????????????????? .toString(); >>> >>> Thanks! >>> I've fixed it in new webrev: >>> >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ >>> >>> >>> I've tested it as below. It works fine: >>> >>> $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>> $ echo $NATIVE_PATH >>> //images/test/hotspot/jtreg/native >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote: >>>> On 11/15/17 23:29, David Holmes wrote: >>>>> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 11/15/17 18:11, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>>>> >>>>>>> There should not be any "/lib/" in that path >>>>>> >>>>>> Right, it should not be. >>>>> >>>>> The test logic is adding it in AttachFailedTestBase.java: >>>>> >>>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>>>> ? 46???????????????????? .toAbsolutePath() >>>>> ? 47???????????????????? .toString(); >>>>> >>>>> but it shouldn't. >>>> >>>> Nice catch! >>>> I looked right to these lines and overlooked it. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> This is the script I'm using to run the tests: >>>>>> >>>>>> #!/bin/sh >>>>>> >>>>>> REPO=/var/tmp/sspitsyn/jdk.attach >>>>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >>>>>> export JAVA_HOME=${IMAGES}/jdk >>>>>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >>>>>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >>>>>> echo "JAVA_HOME = $JAVA_HOME" >>>>>> >>>>>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg -nativepath:${NATIVE_PATH} \ >>>>>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>>>>> >>>>>> >>>>>> This is a part of log with the reported error from the AttachException.jtr: >>>>>> >>>>>> [TestNG] Running: >>>>>> ?? serviceability/dcmd/jvmti/AttachFailed/AttachException.java >>>>>> >>>>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>>> Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 8689, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >>>>>> Command returned with exit code 0 >>>>>> ---------------- stdout ---------------- >>>>>> 8689: >>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so was not loaded. >>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: cannot open shared object file: No such file or directory >>>>>> >>>>>> >>>>>> These are the locations of the libException.so: >>>>>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >>>>>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >>>>>> >>>>>> >>>>>> The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >>>>>> but pass with the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >>>>>> >>>>>> >>>>>> When the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >>>>>> the log has this line: >>>>>> >>>>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' through 'JMXExecutor' >>>>>> >>>>>> >>>>>> Apparently, the sub-directory name "/lib" is added to the path. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa and David, >>>>>>>> >>>>>>>> >>>>>>>> On 11/15/17 04:56, David Holmes wrote: >>>>>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>>> >>>>>>>>>> Of course. >>>>>>>>>> It seems not to exist jtreg native libraries. >>>>>>>>>> I've tested as below: >>>>>>>>>> >>>>>>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>>>>>> ?? $ cd test >>>>>>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>>>>>> >>>>>>>> Thanks. >>>>>>>> I missed to add the -nativepath flag, sorry. >>>>>>>> >>>>>>>>> Please check that: >>>>>>>>> >>>>>>>>> make test-image >>>>>>>>> >>>>>>>>> followed by jtreg -nativepath:/images/test/hotspot/jtreg/native >>>>>>>>> >>>>>>>>> also works. >>>>>>>> >>>>>>>> It fails with the error: >>>>>>>> >>>>>>>> ?? 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>> ?? 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]' >>>>>>>> ?? 65 Command returned with exit code 0 >>>>>>>> ?? 66 ---------------- stdout ---------------- >>>>>>>> ?? 67 28407: >>>>>>>> ?? 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded. >>>>>>>> ?? 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>> ?? 70 >>>>>>>> >>>>>>>> >>>>>>>> It seems, the '/lib' folder is added to the nativepath. >>>>>>>> >>>>>>>> Yasumasa, could you, double check it please? >>>>>>>> >>>>>>>> I'm using the jtreg: >>>>>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>>>>>> >>>>>>>> which is: >>>>>>>> >>>>>>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>>>>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>>>> >>>>>>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>>>>>> >>>>>>>>>>> ??109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>>>>> ??110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>>>>>> ??111 Command returned with exit code 0 >>>>>>>>>>> ??112 ---------------- stdout ---------------- >>>>>>>>>>> ??113 21951: >>>>>>>>>>> ??114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. >>>>>>>>>>> ??115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>>>>> ??116 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> It looks good to me. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>>>>>> StartManagementAgent.java. >>>>>>>>>>>>> >>>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> I'm waiting for second reviewer. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>>>>>> : >>>>>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The changes looks good. >>>>>>>>>>>>>>>> Thank you for making them! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>>>>>>>>>> number: apa >>>>>>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>>>>>>>>>>>>>> Will need to check. >>>>>>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>>>>>>>>>> employee. >>>>>>>>>>>>>>> Can you run them with this change? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>>>>>> ??? Would it better to defin a common base class with these methods? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>> From sharath.ballal at oracle.com Mon Nov 20 09:24:08 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 20 Nov 2017 01:24:08 -0800 (PST) Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler Message-ID: Hello, Pls review changes for the following issue: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin.westberg at oracle.com Mon Nov 20 09:48:15 2017 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 20 Nov 2017 10:48:15 +0100 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: Hi Dan, Overall I must say this looks very nice, can?t wait to use it! (Also a disclaimer: not a reviewer, and have not looked at the gc or jmvti specific changes nor the tests (yet)). Didn?t spot any real issues, just a few small efficiency related things: src/hotspot/share/runtime/biasedLocking.cpp 217 for (JavaThread* cur_thread = Threads::first(); cur_thread != NULL; cur_thread = cur_thread->next()) { 218 if (cur_thread == biased_thread) { 219 thread_is_alive = true; This loop could be replaced with: ThreadsListHandle tlh; thread_is_alive = tlh.includes(biased_thread); src/hotspot/share/runtime/memprofiler.cpp 55-56 grabs the Threads_lock, shouldn?t be needed anymore. src/hotspot/share/runtime/thread.inline.hpp 198 TerminatedTypes l_terminated = (TerminatedTypes) 199 OrderAccess::load_acquire((volatile jint *) &_terminated); 200 return check_is_terminated(_terminated); The variable used in the return statement was intended to be l_terminated I guess? The following are more minor suggestions / comments: src/hotspot/share/runtime/thread.cpp 3432 // operations over all threads. It is protected by its own Mutex 3433 // lock, which is also used in other contexts to protect thread Should this comment perhaps be revised to mention SMR? 4745 hash_table_size--; 4746 hash_table_size |= hash_table_size >> 1; ... This calculation is repeated around line 4922 as well, perhaps put it in a function? 4828 // If someone set a handshake on us just as we entered exit path, we simple cancel it. Perhaps something like ?.. entered the exit path, we simply cancel it.? src/hotspot/share/runtime/thread.hpp 1179 bool on_thread_list() { return _on_thread_list; } 1180 void set_on_thread_list() { _on_thread_list = true; } 1181 1182 // thread has called JavaThread::exit() or is terminated 1183 bool is_exiting() const; 1184 // thread is terminated (no longer on the threads list); we compare 1185 // against the two non-terminated values so that a freed JavaThread 1186 // will also be considered terminated. 1187 bool check_is_terminated(TerminatedTypes l_terminated) const { 1188 return l_terminated != _not_terminated && l_terminated != _thread_exiting; 1189 } 1190 bool is_terminated(); Use of const is inconsistent here, it?s added to 1183, should it perhaps be added to 1179 and 1190 as well then? src/hotspot/share/runtime/vm_operations.hpp 406 DeadlockCycle* result() { return _deadlocks; }; 407 VMOp_Type type() const { return VMOp_FindDeadlocks; } Whitespace only change that seems spurious. Best regards, Robin > On 19 Nov 2017, at 02:49, Daniel D. Daugherty wrote: > > Greetings, > > Testing of the last round of changes revealed a hang in one of the new > TLH tests. Robbin has fixed the hang, updated the existing TLH test, and > added another TLH test for good measure. > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ > > Here is the updated delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ > > Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are > no unexpected failures. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Robbin rebased the project last night/this morning to merge with Thread >> Local Handshakes (TLH) and also picked up additional changesets up thru: >> >>> Changeset: fa736014cf28 >>> Author: cjplummer >>> Date: 2017-11-14 18:08 -0800 >>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>> >>> 8191049: Add alternate version of pns() that is callable from within hotspot source >>> Summary: added pns2() to debug.cpp >>> Reviewed-by: stuefe, gthornbr >> >> This is the first time we've rebased the project to bits that are this >> fresh (< 12 hours old at rebase time). We've done this because we think >> we're done with this project and are in the final review-change-retest >> cycle(s)... In other words, we're not planning on making any more major >> changes for this project... :-) >> >> *** Time for code reviewers to chime in on this thread! *** >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >> >> Here's is the delta webrev from the 2017.11.10 rebase: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >> (and the new baseline also)... >> >> We're expecting this round to be a little noisier than usual because >> we did not rebase on a PIT snapshot so the new baseline has not been >> through Jesper's usual care-and-feeding of integration_blockers, etc. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>> (Yes, we're playing chase-the-repo...) >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>> >>> Unlike the previous rebase, there were no changes required to the >>> open code to get the rebased bits to build so there is no delta >>> webrev. >>> >>> These bits have been run through JPRT and I've submitted the usual >>> Mach5 tier[1-5] test run... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>> >>>> Here are the updated webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> Rebase to 2017.10.25 PIT snapshot. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>> >>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>> look today. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Resolving one of the code review comments (from both Stefan K and Coleen) >>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>> standalone patch and corresponding webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>> JavaThreadIteratorWithHandle. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> We have a (eXtra Large) fix for the following bug: >>>>>> >>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>> >>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>> >>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>> and track the work on this project: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>> >>>>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>> solution for that problem yet. >>>>>> >>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>> >>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>> additional testing on Erik and Robbin's machines. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Daniel Daugherty >>>>>> Erik Osterlund >>>>>> Robbin Ehn >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From goetz.lindenmaier at sap.com Mon Nov 20 11:21:57 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Nov 2017 11:21:57 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <5A0F2AA0.8020906@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <5A0F2AA0.8020906@oracle.com> Message-ID: <367811cf4e0248298c9125f5bdece730@sap.com> Hi Jon, thanks for your feedback. Sorry for getting the javac/Javadoc wrong, I missed that. The point is that the option implementation there does not have the possibility to accept an option but not document it. javac: I'd like to propose to add -help again. javac else prints: javac: invalid flag: -help Usage: javac use --help for a list of possible options Which isn't that nice. Javadoc: I'd prefer to remove -help because then it's not documented which is more streamlined with the overall idea of this change. And Javadoc behaves "friendly": Javadoc -help prints the usage but exits with return code '1'. I don't think that's a major problem. I'll update the CSR accordingly once we decide on this. I'm happy not to edit the properties files :) I'll revert that. (Although I would have liked to edit some of the German translations.) I fixed the typos in the CSR. Best regards, Goetz Change to javac: --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java Tue Oct 10 14:39:45 2017 +0200 +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java Mon Nov 20 12:19:49 2017 +0100 @@ -360,7 +360,7 @@ }, // Note: -h is already taken for "native header output directory". - HELP("-? --help", "opt.help", STANDARD, INFO) { + HELP("-? --help -help", "opt.help", STANDARD, INFO) { @Override public void process(OptionHelper helper, String option) throws InvalidValueException { Log log = helper.getLog(); > -----Original Message----- > From: Jonathan Gibbons [mailto:jonathan.gibbons at oracle.com] > Sent: Freitag, 17. November 2017 19:30 > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > Goetz, > > I understand why you might want to ensure that a basic set of help options is > supported, > but I don't understand why that justifies removing older options, like "-help" > for many tools. > > In addition, I notice the CSR says: > > > > Compatibility Risk Description: > Only new flags are > added, none removed. > > > > But that is not true, since your edits for javac and javadoc remove the option > completely. > > Also, in the CSR, look for these typos: > serveral > deperecation > OpenJdk (should be OpenJDK) > > > Also, I note that you've changed localized resource files. The usual procedure > is to never > touch those files, since they get updated later by Oracle's localization team. > > -- Jon > > > On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote: > > > Hi, > > please review this change. I also filed a CSR for this: > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > See the webrev for a detailed description of the changes. > > If required, I'll make break-out changes to be reviewed separately. > > I had posted a RFR before, but improved the change to > give a more complete overview of currently supported flags > for the CSR: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- > October/028615.html > > Best regards, > Goetz. > > From david.holmes at oracle.com Mon Nov 20 11:32:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Nov 2017 21:32:22 +1000 Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: References: Message-ID: <1e21429e-69bd-e9e3-7890-b857be80a3a8@oracle.com> Hi Sharath, Looks okay. Thanks, David On 20/11/2017 7:24 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 > > Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ > > Thanks, > > Sharath > From goetz.lindenmaier at sap.com Mon Nov 20 11:57:11 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Nov 2017 11:57:11 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <6C0CD3C8-D6DD-4A37-97DE-F4EF2E1A2D7A@oracle.com> Message-ID: <5c565f49102c4d79b44d514a0227eb16@sap.com> Hi Robert, thanks for looking at my change. I'm fine with listing the flags in a different order, but it's ambiguous. Java itslef lists "-? -h --help" therefore I chose this for most of the tools, too. But just tell me how to put it. Below, I list all the option help messages for the tools on linux. --help-extra is quite consistent. Best regards, Goetz. --help-extra, -X Print help on extra options --help-extra, -X --help-extra, -X Print help on non-standard options and exit -X print help on extra options to the output stream --help-extra print help on extra options to the output stream --help-extra Print help on extra options --help-extra Give help on extra options -? -h --help display this help message -? -h --help display this help message -h, --help (Print this help message.) -?, --help Print this help message -? -h --help Print this help message --help, -h, -? Display command line options and exit -? -h --help Print this help message -h -? --help Print this help message -? -h --help -? -h --help : display this help message and exit -? -h --help : display this help message and exit -? -h --help print this help message and exit -? | -h | --help to print this help message jmap -? -h --help to print this help message usage: jps [-? -h --help] -? -h --help to print this help message -? -h --help Prints this help message. -? -h --help print this help message -? -h --help Print this synopsis of standard options and exit Use "keytool -? -h or --help" for all available commands --help print this help message to the output stream -?, -h, --help Print this help message -h, --help, -? Print this help message -?, -h, --help Print this help message -? -h --help Print this help message and exit -?, -h, --help print this help message -?, -h, --help print this help message -? -h --help Print this help message -?, -h, --help[:compat] Give this, or optionally the compatibility, help [-? -h --help] Print this help message jstatd -?|-h|--help > -----Original Message----- > From: Robert Field [mailto:robert.field at oracle.com] > Sent: Freitag, 17. November 2017 20:07 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > serviceability-dev (serviceability-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > JShell changes ? > > The code change is fine. > > The help change in the properties file is not consistent with the other items, > note: --help-extra, -X Print help on? > so this should be: ?help, -h, -? > Or, if there is a tool-wide standard, then the ?help-extra entry should be > changed. > > The tests of ??help? should be updated to include the now documented ?- > h? and ?-?? > > As Jon noted, the _ja and _zh_CN properties should not be touched. > > -Robert > > > On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > please review this change. I also filed a CSR for this: > > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > > > See the webrev for a detailed description of the changes. > > > > If required, I'll make break-out changes to be reviewed separately. > > > > I had posted a RFR before, but improved the change to > > give a more complete overview of currently supported flags > > for the CSR: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- > October/028615.html > > > > Best regards, > > Goetz. > > From goetz.lindenmaier at sap.com Mon Nov 20 13:41:33 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Nov 2017 13:41:33 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com> Message-ID: Hi Alan, thanks for looking at my change. Thanks for pointing to JEP 293. I see my change mostly follows its ideas. As Jon, I don't think asking for support of -help makes sense as it's not according to the gnu style, and it's not that hard to get it right anyways. I'll remove the edits to the properties files. The deprecated tools are orbd, wsgen wsimport schemagen Is that correct? I'll remove them from my change. The test has a list of tools not to test, I'll add them there. Best regards, Goetz. > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Samstag, 18. November 2017 09:42 > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net; 'compiler-dev at openjdk.java.net' dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > On 17/11/2017 11:23, Lindenmaier, Goetz wrote: > > Hi, > > > > please review this change. I also filed a CSR for this: > > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > > > See the webrev for a detailed description of the changes. > > > A question for Jon Gibbons: In JEP 293 the guideline is that tools > should support `--help`. Do you think this should be expanded to include > `-help`, and `-?` (and maybe `-h` where it make sense)? > > As regards the webrev then the changes to the localized resources can be > dropped. As Jon noted, we don't usually edit these directly as they are > bulk updated/replaced by translation drops that usually happen late in > each release. > > It's not clear to me that it's wroth trying to update the JAXB, JAX-WS, > and CORBA tools. One reason the corresponding tool modules are > deprecated-for-removal and there is a draft JEP to remove them > completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to > change as they are owned by upstream projects on the Java EE github - > any changes to the code in these modules needs to coordinated to avoid > having a fork here. > > -Alan > > [1] http://openjdk.java.net/jeps/8189188 From goetz.lindenmaier at sap.com Mon Nov 20 13:46:49 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Nov 2017 13:46:49 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> Message-ID: Hi Max, I think there are so many tools mixing both kinds of options, that it's rather a gain if all at least document the same, up to date help message, than if the documentation is skipped for some. After my change, all the help messages are quite similar. I updated them to use the same wording while trying to keep the sentence structure in accordance with the other documented flags, see below. Best regards, Goetz. -? -h --help display this help message -? -h --help display this help message -h, --help (Print this help message.) -?, --help Print this help message -? -h --help Print this help message --help, -h, -? Display command line options and exit -? -h --help Print this help message -h -? --help Print this help message -? -h --help -? -h --help : display this help message and exit -? -h --help : display this help message and exit -? -h --help print this help message and exit -? | -h | --help to print this help message jmap -? -h --help to print this help message usage: jps [-? -h --help] -? -h --help to print this help message -? -h --help Prints this help message. -? -h --help print this help message -? -h --help Print this synopsis of standard options and exit Use "keytool -? -h or --help" for all available commands --help print this help message to the output stream -?, -h, --help Print this help message -h, --help, -? Print this help message -?, -h, --help Print this help message -? -h --help Print this help message and exit -?, -h, --help print this help message -?, -h, --help print this help message -? -h --help Print this help message -?, -h, --help[:compat] Give this, or optionally the compatibility, help [-? -h --help] Print this help message jstatd -?|-h|--help > -----Original Message----- > From: Weijun Wang [mailto:weijun.wang at oracle.com] > Sent: Sonntag, 19. November 2017 01:28 > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > serviceability-dev (serviceability-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > I am OK with all commands supporting --help, but I am not sure if every tool > should show it on the help screen if the tools's other options are still using > the old single-"-" style. It looks like the tools are half-converted. > > Is there a timetable to add "--" support to all tools? > > Thanks > Max > > > On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > please review this change. I also filed a CSR for this: > > http://cr.openjdk.java.net/~goetz/wr17/8189102- > helpMessage/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > > > > See the webrev for a detailed description of the changes. > > > > If required, I'll make break-out changes to be reviewed separately. > > > > I had posted a RFR before, but improved the change to > > give a more complete overview of currently supported flags > > for the CSR: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- > October/028615.html > > > > Best regards, > > Goetz. > > From Alan.Bateman at oracle.com Mon Nov 20 14:05:57 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Nov 2017 14:05:57 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <71c9130c-a8b6-c811-b14f-564b6f38574e@oracle.com> Message-ID: <191cb8f3-8c15-d98f-0650-516c1f5a51b6@oracle.com> On 20/11/2017 13:41, Lindenmaier, Goetz wrote: > : > > The deprecated tools are > orbd, > wsgen > wsimport > schemagen > Is that correct? > Yes, plus xjc, idlj, servertool and tnameserv (the full list is in the draft JEP that I linked to). -Alan From weijun.wang at oracle.com Mon Nov 20 14:48:37 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 20 Nov 2017 22:48:37 +0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> Message-ID: Hi Goetz I understand your intention. If the reason is that one day every tool will switch to this new style, please at least do not include kinit, klist and ktab. These Windows-only commands are meant to emulate MIT krb5 tools with the same names and we need to keep the option (and maybe the help screen) as similar as possible. I am OK with supporting the --help option undocumented. Thanks Max > On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz wrote: > > Hi Max, > > I think there are so many tools mixing both kinds of > options, that it's rather a gain if all at least document > the same, up to date help message, than if the documentation > is skipped for some. > > After my change, all the help messages are quite similar. > I updated them to use the same wording while trying to > keep the sentence structure in accordance with the other > documented flags, see below. > > Best regards, > Goetz. > > > > -? -h --help display this help message > -? -h --help display this help message > -h, --help (Print this help message.) > -?, --help Print this help message > -? -h --help Print this help message > --help, -h, -? Display command line options and exit > -? -h --help Print this help message > -h -? --help Print this help message > -? -h --help > -? -h --help : display this help message and exit > -? -h --help : display this help message and exit > -? -h --help print this help message and exit > -? | -h | --help to print this help message > jmap -? -h --help to print this help message > usage: jps [-? -h --help] > -? -h --help to print this help message > -? -h --help Prints this help message. > -? -h --help print this help message > -? -h --help Print this synopsis of standard options and exit > Use "keytool -? -h or --help" for all available commands > --help print this help message to the output stream > -?, -h, --help Print this help message > -h, --help, -? Print this help message > -?, -h, --help Print this help message > -? -h --help Print this help message and exit > -?, -h, --help print this help message > -?, -h, --help print this help message > -? -h --help Print this help message > -?, -h, --help[:compat] Give this, or optionally the compatibility, help > [-? -h --help] Print this help message > jstatd -?|-h|--help > > >> -----Original Message----- >> From: Weijun Wang [mailto:weijun.wang at oracle.com] >> Sent: Sonntag, 19. November 2017 01:28 >> To: Lindenmaier, Goetz >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; >> serviceability-dev (serviceability-dev at openjdk.java.net) > dev at openjdk.java.net> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help >> >> I am OK with all commands supporting --help, but I am not sure if every tool >> should show it on the help screen if the tools's other options are still using >> the old single-"-" style. It looks like the tools are half-converted. >> >> Is there a timetable to add "--" support to all tools? >> >> Thanks >> Max >> >>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz >> wrote: >>> >>> Hi, >>> >>> please review this change. I also filed a CSR for this: >>> http://cr.openjdk.java.net/~goetz/wr17/8189102- >> helpMessage/webrev.02/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 >>> >>> See the webrev for a detailed description of the changes. >>> >>> If required, I'll make break-out changes to be reviewed separately. >>> >>> I had posted a RFR before, but improved the change to >>> give a more complete overview of currently supported flags >>> for the CSR: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- >> October/028615.html >>> >>> Best regards, >>> Goetz. >>> > From rkennke at redhat.com Mon Nov 20 15:32:31 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Nov 2017 16:32:31 +0100 Subject: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses Message-ID: <387d2b93-cb8b-51be-a6e0-3b5f9d6cbb1c@redhat.com> Currently, there's lots of GC specific code sprinkled over src/hotspot/share/services. This change introduces a GC interface for that, and moves all GC specific code to their respective src/hotspot/share/gc directory. http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/ Testing: hotspot_gc and hotspot_serviceability, none showed regressions Built minimal and server without regressions What do you think? Roman From daniel.daugherty at oracle.com Tue Nov 21 01:50:29 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Nov 2017 20:50:29 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> Message-ID: <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> On 11/20/17 12:51 AM, David Holmes wrote: > Hi Dan, > > Figured I'd better cast an eye over this again before it gets pushed :) Thanks for reviewing again!! > Only one thing (repeated many times) jumped out at me and apologies if > this has already been debated back and forth. I missed the exchange > where the for loop iteration was rewritten into this unusual form: > > for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = > jtiwh.next(); ) { > > On first reading I expect most people would mistake the control > expression for the iteration-expression due to the next(). I didn't > even know the control expression could introduce a local variable! I > find this really hard to read stylistically and far too cute/clever > for its own good. It also violates the style rules regarding implicit > boolean checks. > > I know Stefan proposed this as he did not like the alternate (in a few > places): > > +? { > +??? ThreadsListHandle tlh; > +??? JavaThreadIterator jti(tlh.list()); > +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { > ... > +? } > > but it seems to me the iterator code has evolved since then and only a > couple of places need a distinct TLH separate from the actual iterator > object. So I'm more in favour of the more classic for-loop, with the > iterator declared before the loop. Or even convert to while loops, as > this iterator seems more suited to that. Actually both Coleen and Stefan had a problem with how much additional code was added to support an iterator model. In some cases we went from 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For Coleen, she wanted 2 of the new lines compressed into 1 new line by using an iterator with an embedded ThreadsListHandle. Stefan wanted us to try and get back to 1-line where possible. The advantages of the new style are: - 1-line to 1-line in all but a few cases - automatic limited scope of the embedded ThreadsListHandle so we were ? able to remove extra braces that were added earlier in most cases The disadvantages of the new style are: - it is an unusual for-loop style (in HotSpot) - it breaks HotSpot's style rule about implied booleans Stefan K is pretty adamant that the original iterator version where we go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC code. The compiler guys haven't chimed in on this debate so I'm guessing they don't have a strong opinion either way. One thing that we don't want to do is have different styles for the different teams. So I had to make a judgement call on whether I thought Runtime could live with Stefan's idea. Originally I wasn't fond of it either and breaking the implied boolean style rule is a problem for me (I post that comment a lot in my code reviews). However, I have to say that I'm a lot happier about the compactness of the code and the fact that limited ThreadsListHandle scope comes for 'free' in most cases. We're planning to keep the new iterator style for the following reasons: - smaller change footprint - consistent style used for all of the teams - limited ThreadsListHandle scope comes for free in most cases We're hoping that you can live with this decision (for now) and maybe even grow to like it in the future. :-) > Other than that just a couple of comments on variable type choices, > and a few typos spotted below. Replies embedded below. > > Thanks, > David > --- > > src/hotspot/share/runtime/globals.hpp > > 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, > ??????? \ > 2477?????????? "Enable Thread SMR extra validity checks") \ > 2478 ??????? \ > 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ > 2480?????????? "Enable Thread SMR Statistics") ??????? \ > > Indent of strings is off by? 3 spaces. Fixed. > --- > > src/hotspot/share/runtime/handshake.cpp > > ?140?????? // There is assumption in code that Threads_lock should be > lock > ?200?????? // There is assumption in code that Threads_lock should be > lock > > lock -> locked Fixed. > 146???????? // handshake_process_by_vmthread will check the semaphore > for us again > > Needs period at end. Fixed. > 148???????? // should be okey since the new thread will not have an > operation. > > okey -> okay Fixed. > 151???????? // We can't warn here is since the thread do > cancel_handshake after it have been removed > > I think: > > // We can't warn here since the thread does cancel_handshake after it > has been removed Fixed. > 152???????? // from ThreadsList. So we should just keep looping here > until while below return negative. > > from -> from the > > Needs period at end. Fixed both. > > ?204???????????? // A new thread on the ThreadsList will not have an > operation. > > Change period to comma, and ... Fixed. > 205???????????? // Hence is skipped in handshake_process_by_vmthread. > > Hence is -> hence it is Fixed. > --- > > src/hotspot/share/runtime/thread.cpp > > 1482???? // dcubed - Looks like the Threads_lock is for stable access > 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. > > Does this comment need revisiting? We've been trying to decide what to do about this comment. We'll be filing a follow up bug for the Compiler team to take another look at how _jvmci_old_thread_counters and _jvmci_counters are protected. Threads_lock is a big hammer and there should be a less expensive solution. Once that bug gets filed, this comment can go away. > 3451 volatile jint ... > > Why are you using jint for field types here? (Surprised Coleen hasn't > spotted them! ;-) ). volatile jint???????? Threads::_smr_delete_notify = 0; volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; volatile jint???????? Threads::_smr_deleted_thread_times = 0; : volatile jint???????? Threads::_smr_tlh_cnt = 0; volatile jint???????? Threads::_smr_tlh_time_max = 0; volatile jint???????? Threads::_smr_tlh_times = 0; _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock notify() operation is needed. It counts up and down and should be a fairly small number. _smr_deleted_thread_cnt counts the number of Threads that have been deleted over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running. _smr_deleted_thread_time_max is the maximum time in millis it has taken to delete a thread. This field was originally a jlong, but IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have just been Atomic::add() that was not happy) _smr_deleted_thread_times accumulates the time in millis that it has taken to delete threads. It's an always increasing number so it's size depends on how long the VM has been running. This field was originally a jlong, but IIRC the Atomic::add() code was not happy on ARM... (might have just been Atomic::cmpxchg() that was not happy) _smr_tlh_cnt counts the number of ThreadsListHandles that have been deleted over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running. _smr_tlh_time_max is the maximum time in millis it has taken to delete a ThreadsListHandle. This field was originally a jlong, but IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have just been Atomic::add() that was not happy) _smr_tlh_times? accumulates the time in millis that it has taken to delete ThreadsListHandles. It's an always increasing number so it's size depends on how long the VM has been running.? This field was originally a jlong, but IIRC the Atomic::add() code was not happy on ARM... (might have just been Atomic::cmpxchg() that was not happy) It just dawned on me that I'm not sure whether you think the 'jint' fields should be larger or smaller or the same size but a different type... :-) The fact that I had to write so much to explain what these fields are for and how they're used indicates I need more comments. See below... > 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; > 3457 long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; > > long? If you really want 64-bit counters here you won't get them on > Windows with that declaration. If you really want variable sized > counters I suggest uintptr_t; otherwise uint64_t. long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that have been allocated over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running and how many Threads have been created and destroyed. _smr_java_thread_list_free_cnt counts the number of ThreadsLists that have been freed over the life of the VM. It's an always increasing number so it's size depends on how long the VM has been running and how many Threads have been created and destroyed. I can't remember why we chose 'long' and I agree it's not a good choice for Win*. Okay so it dawns on me that we haven't written down a description for the various new '_cnt', '_max' and '_times" fields so I'm adding these comments to thread.hpp: ?private: ? // Safe Memory Reclamation (SMR) support: ? static Monitor*????????????? _smr_delete_lock; ? // The '_cnt', '_max' and '_times" fields are enabled via ? // -XX:+EnableThreadSMRStatistics: ?????????????????????????????? // # of parallel threads in _smr_delete_lock->wait(). ? static uint????????????????? _smr_delete_lock_wait_cnt; ?????????????????????????????? // Max # of parallel threads in _smr_delete_lock->wait(). ? static uint????????????????? _smr_delete_lock_wait_max; ?????????????????????????????? // Flag to indicate when an _smr_delete_lock->notify() is needed. ? static volatile uint???????? _smr_delete_notify; ?????????????????????????????? // # of threads deleted over VM lifetime. ? static volatile uint???????? _smr_deleted_thread_cnt; ?????????????????????????????? // Max time in millis to delete a thread. ? static volatile uint???????? _smr_deleted_thread_time_max; ?????????????????????????????? // Cumulative time in millis to delete threads. ? static volatile uint???????? _smr_deleted_thread_times; ? static ThreadsList* volatile _smr_java_thread_list; ? static ThreadsList*????????? get_smr_java_thread_list(); ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); ?????????????????????????????? // # of ThreadsLists allocated over VM lifetime. ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; ?????????????????????????????? // # of ThreadsLists freed over VM lifetime. ? static uint64_t????????????? _smr_java_thread_list_free_cnt; ?????????????????????????????? // Max size ThreadsList allocated. ? static uint????????????????? _smr_java_thread_list_max; ?????????????????????????????? // Max # of nested ThreadsLists for a thread. ? static uint????????????????? _smr_nested_thread_list_max; ?????????????????????????????? // # of ThreadsListHandles deleted over VM lifetime. ? static volatile uint???????? _smr_tlh_cnt; ?????????????????????????????? // Max time in millis to delete a ThreadsListHandle. ? static volatile jint???????? _smr_tlh_time_max; ?????????????????????????????? // Cumulative time in millis to delete ThreadsListHandles. ? static volatile jint???????? _smr_tlh_times; ? static ThreadsList*????????? _smr_to_delete_list; ?????????????????????????????? // # of parallel ThreadsLists on the to-delete list. ? static uint????????????????? _smr_to_delete_list_cnt; ?????????????????????????????? // Max # of parallel ThreadsLists on the to-delete list. ? static uint????????????????? _smr_to_delete_list_max; I've also gone through all the new '_cnt', '_max' and '_times" fields in thread.cpp and added an impl note to explain the choice of type: // Safe Memory Reclamation (SMR) support: Monitor*????????????? Threads::_smr_delete_lock = ????????????????????????? new Monitor(Monitor::special, "smr_delete_lock", ????????????????????????????????????? false /* allow_vm_block */, Monitor::_safepoint_check_never); // The '_cnt', '_max' and '_times" fields are enabled via // -XX:+EnableThreadSMRStatistics: ????????????????????? // # of parallel threads in _smr_delete_lock->wait(). ????????????????????? // Impl note: Hard to imagine > 64K waiting threads so ????????????????????? // this could be 16-bit, but there is no nice 16-bit ????????????????????? // _FORMAT support. uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; ????????????????????? // Max # of parallel threads in _smr_delete_lock->wait(). ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. uint????????????????? Threads::_smr_delete_lock_wait_max = 0; ????????????????????? // Flag to indicate when an _smr_delete_lock->notify() is needed. ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. volatile uint???????? Threads::_smr_delete_notify = 0; ????????????????????? // # of threads deleted over VM lifetime. ????????????????????? // Impl note: Atomically incremented over VM lifetime so ????????????????????? // use unsigned for more range. Unsigned 64-bit would ????????????????????? // be more future proof, but 64-bit atomic inc isn't ????????????????????? // available everywhere (or is it?). volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; ????????????????????? // Max time in millis to delete a thread. ????????????????????? // Impl note: 16-bit might be too small on an overloaded ????????????????????? // machine. Use unsigned since this is a time value. Set ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; ????????????????????? // Cumulative time in millis to delete threads. ????????????????????? // Impl note: Atomically added to over VM lifetime so use ????????????????????? // unsigned for more range. Unsigned 64-bit would be more ????????????????????? // future proof, but 64-bit atomic inc isn't available ????????????????????? // everywhere (or is it?). volatile uint???????? Threads::_smr_deleted_thread_times = 0; ThreadsList* volatile Threads::_smr_java_thread_list = new ThreadsList(0); ????????????????????? // # of ThreadsLists allocated over VM lifetime. ????????????????????? // Impl note: We allocate a new ThreadsList for every ????????????????????? // thread create and every thread delete so we need a ????????????????????? // bigger type than the _smr_deleted_thread_cnt field. uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; ????????????????????? // # of ThreadsLists freed over VM lifetime. ????????????????????? // Impl note: See _smr_java_thread_list_alloc_cnt note. uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; ????????????????????? // Max size ThreadsList allocated. ????????????????????? // Impl note: Max # of threads alive at one time should ????????????????????? // fit in unsigned 32-bit. uint????????????????? Threads::_smr_java_thread_list_max = 0; ????????????????????? // Max # of nested ThreadsLists for a thread. ????????????????????? // Impl note: Hard to imagine > 64K nested ThreadsLists ????????????????????? // so his could be 16-bit, but there is no nice 16-bit ????????????????????? // _FORMAT support. uint????????????????? Threads::_smr_nested_thread_list_max = 0; ????????????????????? // # of ThreadsListHandles deleted over VM lifetime. ????????????????????? // Impl note: Atomically incremented over VM lifetime so ????????????????????? // use unsigned for more range. There will be fewer ????????????????????? // ThreadsListHandles than threads so unsigned 32-bit ????????????????????? // should be fine. volatile uint???????? Threads::_smr_tlh_cnt = 0; ????????????????????? // Max time in millis to delete a ThreadsListHandle. ????????????????????? // Impl note: 16-bit might be too small on an overloaded ????????????????????? // machine. Use unsigned since this is a time value. Set ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. volatile uint???????? Threads::_smr_tlh_time_max = 0; ????????????????????? // Cumulative time in millis to delete ThreadsListHandles. ????????????????????? // Impl note: Atomically added to over VM lifetime so use ????????????????????? // unsigned for more range. Unsigned 64-bit would be more ????????????????????? // future proof, but 64-bit atomic inc isn't available ????????????????????? // everywhere (or is it?). volatile uint???????? Threads::_smr_tlh_times = 0; ThreadsList*????????? Threads::_smr_to_delete_list = NULL; ????????????????????? // # of parallel ThreadsLists on the to-delete list. ????????????????????? // Impl note: Hard to imagine > 64K ThreadsLists needing ????????????????????? // to be deleted so this could be 16-bit, but there is no ????????????????????? // nice 16-bit _FORMAT support. uint????????????????? Threads::_smr_to_delete_list_cnt = 0; ????????????????????? // Max # of parallel ThreadsLists on the to-delete list. ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. uint????????????????? Threads::_smr_to_delete_list_max = 0; Yikes! With the additional comments, the additions to thread.hpp and thread.cpp grew by a bunch... I've done a test build build on my Mac with these changes and I'm about to kick off a Mach5 tier1 job... Dan > > ---- > > On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up >>> thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from >>>> within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>> holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>> closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>> use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>> describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From david.holmes at oracle.com Tue Nov 21 02:13:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 12:13:40 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> Message-ID: Hi Dan, Just to be clear my comment about use of jint's was not about expected size but the fact you were using a j-type instead of a C++ type when the field is not a Java field. (Coleen has been on a crusade to remove j-types from where they don't belong - and they were removed from the Atomic API as part of that recent templatization effort.) No further comments. :) Thanks, David On 21/11/2017 11:50 AM, Daniel D. Daugherty wrote: > On 11/20/17 12:51 AM, David Holmes wrote: >> Hi Dan, >> >> Figured I'd better cast an eye over this again before it gets pushed :) > > Thanks for reviewing again!! > > >> Only one thing (repeated many times) jumped out at me and apologies if >> this has already been debated back and forth. I missed the exchange >> where the for loop iteration was rewritten into this unusual form: >> >> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >> jtiwh.next(); ) { >> >> On first reading I expect most people would mistake the control >> expression for the iteration-expression due to the next(). I didn't >> even know the control expression could introduce a local variable! I >> find this really hard to read stylistically and far too cute/clever >> for its own good. It also violates the style rules regarding implicit >> boolean checks. >> >> I know Stefan proposed this as he did not like the alternate (in a few >> places): >> >> +? { >> +??? ThreadsListHandle tlh; >> +??? JavaThreadIterator jti(tlh.list()); >> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >> ... >> +? } >> >> but it seems to me the iterator code has evolved since then and only a >> couple of places need a distinct TLH separate from the actual iterator >> object. So I'm more in favour of the more classic for-loop, with the >> iterator declared before the loop. Or even convert to while loops, as >> this iterator seems more suited to that. > > Actually both Coleen and Stefan had a problem with how much additional > code was added to support an iterator model. In some cases we went from > 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For > Coleen, she wanted 2 of the new lines compressed into 1 new line by using > an iterator with an embedded ThreadsListHandle. Stefan wanted us to try > and get back to 1-line where possible. > > The advantages of the new style are: > > - 1-line to 1-line in all but a few cases > - automatic limited scope of the embedded ThreadsListHandle so we were > ? able to remove extra braces that were added earlier in most cases > > The disadvantages of the new style are: > > - it is an unusual for-loop style (in HotSpot) > - it breaks HotSpot's style rule about implied booleans > > > Stefan K is pretty adamant that the original iterator version where we > go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC > code. The compiler guys haven't chimed in on this debate so I'm guessing > they don't have a strong opinion either way. One thing that we don't want > to do is have different styles for the different teams. > > So I had to make a judgement call on whether I thought Runtime could live > with Stefan's idea. Originally I wasn't fond of it either and breaking the > implied boolean style rule is a problem for me (I post that comment a lot > in my code reviews). However, I have to say that I'm a lot happier about > the compactness of the code and the fact that limited ThreadsListHandle > scope comes for 'free' in most cases. > > We're planning to keep the new iterator style for the following reasons: > > - smaller change footprint > - consistent style used for all of the teams > - limited ThreadsListHandle scope comes for free in most cases > > We're hoping that you can live with this decision (for now) and maybe > even grow to like it in the future. :-) > > >> Other than that just a couple of comments on variable type choices, >> and a few typos spotted below. > > Replies embedded below. > > >> >> Thanks, >> David >> --- >> >> src/hotspot/share/runtime/globals.hpp >> >> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >> ??????? \ >> 2477?????????? "Enable Thread SMR extra validity checks") \ >> 2478 ??????? \ >> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ >> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >> >> Indent of strings is off by? 3 spaces. > > Fixed. > > >> --- >> >> src/hotspot/share/runtime/handshake.cpp >> >> ?140?????? // There is assumption in code that Threads_lock should be >> lock >> ?200?????? // There is assumption in code that Threads_lock should be >> lock >> >> lock -> locked > > Fixed. > > >> 146???????? // handshake_process_by_vmthread will check the semaphore >> for us again >> >> Needs period at end. > > Fixed. > > >> 148???????? // should be okey since the new thread will not have an >> operation. >> >> okey -> okay > > Fixed. > > >> 151???????? // We can't warn here is since the thread do >> cancel_handshake after it have been removed >> >> I think: >> >> // We can't warn here since the thread does cancel_handshake after it >> has been removed > > Fixed. > > >> 152???????? // from ThreadsList. So we should just keep looping here >> until while below return negative. >> >> from -> from the >> >> Needs period at end. > > Fixed both. > > >> >> ?204???????????? // A new thread on the ThreadsList will not have an >> operation. >> >> Change period to comma, and ... > > Fixed. > > >> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >> >> Hence is -> hence it is > > Fixed. > > >> --- >> >> src/hotspot/share/runtime/thread.cpp >> >> 1482???? // dcubed - Looks like the Threads_lock is for stable access >> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >> >> Does this comment need revisiting? > > We've been trying to decide what to do about this comment. We'll be > filing a follow up bug for the Compiler team to take another look at > how _jvmci_old_thread_counters and _jvmci_counters are protected. > Threads_lock is a big hammer and there should be a less expensive > solution. Once that bug gets filed, this comment can go away. > > >> 3451 volatile jint ... >> >> Why are you using jint for field types here? (Surprised Coleen hasn't >> spotted them! ;-) ). > > volatile jint???????? Threads::_smr_delete_notify = 0; > volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; > volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; > volatile jint???????? Threads::_smr_deleted_thread_times = 0; > : > volatile jint???????? Threads::_smr_tlh_cnt = 0; > volatile jint???????? Threads::_smr_tlh_time_max = 0; > volatile jint???????? Threads::_smr_tlh_times = 0; > > _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock > notify() operation is needed. It counts up and down and should be a fairly > small number. > > _smr_deleted_thread_cnt counts the number of Threads that have been > deleted over the life of the VM. It's an always increasing number so > it's size depends on how long the VM has been running. > > _smr_deleted_thread_time_max is the maximum time in millis it has > taken to delete a thread. This field was originally a jlong, but > IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have > just been Atomic::add() that was not happy) > > _smr_deleted_thread_times accumulates the time in millis that it > has taken to delete threads. It's an always increasing number so > it's size depends on how long the VM has been running. This field > was originally a jlong, but IIRC the Atomic::add() code was not > happy on ARM... (might have just been Atomic::cmpxchg() that was > not happy) > > _smr_tlh_cnt counts the number of ThreadsListHandles that have been > deleted over the life of the VM. It's an always increasing number so > it's size depends on how long the VM has been running. > > _smr_tlh_time_max is the maximum time in millis it has taken to > delete a ThreadsListHandle. This field was originally a jlong, but > IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have > just been Atomic::add() that was not happy) > > _smr_tlh_times? accumulates the time in millis that it has taken to > delete ThreadsListHandles. It's an always increasing number so > it's size depends on how long the VM has been running.? This field > was originally a jlong, but IIRC the Atomic::add() code was not > happy on ARM... (might have just been Atomic::cmpxchg() that was > not happy) > > > It just dawned on me that I'm not sure whether you think the 'jint' > fields should be larger or smaller or the same size but a different > type... :-) > > The fact that I had to write so much to explain what these fields > are for and how they're used indicates I need more comments. See > below... > > >> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >> 3457 long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> long? If you really want 64-bit counters here you won't get them on >> Windows with that declaration. If you really want variable sized >> counters I suggest uintptr_t; otherwise uint64_t. > > long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; > long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; > > _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that > have been allocated over the life of the VM. It's an always increasing > number so it's size depends on how long the VM has been running and how > many Threads have been created and destroyed. > > _smr_java_thread_list_free_cnt counts the number of ThreadsLists that > have been freed over the life of the VM. It's an always increasing > number so it's size depends on how long the VM has been running and how > many Threads have been created and destroyed. > > I can't remember why we chose 'long' and I agree it's not a good choice > for Win*. > > > Okay so it dawns on me that we haven't written down a description for > the various new '_cnt', '_max' and '_times" fields so I'm adding these > comments to thread.hpp: > > ?private: > ? // Safe Memory Reclamation (SMR) support: > ? static Monitor*????????????? _smr_delete_lock; > ? // The '_cnt', '_max' and '_times" fields are enabled via > ? // -XX:+EnableThreadSMRStatistics: > ?????????????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_cnt; > ?????????????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_max; > ?????????????????????????????? // Flag to indicate when an > _smr_delete_lock->notify() is needed. > ? static volatile uint???????? _smr_delete_notify; > ?????????????????????????????? // # of threads deleted over VM lifetime. > ? static volatile uint???????? _smr_deleted_thread_cnt; > ?????????????????????????????? // Max time in millis to delete a thread. > ? static volatile uint???????? _smr_deleted_thread_time_max; > ?????????????????????????????? // Cumulative time in millis to delete > threads. > ? static volatile uint???????? _smr_deleted_thread_times; > ? static ThreadsList* volatile _smr_java_thread_list; > ? static ThreadsList*????????? get_smr_java_thread_list(); > ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); > ?????????????????????????????? // # of ThreadsLists allocated over VM > lifetime. > ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; > ?????????????????????????????? // # of ThreadsLists freed over VM > lifetime. > ? static uint64_t????????????? _smr_java_thread_list_free_cnt; > ?????????????????????????????? // Max size ThreadsList allocated. > ? static uint????????????????? _smr_java_thread_list_max; > ?????????????????????????????? // Max # of nested ThreadsLists for a > thread. > ? static uint????????????????? _smr_nested_thread_list_max; > ?????????????????????????????? // # of ThreadsListHandles deleted over > VM lifetime. > ? static volatile uint???????? _smr_tlh_cnt; > ?????????????????????????????? // Max time in millis to delete a > ThreadsListHandle. > ? static volatile jint???????? _smr_tlh_time_max; > ?????????????????????????????? // Cumulative time in millis to delete > ThreadsListHandles. > ? static volatile jint???????? _smr_tlh_times; > ? static ThreadsList*????????? _smr_to_delete_list; > ?????????????????????????????? // # of parallel ThreadsLists on the > to-delete list. > ? static uint????????????????? _smr_to_delete_list_cnt; > ?????????????????????????????? // Max # of parallel ThreadsLists on the > to-delete list. > ? static uint????????????????? _smr_to_delete_list_max; > > > I've also gone through all the new '_cnt', '_max' and '_times" fields > in thread.cpp and added an impl note to explain the choice of type: > > // Safe Memory Reclamation (SMR) support: > Monitor*????????????? Threads::_smr_delete_lock = > ????????????????????????? new Monitor(Monitor::special, "smr_delete_lock", > ????????????????????????????????????? false /* allow_vm_block */, > Monitor::_safepoint_check_never); > // The '_cnt', '_max' and '_times" fields are enabled via > // -XX:+EnableThreadSMRStatistics: > ????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ????????????????????? // Impl note: Hard to imagine > 64K waiting > threads so > ????????????????????? // this could be 16-bit, but there is no nice 16-bit > ????????????????????? // _FORMAT support. > uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; > ????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. > uint????????????????? Threads::_smr_delete_lock_wait_max = 0; > ????????????????????? // Flag to indicate when an > _smr_delete_lock->notify() is needed. > ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. > volatile uint???????? Threads::_smr_delete_notify = 0; > ????????????????????? // # of threads deleted over VM lifetime. > ????????????????????? // Impl note: Atomically incremented over VM > lifetime so > ????????????????????? // use unsigned for more range. Unsigned 64-bit > would > ????????????????????? // be more future proof, but 64-bit atomic inc isn't > ????????????????????? // available everywhere (or is it?). > volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; > ????????????????????? // Max time in millis to delete a thread. > ????????????????????? // Impl note: 16-bit might be too small on an > overloaded > ????????????????????? // machine. Use unsigned since this is a time > value. Set > ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. > volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; > ????????????????????? // Cumulative time in millis to delete threads. > ????????????????????? // Impl note: Atomically added to over VM > lifetime so use > ????????????????????? // unsigned for more range. Unsigned 64-bit would > be more > ????????????????????? // future proof, but 64-bit atomic inc isn't > available > ????????????????????? // everywhere (or is it?). > volatile uint???????? Threads::_smr_deleted_thread_times = 0; > ThreadsList* volatile Threads::_smr_java_thread_list = new ThreadsList(0); > ????????????????????? // # of ThreadsLists allocated over VM lifetime. > ????????????????????? // Impl note: We allocate a new ThreadsList for > every > ????????????????????? // thread create and every thread delete so we > need a > ????????????????????? // bigger type than the _smr_deleted_thread_cnt > field. > uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; > ????????????????????? // # of ThreadsLists freed over VM lifetime. > ????????????????????? // Impl note: See _smr_java_thread_list_alloc_cnt > note. > uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; > ????????????????????? // Max size ThreadsList allocated. > ????????????????????? // Impl note: Max # of threads alive at one time > should > ????????????????????? // fit in unsigned 32-bit. > uint????????????????? Threads::_smr_java_thread_list_max = 0; > ????????????????????? // Max # of nested ThreadsLists for a thread. > ????????????????????? // Impl note: Hard to imagine > 64K nested > ThreadsLists > ????????????????????? // so his could be 16-bit, but there is no nice > 16-bit > ????????????????????? // _FORMAT support. > uint????????????????? Threads::_smr_nested_thread_list_max = 0; > ????????????????????? // # of ThreadsListHandles deleted over VM lifetime. > ????????????????????? // Impl note: Atomically incremented over VM > lifetime so > ????????????????????? // use unsigned for more range. There will be fewer > ????????????????????? // ThreadsListHandles than threads so unsigned > 32-bit > ????????????????????? // should be fine. > volatile uint???????? Threads::_smr_tlh_cnt = 0; > ????????????????????? // Max time in millis to delete a ThreadsListHandle. > ????????????????????? // Impl note: 16-bit might be too small on an > overloaded > ????????????????????? // machine. Use unsigned since this is a time > value. Set > ????????????????????? // via Atomic::cmpxchg() in a loop for correctness. > volatile uint???????? Threads::_smr_tlh_time_max = 0; > ????????????????????? // Cumulative time in millis to delete > ThreadsListHandles. > ????????????????????? // Impl note: Atomically added to over VM > lifetime so use > ????????????????????? // unsigned for more range. Unsigned 64-bit would > be more > ????????????????????? // future proof, but 64-bit atomic inc isn't > available > ????????????????????? // everywhere (or is it?). > volatile uint???????? Threads::_smr_tlh_times = 0; > ThreadsList*????????? Threads::_smr_to_delete_list = NULL; > ????????????????????? // # of parallel ThreadsLists on the to-delete list. > ????????????????????? // Impl note: Hard to imagine > 64K ThreadsLists > needing > ????????????????????? // to be deleted so this could be 16-bit, but > there is no > ????????????????????? // nice 16-bit _FORMAT support. > uint????????????????? Threads::_smr_to_delete_list_cnt = 0; > ????????????????????? // Max # of parallel ThreadsLists on the > to-delete list. > ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. > uint????????????????? Threads::_smr_to_delete_list_max = 0; > > > Yikes! With the additional comments, the additions to thread.hpp and > thread.cpp grew by a bunch... I've done a test build build on my Mac > with these changes and I'm about to kick off a Mach5 tier1 job... > > Dan > > > >> >> ---- >> >> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>>> Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>>> as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>>> use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> > From daniel.daugherty at oracle.com Tue Nov 21 03:51:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 Nov 2017 22:51:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> Message-ID: <0fc655c8-fffe-03cc-0f7b-a34a9893923d@oracle.com> On 11/20/17 9:13 PM, David Holmes wrote: > Hi Dan, > > Just to be clear my comment about use of jint's was not about expected > size but the fact you were using a j-type instead of a C++ type when > the field is not a Java field. (Coleen has been on a crusade to remove > j-types from where they don't belong - and they were removed from the > Atomic API as part of that recent templatization effort.) Thanks for making that clear. I think I've gotten rid of all the jint's at this point... > No further comments. :) Thanks. I'll be sending out more webrevs when I get through all the code review comments... Dan > > Thanks, > David > > On 21/11/2017 11:50 AM, Daniel D. Daugherty wrote: >> On 11/20/17 12:51 AM, David Holmes wrote: >>> Hi Dan, >>> >>> Figured I'd better cast an eye over this again before it gets pushed :) >> >> Thanks for reviewing again!! >> >> >>> Only one thing (repeated many times) jumped out at me and apologies >>> if this has already been debated back and forth. I missed the >>> exchange where the for loop iteration was rewritten into this >>> unusual form: >>> >>> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >>> jtiwh.next(); ) { >>> >>> On first reading I expect most people would mistake the control >>> expression for the iteration-expression due to the next(). I didn't >>> even know the control expression could introduce a local variable! I >>> find this really hard to read stylistically and far too cute/clever >>> for its own good. It also violates the style rules regarding >>> implicit boolean checks. >>> >>> I know Stefan proposed this as he did not like the alternate (in a >>> few places): >>> >>> +? { >>> +??? ThreadsListHandle tlh; >>> +??? JavaThreadIterator jti(tlh.list()); >>> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >>> ... >>> +? } >>> >>> but it seems to me the iterator code has evolved since then and only >>> a couple of places need a distinct TLH separate from the actual >>> iterator object. So I'm more in favour of the more classic for-loop, >>> with the iterator declared before the loop. Or even convert to while >>> loops, as this iterator seems more suited to that. >> >> Actually both Coleen and Stefan had a problem with how much additional >> code was added to support an iterator model. In some cases we went from >> 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For >> Coleen, she wanted 2 of the new lines compressed into 1 new line by >> using >> an iterator with an embedded ThreadsListHandle. Stefan wanted us to try >> and get back to 1-line where possible. >> >> The advantages of the new style are: >> >> - 1-line to 1-line in all but a few cases >> - automatic limited scope of the embedded ThreadsListHandle so we were >> ?? able to remove extra braces that were added earlier in most cases >> >> The disadvantages of the new style are: >> >> - it is an unusual for-loop style (in HotSpot) >> - it breaks HotSpot's style rule about implied booleans >> >> >> Stefan K is pretty adamant that the original iterator version where we >> go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC >> code. The compiler guys haven't chimed in on this debate so I'm guessing >> they don't have a strong opinion either way. One thing that we don't >> want >> to do is have different styles for the different teams. >> >> So I had to make a judgement call on whether I thought Runtime could >> live >> with Stefan's idea. Originally I wasn't fond of it either and >> breaking the >> implied boolean style rule is a problem for me (I post that comment a >> lot >> in my code reviews). However, I have to say that I'm a lot happier about >> the compactness of the code and the fact that limited ThreadsListHandle >> scope comes for 'free' in most cases. >> >> We're planning to keep the new iterator style for the following reasons: >> >> - smaller change footprint >> - consistent style used for all of the teams >> - limited ThreadsListHandle scope comes for free in most cases >> >> We're hoping that you can live with this decision (for now) and maybe >> even grow to like it in the future. :-) >> >> >>> Other than that just a couple of comments on variable type choices, >>> and a few typos spotted below. >> >> Replies embedded below. >> >> >>> >>> Thanks, >>> David >>> --- >>> >>> src/hotspot/share/runtime/globals.hpp >>> >>> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >>> ??????? \ >>> 2477?????????? "Enable Thread SMR extra validity checks") \ >>> 2478 ??????? \ >>> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, ??????? \ >>> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >>> >>> Indent of strings is off by? 3 spaces. >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/handshake.cpp >>> >>> ?140?????? // There is assumption in code that Threads_lock should >>> be lock >>> ?200?????? // There is assumption in code that Threads_lock should >>> be lock >>> >>> lock -> locked >> >> Fixed. >> >> >>> 146???????? // handshake_process_by_vmthread will check the >>> semaphore for us again >>> >>> Needs period at end. >> >> Fixed. >> >> >>> 148???????? // should be okey since the new thread will not have an >>> operation. >>> >>> okey -> okay >> >> Fixed. >> >> >>> 151???????? // We can't warn here is since the thread do >>> cancel_handshake after it have been removed >>> >>> I think: >>> >>> // We can't warn here since the thread does cancel_handshake after >>> it has been removed >> >> Fixed. >> >> >>> 152???????? // from ThreadsList. So we should just keep looping here >>> until while below return negative. >>> >>> from -> from the >>> >>> Needs period at end. >> >> Fixed both. >> >> >>> >>> ?204???????????? // A new thread on the ThreadsList will not have an >>> operation. >>> >>> Change period to comma, and ... >> >> Fixed. >> >> >>> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >>> >>> Hence is -> hence it is >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 1482???? // dcubed - Looks like the Threads_lock is for stable access >>> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >>> >>> Does this comment need revisiting? >> >> We've been trying to decide what to do about this comment. We'll be >> filing a follow up bug for the Compiler team to take another look at >> how _jvmci_old_thread_counters and _jvmci_counters are protected. >> Threads_lock is a big hammer and there should be a less expensive >> solution. Once that bug gets filed, this comment can go away. >> >> >>> 3451 volatile jint ... >>> >>> Why are you using jint for field types here? (Surprised Coleen >>> hasn't spotted them! ;-) ). >> >> volatile jint???????? Threads::_smr_delete_notify = 0; >> volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; >> volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; >> volatile jint???????? Threads::_smr_deleted_thread_times = 0; >> : >> volatile jint???????? Threads::_smr_tlh_cnt = 0; >> volatile jint???????? Threads::_smr_tlh_time_max = 0; >> volatile jint???????? Threads::_smr_tlh_times = 0; >> >> _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock >> notify() operation is needed. It counts up and down and should be a >> fairly >> small number. >> >> _smr_deleted_thread_cnt counts the number of Threads that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_deleted_thread_time_max is the maximum time in millis it has >> taken to delete a thread. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_deleted_thread_times accumulates the time in millis that it >> has taken to delete threads. It's an always increasing number so >> it's size depends on how long the VM has been running. This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> _smr_tlh_cnt counts the number of ThreadsListHandles that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_tlh_time_max is the maximum time in millis it has taken to >> delete a ThreadsListHandle. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_tlh_times? accumulates the time in millis that it has taken to >> delete ThreadsListHandles. It's an always increasing number so >> it's size depends on how long the VM has been running.? This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> >> It just dawned on me that I'm not sure whether you think the 'jint' >> fields should be larger or smaller or the same size but a different >> type... :-) >> >> The fact that I had to write so much to explain what these fields >> are for and how they're used indicates I need more comments. See >> below... >> >> >>> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >>> 3457 long Threads::_smr_java_thread_list_free_cnt = 0; >>> >>> long? If you really want 64-bit counters here you won't get them on >>> Windows with that declaration. If you really want variable sized >>> counters I suggest uintptr_t; otherwise uint64_t. >> >> long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that >> have been allocated over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> _smr_java_thread_list_free_cnt counts the number of ThreadsLists that >> have been freed over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> I can't remember why we chose 'long' and I agree it's not a good choice >> for Win*. >> >> >> Okay so it dawns on me that we haven't written down a description for >> the various new '_cnt', '_max' and '_times" fields so I'm adding these >> comments to thread.hpp: >> >> ??private: >> ?? // Safe Memory Reclamation (SMR) support: >> ?? static Monitor*????????????? _smr_delete_lock; >> ?? // The '_cnt', '_max' and '_times" fields are enabled via >> ?? // -XX:+EnableThreadSMRStatistics: >> ??????????????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ?? static uint????????????????? _smr_delete_lock_wait_cnt; >> ??????????????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ?? static uint????????????????? _smr_delete_lock_wait_max; >> ??????????????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ?? static volatile uint???????? _smr_delete_notify; >> ??????????????????????????????? // # of threads deleted over VM >> lifetime. >> ?? static volatile uint???????? _smr_deleted_thread_cnt; >> ??????????????????????????????? // Max time in millis to delete a >> thread. >> ?? static volatile uint???????? _smr_deleted_thread_time_max; >> ??????????????????????????????? // Cumulative time in millis to >> delete threads. >> ?? static volatile uint???????? _smr_deleted_thread_times; >> ?? static ThreadsList* volatile _smr_java_thread_list; >> ?? static ThreadsList*????????? get_smr_java_thread_list(); >> ?? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); >> ??????????????????????????????? // # of ThreadsLists allocated over >> VM lifetime. >> ?? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; >> ??????????????????????????????? // # of ThreadsLists freed over VM >> lifetime. >> ?? static uint64_t????????????? _smr_java_thread_list_free_cnt; >> ??????????????????????????????? // Max size ThreadsList allocated. >> ?? static uint????????????????? _smr_java_thread_list_max; >> ??????????????????????????????? // Max # of nested ThreadsLists for a >> thread. >> ?? static uint????????????????? _smr_nested_thread_list_max; >> ??????????????????????????????? // # of ThreadsListHandles deleted >> over VM lifetime. >> ?? static volatile uint???????? _smr_tlh_cnt; >> ??????????????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ?? static volatile jint???????? _smr_tlh_time_max; >> ??????????????????????????????? // Cumulative time in millis to >> delete ThreadsListHandles. >> ?? static volatile jint???????? _smr_tlh_times; >> ?? static ThreadsList*????????? _smr_to_delete_list; >> ??????????????????????????????? // # of parallel ThreadsLists on the >> to-delete list. >> ?? static uint????????????????? _smr_to_delete_list_cnt; >> ??????????????????????????????? // Max # of parallel ThreadsLists on >> the to-delete list. >> ?? static uint????????????????? _smr_to_delete_list_max; >> >> >> I've also gone through all the new '_cnt', '_max' and '_times" fields >> in thread.cpp and added an impl note to explain the choice of type: >> >> // Safe Memory Reclamation (SMR) support: >> Monitor*????????????? Threads::_smr_delete_lock = >> ?????????????????????????? new Monitor(Monitor::special, >> "smr_delete_lock", >> ?????????????????????????????????????? false /* allow_vm_block */, >> Monitor::_safepoint_check_never); >> // The '_cnt', '_max' and '_times" fields are enabled via >> // -XX:+EnableThreadSMRStatistics: >> ?????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ?????????????????????? // Impl note: Hard to imagine > 64K waiting >> threads so >> ?????????????????????? // this could be 16-bit, but there is no nice >> 16-bit >> ?????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; >> ?????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ?????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> uint????????????????? Threads::_smr_delete_lock_wait_max = 0; >> ?????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ?????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> volatile uint???????? Threads::_smr_delete_notify = 0; >> ?????????????????????? // # of threads deleted over VM lifetime. >> ?????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ?????????????????????? // use unsigned for more range. Unsigned >> 64-bit would >> ?????????????????????? // be more future proof, but 64-bit atomic inc >> isn't >> ?????????????????????? // available everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; >> ?????????????????????? // Max time in millis to delete a thread. >> ?????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ?????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ?????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; >> ?????????????????????? // Cumulative time in millis to delete threads. >> ?????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ?????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ?????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ?????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_times = 0; >> ThreadsList* volatile Threads::_smr_java_thread_list = new >> ThreadsList(0); >> ?????????????????????? // # of ThreadsLists allocated over VM lifetime. >> ?????????????????????? // Impl note: We allocate a new ThreadsList >> for every >> ?????????????????????? // thread create and every thread delete so we >> need a >> ?????????????????????? // bigger type than the >> _smr_deleted_thread_cnt field. >> uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> ?????????????????????? // # of ThreadsLists freed over VM lifetime. >> ?????????????????????? // Impl note: See >> _smr_java_thread_list_alloc_cnt note. >> uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> ?????????????????????? // Max size ThreadsList allocated. >> ?????????????????????? // Impl note: Max # of threads alive at one >> time should >> ?????????????????????? // fit in unsigned 32-bit. >> uint????????????????? Threads::_smr_java_thread_list_max = 0; >> ?????????????????????? // Max # of nested ThreadsLists for a thread. >> ?????????????????????? // Impl note: Hard to imagine > 64K nested >> ThreadsLists >> ?????????????????????? // so his could be 16-bit, but there is no >> nice 16-bit >> ?????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_nested_thread_list_max = 0; >> ?????????????????????? // # of ThreadsListHandles deleted over VM >> lifetime. >> ?????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ?????????????????????? // use unsigned for more range. There will be >> fewer >> ?????????????????????? // ThreadsListHandles than threads so unsigned >> 32-bit >> ?????????????????????? // should be fine. >> volatile uint???????? Threads::_smr_tlh_cnt = 0; >> ?????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ?????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ?????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ?????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_tlh_time_max = 0; >> ?????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ?????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ?????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ?????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ?????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_tlh_times = 0; >> ThreadsList*????????? Threads::_smr_to_delete_list = NULL; >> ?????????????????????? // # of parallel ThreadsLists on the to-delete >> list. >> ?????????????????????? // Impl note: Hard to imagine > 64K >> ThreadsLists needing >> ?????????????????????? // to be deleted so this could be 16-bit, but >> there is no >> ?????????????????????? // nice 16-bit _FORMAT support. >> uint????????????????? Threads::_smr_to_delete_list_cnt = 0; >> ?????????????????????? // Max # of parallel ThreadsLists on the >> to-delete list. >> ?????????????????????? // Impl note: See _smr_to_delete_list_cnt note. >> uint????????????????? Threads::_smr_to_delete_list_max = 0; >> >> >> Yikes! With the additional comments, the additions to thread.hpp and >> thread.cpp grew by a bunch... I've done a test build build on my Mac >> with these changes and I'm about to kick off a Mach5 tier1 job... >> >> Dan >> >> >> >>> >>> ---- >>> >>> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> From sharath.ballal at oracle.com Tue Nov 21 05:00:49 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 20 Nov 2017 21:00:49 -0800 (PST) Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: <1e21429e-69bd-e9e3-7890-b857be80a3a8@oracle.com> References: <1e21429e-69bd-e9e3-7890-b857be80a3a8@oracle.com> Message-ID: Thank you David. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Monday, November 20, 2017 5:02 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler Hi Sharath, Looks okay. Thanks, David On 20/11/2017 7:24 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 > > Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ > > Thanks, > > Sharath > From jini.george at oracle.com Tue Nov 21 05:13:11 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 21 Nov 2017 10:43:11 +0530 Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: References: Message-ID: <0599991b-0eb3-4dc9-097a-92b2cecfb8f2@oracle.com> Hi Sharath, Since StartFlightRecording and UseAppCDS are closed only flags currently, these would fail for testing with open only builds. It might be prudent to remove the checking of these flags too. Other than this, the changes look good. Thank you, Jini. On 11/20/2017 2:54 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 > > Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ > > Thanks, > > Sharath > From sharath.ballal at oracle.com Tue Nov 21 05:16:50 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 20 Nov 2017 21:16:50 -0800 (PST) Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: <0599991b-0eb3-4dc9-097a-92b2cecfb8f2@oracle.com> References: <0599991b-0eb3-4dc9-097a-92b2cecfb8f2@oracle.com> Message-ID: <6328cfb3-669b-4d34-9a26-e5929d631692@default> OK. Thanks Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Tuesday, November 21, 2017 10:43 AM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler Hi Sharath, Since StartFlightRecording and UseAppCDS are closed only flags currently, these would fail for testing with open only builds. It might be prudent to remove the checking of these flags too. Other than this, the changes look good. Thank you, Jini. On 11/20/2017 2:54 PM, Sharath Ballal wrote: > Hello, > > Pls review changes for the following issue: > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 > > Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ > > Thanks, > > Sharath > From david.holmes at oracle.com Tue Nov 21 05:23:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 15:23:11 +1000 Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: <6328cfb3-669b-4d34-9a26-e5929d631692@default> References: <0599991b-0eb3-4dc9-097a-92b2cecfb8f2@oracle.com> <6328cfb3-669b-4d34-9a26-e5929d631692@default> Message-ID: Sorry I missed those commercial flags. But we need this fix in today else the test will be problem listed. Don't swap those flags for anything just delete them. Then no extra testing needed. Thanks, David On 21/11/2017 3:16 PM, Sharath Ballal wrote: > OK. Thanks Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Tuesday, November 21, 2017 10:43 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler > > Hi Sharath, > > Since StartFlightRecording and UseAppCDS are closed only flags currently, these would fail for testing with open only builds. It might be prudent to remove the checking of these flags too. Other than this, the changes look good. > > Thank you, > Jini. > > On 11/20/2017 2:54 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Tue Nov 21 05:24:12 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 20 Nov 2017 21:24:12 -0800 (PST) Subject: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler In-Reply-To: References: <0599991b-0eb3-4dc9-097a-92b2cecfb8f2@oracle.com> <6328cfb3-669b-4d34-9a26-e5929d631692@default> Message-ID: <53d3f81c-92ba-4692-9399-4b1ee8569b79@default> Sure David. Thanks. Thanks, Sharath -----Original Message----- From: David Holmes Sent: Tuesday, November 21, 2017 10:53 AM To: Sharath Ballal; Jini Susan George; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8191401 - [TESTBUG] serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler Sorry I missed those commercial flags. But we need this fix in today else the test will be problem listed. Don't swap those flags for anything just delete them. Then no extra testing needed. Thanks, David On 21/11/2017 3:16 PM, Sharath Ballal wrote: > OK. Thanks Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Tuesday, November 21, 2017 10:43 AM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8191401 - [TESTBUG] > serviceability/sa/ClhsdbFlags.java can fail due to UseJVMCICompiler > > Hi Sharath, > > Since StartFlightRecording and UseAppCDS are closed only flags currently, these would fail for testing with open only builds. It might be prudent to remove the checking of these flags too. Other than this, the changes look good. > > Thank you, > Jini. > > On 11/20/2017 2:54 PM, Sharath Ballal wrote: >> Hello, >> >> Pls review changes for the following issue: >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191401 >> >> Webrev: http://cr.openjdk.java.net/~sballal/8191401/webrev.00/ >> >> Thanks, >> >> Sharath >> From sharath.ballal at oracle.com Tue Nov 21 06:56:55 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 20 Nov 2017 22:56:55 -0800 (PST) Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException In-Reply-To: References: Message-ID: <84288f14-2283-4ea4-b152-28762c27237b@default> Gentle reminder. Thanks, Sharath From: Sharath Ballal Sent: Tuesday, November 14, 2017 10:31 AM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Hello, Pls review the code changes and testcase for the following issue. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 Webrev: http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Nov 21 07:17:42 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Nov 2017 23:17:42 -0800 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: <8749717a-f6d1-62c9-a2cc-427304ea5f35@gmail.com> References: <907944d9-e78d-65a3-1d5e-24661c737e25@gmail.com> <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> <8749717a-f6d1-62c9-a2cc-427304ea5f35@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Tue Nov 21 09:56:33 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 21 Nov 2017 01:56:33 -0800 (PST) Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException In-Reply-To: <84288f14-2283-4ea4-b152-28762c27237b@default> References: <84288f14-2283-4ea4-b152-28762c27237b@default> Message-ID: I have made minor modification to the test (added @bug and removed @modules). The revised webrev is http://cr.openjdk.java.net/~sballal/8184982/webrev.01/ Thanks, Sharath From: Sharath Ballal Sent: Tuesday, November 21, 2017 12:27 PM To: serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Gentle reminder. Thanks, Sharath From: Sharath Ballal Sent: Tuesday, November 14, 2017 10:31 AM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Hello, Pls review the code changes and testcase for the following issue. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 Webrev: http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Nov 21 10:34:55 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 21 Nov 2017 16:04:55 +0530 Subject: RFR: JDK-8191324: SA cleanup -- part 2 Message-ID: Hello, Here's requesting reviews for some SA code cleanup. ID: https://bugs.openjdk.java.net/browse/JDK-8191324 Webrev: http://cr.openjdk.java.net/~jgeorge/8191324/webrev.00/index.html The changes here are primarily to: 1. Remove unused IA64 SA code. 2. Make changes to avoid error-prone redefinition of hotspot constants in SA Java code. Instead read it in through vmStructs and db.lookupIntConstant(). 3. Make variable name changes in SA to align with the hotspot names. The changes are straightforward. Thanks much, Jini. From rkennke at redhat.com Tue Nov 21 11:50:14 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 12:50:14 +0100 Subject: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses In-Reply-To: <387d2b93-cb8b-51be-a6e0-3b5f9d6cbb1c@redhat.com> References: <387d2b93-cb8b-51be-a6e0-3b5f9d6cbb1c@redhat.com> Message-ID: <211c2faf-c6fc-5d7b-0426-1d96b4e6627e@redhat.com> > Currently, there's lots of GC specific code sprinkled over > src/hotspot/share/services. This change introduces a GC interface for > that, and moves all GC specific code to their respective > src/hotspot/share/gc directory. > > http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/ > > > Testing: hotspot_gc and hotspot_serviceability, none showed regressions > > Built minimal and server without regressions > > What do you think? > Ping? Roman From sundararajan.athijegannathan at oracle.com Tue Nov 21 14:06:20 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 21 Nov 2017 19:36:20 +0530 Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException In-Reply-To: <84288f14-2283-4ea4-b152-28762c27237b@default> References: <84288f14-2283-4ea4-b152-28762c27237b@default> Message-ID: <5A1432DC.5030307@oracle.com> +1 -Sundar On 21/11/17, 12:26 PM, Sharath Ballal wrote: > > Gentle reminder. > > Thanks, > > Sharath > > *From:* Sharath Ballal > *Sent:* Tuesday, November 14, 2017 10:31 AM > *To:* serviceability-dev at openjdk.java.net > *Subject:* RFR: JDK-8184982 - SA: Running ClassDump on a simple java > program generates NullPointerException > > Hello, > > Pls review the code changes and testcase for the following issue. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 > > Webrev: http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ > > > Thanks, > > Sharath > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundararajan.athijegannathan at oracle.com Tue Nov 21 14:07:41 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 21 Nov 2017 19:37:41 +0530 Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException In-Reply-To: References: <84288f14-2283-4ea4-b152-28762c27237b@default> Message-ID: <5A14332D.2060002@oracle.com> +1 -Sundar On 21/11/17, 3:26 PM, Sharath Ballal wrote: > > I have made minor modification to the test (added @bug and removed > @modules). > > The revised webrev is > > http://cr.openjdk.java.net/~sballal/8184982/webrev.01/ > > > Thanks, > > Sharath > > *From:* Sharath Ballal > *Sent:* Tuesday, November 21, 2017 12:27 PM > *To:* serviceability-dev at openjdk.java.net > *Subject:* RE: RFR: JDK-8184982 - SA: Running ClassDump on a simple > java program generates NullPointerException > > Gentle reminder. > > Thanks, > > Sharath > > *From:* Sharath Ballal > *Sent:* Tuesday, November 14, 2017 10:31 AM > *To:* serviceability-dev at openjdk.java.net > > *Subject:* RFR: JDK-8184982 - SA: Running ClassDump on a simple java > program generates NullPointerException > > Hello, > > Pls review the code changes and testcase for the following issue. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 > > Webrev: http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ > > > Thanks, > > Sharath > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Nov 21 14:46:10 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 09:46:10 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <56ab19ad-58d7-f65a-b29b-8503a8f6f72a@oracle.com> Hi Robin W! Welcome to the Thread-SMR party!! On 11/20/17 4:48 AM, Robin Westberg wrote: > Hi Dan, > > Overall I must say this looks very nice, can?t wait to use it! (Also a disclaimer: not a reviewer, and have not looked at the gc or jmvti specific changes nor the tests (yet)). Code reviews are always welcome (OpenJDK role does not matter). > Didn?t spot any real issues, just a few small efficiency related things: > > src/hotspot/share/runtime/biasedLocking.cpp > > 217 for (JavaThread* cur_thread = Threads::first(); cur_thread != NULL; cur_thread = cur_thread->next()) { > 218 if (cur_thread == biased_thread) { > 219 thread_is_alive = true; > > This loop could be replaced with: > > ThreadsListHandle tlh; > thread_is_alive = tlh.includes(biased_thread); Nice catch! Fixed with your proposed change. The careful reader will notice that in revoke_bias() we are not creating a ThreadsListHandle that is in scope for the entire function and we are doing cached monitor info walks without an obvious ThreadsListHandle in place. revoke_bias() is called at a safepoint from most locations. The one call that is not made at a safepoint is from BiasedLocking::revoke_and_rebias() and it is made by a JavaThread that is revoking a bias on itself which is also safe. We should add an assertion to revoke_bias() that looks something like this: ? assert(requesting_thread == Thread::current() || ???????? SafepointSynchronize::is_at_safepoint(), ???????? "must be operating on self or at a safepoint."); but we'll do that in a separate follow up bug since that will require biased locking focused testing. > src/hotspot/share/runtime/memprofiler.cpp > > 55-56 grabs the Threads_lock, shouldn?t be needed anymore. Nice catch! Deleting lines 55-56. > src/hotspot/share/runtime/thread.inline.hpp > > 198 TerminatedTypes l_terminated = (TerminatedTypes) > 199 OrderAccess::load_acquire((volatile jint *) &_terminated); > 200 return check_is_terminated(_terminated); > > The variable used in the return statement was intended to be l_terminated I guess? Ouch! Looks like JavaThread::is_exiting() is right, but JavaThread::is_terminated() has been inefficient all this time. Fixed. > The following are more minor suggestions / comments: > > src/hotspot/share/runtime/thread.cpp > > 3432 // operations over all threads. It is protected by its own Mutex > 3433 // lock, which is also used in other contexts to protect thread > > Should this comment perhaps be revised to mention SMR? It definitely needs some updating... Here's a stab at it: // The Threads class links together all active threads, and provides // operations over all threads. It is protected by the Threads_lock, // which is also used in other global contexts like safepointing. // ThreadsListHandles are used to safely perform operations on one // or more threads without the risk of the thread exiting during the // operation. // // Note: The Threads_lock is currently more widely used than we // would like. We are actively migrating Threads_lock uses to other // mechanisms in order to reduce Threads_lock contention. > 4745 hash_table_size--; > 4746 hash_table_size |= hash_table_size >> 1; > ... > > This calculation is repeated around line 4922 as well, perhaps put it in a function? The hash_table_size parameter is currently unused. We were using a different hash table before that allowed the size to be set. Unfortunately, that hash table didn't support being freed so we switched to ResourceHashtable. We have a project note to come back and update the underlying hash table to work with dynamic table sizes, but Erik hasn't had the cycles to do it yet. > 4828 // If someone set a handshake on us just as we entered exit path, we simple cancel it. > > Perhaps something like ?.. entered the exit path, we simply cancel it.? I went with this: ? if (ThreadLocalHandshakes) { ??? // The thread is about to be deleted so cancel any handshake. ??? thread->cancel_handshake(); ? } > src/hotspot/share/runtime/thread.hpp > > 1179 bool on_thread_list() { return _on_thread_list; } > 1180 void set_on_thread_list() { _on_thread_list = true; } > 1181 > 1182 // thread has called JavaThread::exit() or is terminated > 1183 bool is_exiting() const; > 1184 // thread is terminated (no longer on the threads list); we compare > 1185 // against the two non-terminated values so that a freed JavaThread > 1186 // will also be considered terminated. > 1187 bool check_is_terminated(TerminatedTypes l_terminated) const { > 1188 return l_terminated != _not_terminated && l_terminated != _thread_exiting; > 1189 } > 1190 bool is_terminated(); > > Use of const is inconsistent here, it?s added to 1183, should it perhaps be added to 1179 and 1190 as well then? Fixed. > src/hotspot/share/runtime/vm_operations.hpp > > 406 DeadlockCycle* result() { return _deadlocks; }; > 407 VMOp_Type type() const { return VMOp_FindDeadlocks; } > > Whitespace only change that seems spurious. Agreed. Restored to the original. Thanks for the review! Dan > > Best regards, > Robin > >> On 19 Nov 2017, at 02:49, Daniel D. Daugherty wrote: >> >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>> >>>> Changeset: fa736014cf28 >>>> Author: cjplummer >>>> Date: 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>> JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>> >>>> >>> From yasuenag at gmail.com Tue Nov 21 14:48:22 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 21 Nov 2017 23:48:22 +0900 Subject: PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached In-Reply-To: References: <192625c6-9c4a-8101-3411-f528f1264a00@oracle.com> <4b0be66f-e4ca-3a23-789f-0d2dfd065c5b@gmail.com> <072b8ea3-a71e-920f-2dfd-640f5866925c@oracle.com> <1e8a8944-3d53-63bc-bddf-576a923b2951@oracle.com> <1b4aced3-883e-7b2f-c2e1-29da98909559@oracle.com> <21673e0e-8766-288d-590f-10786cfdd95a@oracle.com> <37e7d134-5245-0c6e-5ac7-7231b978eb5a@oracle.com> <084b8cec-d25e-235d-29f1-f90b7ad448fc@gmail.com> <8f8f60b5-4494-6ea8-eded-98e8eef62626@gmail.com> <8749717a-f6d1-62c9-a2cc-427304ea5f35@gmail.com> Message-ID: Hi Serguei, On 2017/11/21 16:17, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > Thank you for the update. > > Some comments. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.04/src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java.frames.html > > 94 BufferedReader reader = new BufferedReader(new InputStreamReader(in)); > 95 try (reader) { A classic way for the above is: try (BufferedReader reader = new BufferedReader(new InputStreamReader(in))) { I fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.05/ > Also, I have a doubt about the change in HotSpotVirtualMachine.java: > > private void loadAgentLibrary(String agentLibrary, boolean isAbsolute, String options) > throws AgentLoadException, AgentInitializationException, IOException > { > + String msgPrefix = "return code: "; > InputStream in = execute("load", > agentLibrary, > isAbsolute ? "true" : "false", > options); > - try { > - int result = readInt(in); > - if (result != 0) { > - throw new AgentInitializationException("Agent_OnAttach failed", result); > + BufferedReader reader = new BufferedReader(new InputStreamReader(in)); > + try (reader) { > + String result = reader.readLine(); > + if (result == null) { > + throw new AgentLoadException("Target VM did not respond"); > + } else if (result.startsWith(msgPrefix)) { > + int retCode = Integer.parseInt(result.substring(msgPrefix.length())); > + if (retCode != 0) { > + throw new AgentInitializationException("Agent_OnAttach failed", retCode); > + } > + } else { > + throw new AgentLoadException(result); > } > - } finally { > - in.close(); > - > } > } > > > Now the AgentLoadException is thrown where it was not before. So that there is a change in behavior. > On the other hand the AgentLoadException was already specified to be thrown by the loadAgentLibrary. > I wonder, if this is worth to file a CSR for this. IMHO this change need not to CSR because the spec is not changed. (AgentLoadException is already added to `throws`.) I've not changed method signature in HotSpotVirtualMachine.java . Thanks, Yasumasa > Thanks, > Serguei > > > On 11/19/17 23:54, Yasumasa Suenaga wrote: >> Hi David, >> >> >>> My own feeling is that it is up to the OnAttach function to properly deal with pending exceptions: report and/or clear them. The VM side just has to clear any pending exception to avoid it causing problems for later code. >> >> I removed the change to print pending exceptions in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.04/ >> >> >>> test/jdk/com/sun/tools/attach/StartManagementAgent.java >>> >>> The reporting of NumberFormatException may be accurate in terms of the low-level exception, but "Invalid com.sun.management.jmxremote.port number" was much clearer. This makes me wonder about whether the code that previously produced "Invalid com.sun.management.jmxremote.port number" needs updating if this change proceeds. (And alao makes me wonder about the impact of the change in general.) >> >> I tested StartManagementAgent.java without this change, and I got failure as below: >> -------------- >> JavaTest Message: Test threw exception: com.sun.tools.attach.AttachOperationFailedE >> xception: java.lang.RuntimeException: jdk.internal.agent.AgentConfigurationError: j >> ava.lang.NumberFormatException: For input string: "apa" >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: com.sun.tools.attach.AttachOperationFailedExc >> eption: java.lang.RuntimeException: jdk.internal.agent.AgentConfigurationError: jav >> a.lang.NumberFormatException: For input string: "apa" >> -------------- >> >> Should we change this testcase whatever this change is not accepted? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/11/20 6:41, David Holmes wrote: >>> Hi Yasumasa, >>> >>> I've been trying to leave these reviews to serviceability folk ... >>> >>> I've gone back through the original RFR from September last year to see what we did and what was left. >>> >>> The current proposal raises some concern for me - and IIRC Dmitry was also concerned about it last time: printing of the pending exception. If we print the pending exception we will report an error and throw AgentLoadException, even if execution of the OnAttach function returned JNI_OK. If that exception was not critical to the success of the loading the agent, and the agent was just sloppy about clearing it, then it will now fail to load - which would be a compatibility concern. >>> >>> Further, if the exception indicates an error and the OnAttach function returns JNI_ERR then we won't report that cleanly because the printing of the exception will prevent matching with "return code: -1". >>> >>> My own feeling is that it is up to the OnAttach function to properly deal with pending exceptions: report and/or clear them. The VM side just has to clear any pending exception to avoid it causing problems for later code. >>> >>> Some specific comments: >>> >>> HotSpotVirtualMachine.java >>> >>> The regex code seems overkill for the basic parsing you are doing. You just need to see if the strings starts with "return code: " and then parse the next bit as an integer to get the return code. >>> >>> --- >>> >>> ??test/jdk/com/sun/tools/attach/StartManagementAgent.java >>> >>> The reporting of NumberFormatException may be accurate in terms of the low-level exception, but "Invalid com.sun.management.jmxremote.port number" was much clearer. This makes me wonder about whether the code that previously produced "Invalid com.sun.management.jmxremote.port number" needs updating if this change proceeds. (And alao makes me wonder about the impact of the change in general.) >>> >>> --- >>> >>> Sorry - not the quick second review you were looking for. >>> >>> David >>> ----- >>> >>> On 19/11/2017 11:38 PM, Yasumasa Suenaga wrote: >>>> PING: >>>> >>>> Could you review it? >>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ >>>> >>>> I want to merge this change to jdk 10. So I need a second reviewer. >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> On 2017/11/16 21:09, Yasumasa Suenaga wrote: >>>>> Hi David, Serguei, >>>>> >>>>>>> The test logic is adding it in AttachFailedTestBase.java: >>>>>>> >>>>>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>>>>>> ? 46???????????????????? .toAbsolutePath() >>>>>>> ? 47???????????????????? .toString(); >>>>> >>>>> Thanks! >>>>> I've fixed it in new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/ >>>>> >>>>> >>>>> I've tested it as below. It works fine: >>>>> >>>>> $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>>>> $ echo $NATIVE_PATH >>>>> //images/test/hotspot/jtreg/native >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote: >>>>>> On 11/15/17 23:29, David Holmes wrote: >>>>>>> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> On 11/15/17 18:11, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' >>>>>>>>> >>>>>>>>> There should not be any "/lib/" in that path >>>>>>>> >>>>>>>> Right, it should not be. >>>>>>> >>>>>>> The test logic is adding it in AttachFailedTestBase.java: >>>>>>> >>>>>>> ? 45???????? return Paths.get(System.getProperty("test.nativepath"), "lib", libname) >>>>>>> ? 46???????????????????? .toAbsolutePath() >>>>>>> ? 47???????????????????? .toString(); >>>>>>> >>>>>>> but it shouldn't. >>>>>> >>>>>> Nice catch! >>>>>> I looked right to these lines and overlooked it. :) >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> This is the script I'm using to run the tests: >>>>>>>> >>>>>>>> #!/bin/sh >>>>>>>> >>>>>>>> REPO=/var/tmp/sspitsyn/jdk.attach >>>>>>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images >>>>>>>> export JAVA_HOME=${IMAGES}/jdk >>>>>>>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native >>>>>>>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native >>>>>>>> echo "JAVA_HOME = $JAVA_HOME" >>>>>>>> >>>>>>>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg -nativepath:${NATIVE_PATH} \ >>>>>>>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed >>>>>>>> >>>>>>>> >>>>>>>> This is a part of log with the reported error from the AttachException.jtr: >>>>>>>> >>>>>>>> [TestNG] Running: >>>>>>>> serviceability/dcmd/jvmti/AttachFailed/AttachException.java >>>>>>>> >>>>>>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>> Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 8689, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]' >>>>>>>> Command returned with exit code 0 >>>>>>>> ---------------- stdout ---------------- >>>>>>>> 8689: >>>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so was not loaded. >>>>>>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: cannot open shared object file: No such file or directory >>>>>>>> >>>>>>>> >>>>>>>> These are the locations of the libException.so: >>>>>>>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so >>>>>>>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so >>>>>>>> >>>>>>>> >>>>>>>> The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native" >>>>>>>> but pass with the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native". >>>>>>>> >>>>>>>> >>>>>>>> When the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used >>>>>>>> the log has this line: >>>>>>>> >>>>>>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' through 'JMXExecutor' >>>>>>>> >>>>>>>> >>>>>>>> Apparently, the sub-directory name "/lib" is added to the path. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Yasumasa and David, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/15/17 04:56, David Holmes wrote: >>>>>>>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>>>>> >>>>>>>>>>>> Of course. >>>>>>>>>>>> It seems not to exist jtreg native libraries. >>>>>>>>>>>> I've tested as below: >>>>>>>>>>>> >>>>>>>>>>>> ?? $ make build-test-hotspot-jtreg-native >>>>>>>>>>>> ?? $ cd test >>>>>>>>>>>> ?? $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath://support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> I missed to add the -nativepath flag, sorry. >>>>>>>>>> >>>>>>>>>>> Please check that: >>>>>>>>>>> >>>>>>>>>>> make test-image >>>>>>>>>>> >>>>>>>>>>> followed by jtreg -nativepath:/images/test/hotspot/jtreg/native >>>>>>>>>>> >>>>>>>>>>> also works. >>>>>>>>>> >>>>>>>>>> It fails with the error: >>>>>>>>>> >>>>>>>>>> ?? 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>>>> ?? 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]' >>>>>>>>>> ?? 65 Command returned with exit code 0 >>>>>>>>>> ?? 66 ---------------- stdout ---------------- >>>>>>>>>> ?? 67 28407: >>>>>>>>>> ?? 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded. >>>>>>>>>> ?? 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>>>> ?? 70 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It seems, the '/lib' folder is added to the nativepath. >>>>>>>>>> >>>>>>>>>> Yasumasa, could you, double check it please? >>>>>>>>>> >>>>>>>>>> I'm using the jtreg: >>>>>>>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg >>>>>>>>>> >>>>>>>>>> which is: >>>>>>>>>> >>>>>>>>>> % ls -l /java/re/jtreg/4.2/promoted/latest >>>>>>>>>> lrwxrwxrwx 1 uucp 143 7 Nov? 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> Do the new tests pass in your runs? >>>>>>>>>>>>> >>>>>>>>>>>>> In my runs 3 of 4 tests are failed with the errors like this: >>>>>>>>>>>>> >>>>>>>>>>>>> ??109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor' >>>>>>>>>>>>> ??110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]' >>>>>>>>>>>>> ??111 Command returned with exit code 0 >>>>>>>>>>>>> ??112 ---------------- stdout ---------------- >>>>>>>>>>>>> ??113 21951: >>>>>>>>>>>>> ??114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded. >>>>>>>>>>>>> ??115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory >>>>>>>>>>>>> ??116 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Good news is that the attach-related tests from closed repository are passed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> It looks good to me. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>>>>> I've changed to check exception name (NumberFormatException) in >>>>>>>>>>>>>>> StartManagementAgent.java. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> I'm waiting for second reviewer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com >>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The changes looks good. >>>>>>>>>>>>>>>>>> Thank you for making them! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thank you for your comment! >>>>>>>>>>>>>>>>>>> I uploaded new webrev: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "ex" is AttachOperationFailedException. >>>>>>>>>>>>>>>>>>> We can get the result as below when we run StartManagementAgent: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port >>>>>>>>>>>>>>>>>>> number: apa >>>>>>>>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError: >>>>>>>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa" >>>>>>>>>>>>>>>>>>> [runApplication]??????? at >>>>>>>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336) >>>>>>>>>>>>>>>>>>> ------------- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think we should check exception message in >>>>>>>>>>>>>>>>>>> AttachOperationFailedException. >>>>>>>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For >>>>>>>>>>>>>>>>>> input string: "apa". >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Should we remove this comparison? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't understand. Why do remove? >>>>>>>>>>>>>>>> Would it better to check for the exception name instead? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've tested the following testcases: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>>>> ?? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>>>> ?? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There are more tests related to dynamic attach in closed, >>>>>>>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist. >>>>>>>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 testing levels. >>>>>>>>>>>>>>>>>> Will need to check. >>>>>>>>>>>>>>>>>> We have to make sure these tests are still passed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle >>>>>>>>>>>>>>>>> employee. >>>>>>>>>>>>>>>>> Can you run them with this change? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ok. >>>>>>>>>>>>>>>> I will sponsor this fix and run these tests before the push. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It seems, another update and one more review is needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Some comments. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid >>>>>>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) { >>>>>>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) { >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? What is the motivation for this change? >>>>>>>>>>>>>>>>>>>> ??? It seems, the original comparison is better. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? 37???? public void run(CommandExecutor executor) { >>>>>>>>>>>>>>>>>>>> ??? 38???????? try{ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? A space is missed after 'try'. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> ??? It is odd that all test java classes define exactly the same >>>>>>>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli(). >>>>>>>>>>>>>>>>>>>> ??? Would it better to defin a common base class with these methods? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Otherwise, it looks good. >>>>>>>>>>>>>>>>>>>> Thank you for taking care about it! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> PING: Could you review and sponsor it? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >>>>>>>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it implies error >>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd. >>>>>>>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output >>>>>>>>>>>>>>>>>>>>>> from target VM. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to >>>>>>>>>>>>>>>>>>>>>> understand the cause of failure. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg >>>>>>>>>>>>>>>>>>>>>> testcases: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/attach >>>>>>>>>>>>>>>>>>>>>> ??? - hotspot/jtreg/serviceability/dcmd/jvmti >>>>>>>>>>>>>>>>>>>>>> ??? - jdk/com/sun/tools/attach >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>> (I cannot test it on other platforms.) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> > From sharath.ballal at oracle.com Tue Nov 21 16:10:53 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 21 Nov 2017 08:10:53 -0800 (PST) Subject: RFR: JDK-8191658 - SA: Testcases for attach, detach, reattach and Jhisto commands Message-ID: <77f92823-69a4-4566-bbaf-6b4b4f34a04b@default> Hello, Pls review changes for the following issue: Bug ID: https://bugs.openjdk.java.net/browse/JDK-8191658 Webrev: http://cr.openjdk.java.net/~sballal/8191658/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Nov 21 16:28:56 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 11:28:56 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> Hi Coleen! Thanks for making time to review the Thread-SMR stuff again!! I have added back the other three OpenJDK aliases... This review is being done on _four_ different OpenJDK aliases. As always, replies are embedded below... On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html > > > I read David's comments about the threads list iterator, and I was > going to say that it can be cleaned up later, as the bulk of the > change is the SMR part but this looks truly bizarre.?? It looks like > it shouldn't compile because 'jt' isn't in scope. > > Why isn't this the syntax: > > JavaThreadIteratorWithHandle jtiwh; > for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { > } > > Which would do the obvious thing without anyone having to squint at > the code. See my reply to David's review for the more detailed answer. For the above syntax, we would need braces to limit the scope of the 'jtiwh' variable. With Stefan's propsal, you get limited scope on 'jtiwh' for "free". > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html > > > As a hater of acronmys, can this file use "Safe Memory Reclaimation" I'm not sure what you mean by this. Do you mean rename the files? ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp > and briefly describe the concept in the beginning of the header file, > so one knows why it's called threadSMR.hpp? And then this part of the sentence kind of indicates that you would be okay with the threadSMR.{c,h}pp names if a comment was added to the header file. Please clarify. > It doesn't need to be long and include why Threads list needs this > Sometimes we tell new people that the hotspot documentation is in the > header files. Yup. When I migrated stuff from thread.hpp and thread.cpp to threadSMR.hpp and threadSMR.cpp, I should have written a header comment... I did update a comment in thread.cpp based on Robin W's code review: > > src/hotspot/share/runtime/thread.cpp > > > > 3432 // operations over all threads.? It is protected by its own Mutex > > 3433 // lock, which is also used in other contexts to protect thread > > > > Should this comment perhaps be revised to mention SMR? > > It definitely needs some updating... Here's a stab at it: > > // The Threads class links together all active threads, and provides > // operations over all threads. It is protected by the Threads_lock, > // which is also used in other global contexts like safepointing. > // ThreadsListHandles are used to safely perform operations on one > // or more threads without the risk of the thread exiting during the > // operation. > // > // Note: The Threads_lock is currently more widely used than we > // would like. We are actively migrating Threads_lock uses to other > // mechanisms in order to reduce Threads_lock contention. I'll take a look at adding a header comment to threadSMR.hpp. > 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} > > This _tlh() call should not be necessary.? The compiler should > generate this for you in the constructor. Deleted. > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html > > > ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), > _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), > _next_list(NULL) { > > Seems like it should be mtThread rather than mtGC. Fixed. Definitely an artifact of Erik's original prototype when he extracted Thread-SMR from his GC work... Thanks for catching it. > Should > > ? 62?? if (EnableThreadSMRStatistics) { > > really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? EnableThreadSMRStatistics is used in more places than UL code. We use it in Thread::print_*() stuff to control output of Thread-SMR statistics info in thread dumps and hs_err_pid file generation. Currently thread dump and hs_err_pid file output is not generated using UL (and probably can't be?) so we need an option to control the Thread-SMR statistics stuff in all places. > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html > > > Can you use for these tests instead (there were a couple): > > *@requires (vm.debug == true)* The test I cloned had this in it: ??? if (!Platform.isDebugBuild()) { ??????? // -XX:ErrorHandlerTest=N option requires debug bits. ??????? return; ??? } and you would like me to switch to the newer mechanism? I have updated the following tests: ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html > > > +// thread, has been added the Threads list, the system is not at a > > Has "not" been added to the Threads list?? missing "not"? Nope. If the JavaThread has been added to the Threads list and it is not protected, then it is dangling. In other words, a published JavaThread (on the Threads list) has to be protected by either the system being at a safepoint or the JavaThread has to be on some threads's ThreadsList. > > + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); > > Can you add a comment about where this number came from? I'll have to get that from Erik... > I can't find the caller of threads_do_smr. I'm guessing that's used by the GC code that depends on Thread-SMR... > If these functions xchg_smr_thread_list, get_smr_java_thread_list, > inc_smr_deleted_thread_count are only used by thread.cpp, I think they > should go in that file and not in the .inline.hpp file to be included > and possibly called by other files.? I think they're private to class > Threads. I have a vague memory that some of the compilers don't do inlining when an "inline" function is in a .cpp. I believe we want these functions to be inlined for performance reasons. Erik should probably chime in here. > I don't have any in-depth comments.? This looks really good from my > day of reading it. Thanks for taking the time to review it again! Dan > > Thanks, > Coleen > > On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: > >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up >>> thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from >>>> within hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>> holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>> closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to >>>>>> use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>> describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > From coleen.phillimore at oracle.com Tue Nov 21 17:24:11 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Nov 2017 12:24:11 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> Message-ID: <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: > Hi Coleen! > > Thanks for making time to review the Thread-SMR stuff again!! > > I have added back the other three OpenJDK aliases... This review is > being done on _four_ different OpenJDK aliases. > > As always, replies are embedded below... > > > On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html >> >> >> I read David's comments about the threads list iterator, and I was >> going to say that it can be cleaned up later, as the bulk of the >> change is the SMR part but this looks truly bizarre.?? It looks like >> it shouldn't compile because 'jt' isn't in scope. >> >> Why isn't this the syntax: >> >> JavaThreadIteratorWithHandle jtiwh; >> for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { >> } >> >> Which would do the obvious thing without anyone having to squint at >> the code. > > See my reply to David's review for the more detailed answer. > > For the above syntax, we would need braces to limit the scope of the > 'jtiwh' variable. With Stefan's propsal, you get limited scope on > 'jtiwh' for "free". Yes, thank you, I see that motivation now. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html >> >> >> As a hater of acronmys, can this file use "Safe Memory Reclaimation" > > I'm not sure what you mean by this. Do you mean rename the files? > > ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp > ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp > No. > >> and briefly describe the concept in the beginning of the header file, >> so one knows why it's called threadSMR.hpp? > > And then this part of the sentence kind of indicates that you would be > okay with the threadSMR.{c,h}pp names if a comment was added to the > header file. > > Please clarify. Yes.? If you added a comment to the beginning of the threadSMR.hpp file that said what SMR stood for and what it was, that would be extremely helpful for future viewers of this file. > > >> It doesn't need to be long and include why Threads list needs this >> Sometimes we tell new people that the hotspot documentation is in the >> header files. > > Yup. When I migrated stuff from thread.hpp and thread.cpp to > threadSMR.hpp > and threadSMR.cpp, I should have written a header comment... > > I did update a comment in thread.cpp based on Robin W's code review: Yes, I think a comment belongs in the SMR file also, or in preference. > >> > src/hotspot/share/runtime/thread.cpp >> > >> > 3432 // operations over all threads.? It is protected by its own Mutex >> > 3433 // lock, which is also used in other contexts to protect thread >> > >> > Should this comment perhaps be revised to mention SMR? >> >> It definitely needs some updating... Here's a stab at it: >> >> // The Threads class links together all active threads, and provides >> // operations over all threads. It is protected by the Threads_lock, >> // which is also used in other global contexts like safepointing. >> // ThreadsListHandles are used to safely perform operations on one >> // or more threads without the risk of the thread exiting during the >> // operation. >> // >> // Note: The Threads_lock is currently more widely used than we >> // would like. We are actively migrating Threads_lock uses to other >> // mechanisms in order to reduce Threads_lock contention. > > I'll take a look at adding a header comment to threadSMR.hpp. > > >> 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} >> >> This _tlh() call should not be necessary.? The compiler should >> generate this for you in the constructor. > > Deleted. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >> >> >> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >> _next_list(NULL) { >> >> Seems like it should be mtThread rather than mtGC. > > Fixed. Definitely an artifact of Erik's original prototype when he > extracted Thread-SMR from his GC work... Thanks for catching it. > > >> Should >> >> ? 62?? if (EnableThreadSMRStatistics) { >> >> really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? > > EnableThreadSMRStatistics is used in more places than UL code. > We use it in Thread::print_*() stuff to control output of > Thread-SMR statistics info in thread dumps and hs_err_pid file > generation. That sort of thing is also controlled by logging in general. > > Currently thread dump and hs_err_pid file output is not generated > using UL (and probably can't be?) so we need an option to control > the Thread-SMR statistics stuff in all places. > You can use log options in preference to this new diagnostic option in these cases too.?? This option looks a lot like logging to me and would be nice to not have to later convert it. > > >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html >> >> >> Can you use for these tests instead (there were a couple): >> >> *@requires (vm.debug == true)* > > The test I cloned had this in it: > > ??? if (!Platform.isDebugBuild()) { > ??????? // -XX:ErrorHandlerTest=N option requires debug bits. > ??????? return; > ??? } > > and you would like me to switch to the newer mechanism? > > I have updated the following tests: > > ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java > test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java > > test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java > > > Yes, the newer mechanism makes jtreg not bother to run the test, which makes it faster! >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html >> >> >> +// thread, has been added the Threads list, the system is not at a >> >> Has "not" been added to the Threads list?? missing "not"? > > Nope. If the JavaThread has been added to the Threads list > and it is not protected, then it is dangling. In other words, > a published JavaThread (on the Threads list) has to be protected > by either the system being at a safepoint or the JavaThread has > to be on some threads's ThreadsList. > > >> >> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >> >> Can you add a comment about where this number came from? > > I'll have to get that from Erik... > > >> I can't find the caller of threads_do_smr. > > I'm guessing that's used by the GC code that depends on Thread-SMR... > They? should add this API when the add the use of it then.? I don't see it in any sources. > >> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >> inc_smr_deleted_thread_count are only used by thread.cpp, I think >> they should go in that file and not in the .inline.hpp file to be >> included and possibly called by other files.? I think they're private >> to class Threads. > > I have a vague memory that some of the compilers don't do inlining when > an "inline" function is in a .cpp. I believe we want these functions > to be inlined for performance reasons. Erik should probably chime in > here. I don't see why this should be.? Maybe some (older) compilers require it to be found before the call though, but that can still be accomplished in the .cpp file. > > >> I don't have any in-depth comments.? This looks really good from my >> day of reading it. > > Thanks for taking the time to review it again! > Thanks, Coleen > Dan > > >> >> Thanks, >> Coleen >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >> >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>> and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with >>>> Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we >>>> think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more >>>> major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>> and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>> done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>> to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>> and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Nov 21 17:30:52 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 12:30:52 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <9cc8b08b-f373-f493-4429-662d18ff81ad@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <43d2f342-3f4b-5c1a-a687-c24c4efedba9@oracle.com> <92d1f572-a745-6f2b-1b5f-e68a1d252bab@oracle.com> <9cc8b08b-f373-f493-4429-662d18ff81ad@oracle.com> Message-ID: Adding back the missing OpenJDK aliases... On 11/21/17 11:14 AM, coleen.phillimore at oracle.com wrote: > > > On 11/20/17 8:50 PM, Daniel D. Daugherty wrote: >> On 11/20/17 12:51 AM, David Holmes wrote: >>> Hi Dan, >>> >>> Figured I'd better cast an eye over this again before it gets pushed :) >> >> Thanks for reviewing again!! >> >> >>> Only one thing (repeated many times) jumped out at me and apologies >>> if this has already been debated back and forth. I missed the >>> exchange where the for loop iteration was rewritten into this >>> unusual form: >>> >>> for (JavaThreadIteratorWithHandle jtiwh; JavaThread *jt = >>> jtiwh.next(); ) { >>> >>> On first reading I expect most people would mistake the control >>> expression for the iteration-expression due to the next(). I didn't >>> even know the control expression could introduce a local variable! I >>> find this really hard to read stylistically and far too cute/clever >>> for its own good. It also violates the style rules regarding >>> implicit boolean checks. >>> >>> I know Stefan proposed this as he did not like the alternate (in a >>> few places): >>> >>> +? { >>> +??? ThreadsListHandle tlh; >>> +??? JavaThreadIterator jti(tlh.list()); >>> +??? for (JavaThread* t = jti.first(); t != NULL; t = jti.next()) { >>> ... >>> +? } >>> >>> but it seems to me the iterator code has evolved since then and only >>> a couple of places need a distinct TLH separate from the actual >>> iterator object. So I'm more in favour of the more classic for-loop, >>> with the iterator declared before the loop. Or even convert to while >>> loops, as this iterator seems more suited to that. >> >> Actually both Coleen and Stefan had a problem with how much additional >> code was added to support an iterator model. In some cases we went from >> 1-line to 3-lines and in some cases we went from 1-line to 5-lines. For >> Coleen, she wanted 2 of the new lines compressed into 1 new line by >> using >> an iterator with an embedded ThreadsListHandle. Stefan wanted us to try >> and get back to 1-line where possible. >> >> The advantages of the new style are: >> >> - 1-line to 1-line in all but a few cases >> - automatic limited scope of the embedded ThreadsListHandle so we were >> ? able to remove extra braces that were added earlier in most cases >> >> The disadvantages of the new style are: >> >> - it is an unusual for-loop style (in HotSpot) >> - it breaks HotSpot's style rule about implied booleans >> >> >> Stefan K is pretty adamant that the original iterator version where we >> go from 1-line to 3-lines or 1-line to 5-lines is not acceptable for GC >> code. The compiler guys haven't chimed in on this debate so I'm guessing >> they don't have a strong opinion either way. One thing that we don't >> want >> to do is have different styles for the different teams. >> >> So I had to make a judgement call on whether I thought Runtime could >> live >> with Stefan's idea. Originally I wasn't fond of it either and >> breaking the >> implied boolean style rule is a problem for me (I post that comment a >> lot >> in my code reviews). However, I have to say that I'm a lot happier about >> the compactness of the code and the fact that limited ThreadsListHandle >> scope comes for 'free' in most cases. >> >> We're planning to keep the new iterator style for the following reasons: >> >> - smaller change footprint >> - consistent style used for all of the teams >> - limited ThreadsListHandle scope comes for free in most cases >> >> We're hoping that you can live with this decision (for now) and maybe >> even grow to like it in the future. :-) > > The limited ThreadsListHandle scope, since ThreadsListHandle registers > and unregisters lists to SMR, seems to be worth the cost of looking at > this strange code pattern.?? Thank you for the explanation. > >> >> >>> Other than that just a couple of comments on variable type choices, >>> and a few typos spotted below. >> >> Replies embedded below. >> >> >>> >>> Thanks, >>> David >>> --- >>> >>> src/hotspot/share/runtime/globals.hpp >>> >>> 2476?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true, >>> ??????? \ >>> 2477?????????? "Enable Thread SMR extra validity checks") \ >>> 2478 ??????? \ >>> 2479?? diagnostic(bool, EnableThreadSMRStatistics, true, \ >>> 2480?????????? "Enable Thread SMR Statistics") ??????? \ >>> >>> Indent of strings is off by? 3 spaces. >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/handshake.cpp >>> >>> ?140?????? // There is assumption in code that Threads_lock should >>> be lock >>> ?200?????? // There is assumption in code that Threads_lock should >>> be lock >>> >>> lock -> locked >> >> Fixed. >> >> >>> 146???????? // handshake_process_by_vmthread will check the >>> semaphore for us again >>> >>> Needs period at end. >> >> Fixed. >> >> >>> 148???????? // should be okey since the new thread will not have an >>> operation. >>> >>> okey -> okay >> >> Fixed. >> >> >>> 151???????? // We can't warn here is since the thread do >>> cancel_handshake after it have been removed >>> >>> I think: >>> >>> // We can't warn here since the thread does cancel_handshake after >>> it has been removed >> >> Fixed. >> >> >>> 152???????? // from ThreadsList. So we should just keep looping here >>> until while below return negative. >>> >>> from -> from the >>> >>> Needs period at end. >> >> Fixed both. >> >> >>> >>> ?204???????????? // A new thread on the ThreadsList will not have an >>> operation. >>> >>> Change period to comma, and ... >> >> Fixed. >> >> >>> 205???????????? // Hence is skipped in handshake_process_by_vmthread. >>> >>> Hence is -> hence it is >> >> Fixed. >> >> >>> --- >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 1482???? // dcubed - Looks like the Threads_lock is for stable access >>> 1483???? // to _jvmci_old_thread_counters and _jvmci_counters. >>> >>> Does this comment need revisiting? >> >> We've been trying to decide what to do about this comment. We'll be >> filing a follow up bug for the Compiler team to take another look at >> how _jvmci_old_thread_counters and _jvmci_counters are protected. >> Threads_lock is a big hammer and there should be a less expensive >> solution. Once that bug gets filed, this comment can go away. >> >> >>> 3451 volatile jint ... >>> >>> Why are you using jint for field types here? (Surprised Coleen >>> hasn't spotted them! ;-) ). > > Yes, it was the jtypes I would have objected to.? And long isn't a > good choice on windows because it's only 32 bits there. >> >> volatile jint???????? Threads::_smr_delete_notify = 0; >> volatile jint???????? Threads::_smr_deleted_thread_cnt = 0; >> volatile jint???????? Threads::_smr_deleted_thread_time_max = 0; >> volatile jint???????? Threads::_smr_deleted_thread_times = 0; >> : >> volatile jint???????? Threads::_smr_tlh_cnt = 0; >> volatile jint???????? Threads::_smr_tlh_time_max = 0; >> volatile jint???????? Threads::_smr_tlh_times = 0; >> >> _smr_delete_notify is a "flag" that indicates when an _smr_delete_lock >> notify() operation is needed. It counts up and down and should be a >> fairly >> small number. >> >> _smr_deleted_thread_cnt counts the number of Threads that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_deleted_thread_time_max is the maximum time in millis it has >> taken to delete a thread. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_deleted_thread_times accumulates the time in millis that it >> has taken to delete threads. It's an always increasing number so >> it's size depends on how long the VM has been running. This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> _smr_tlh_cnt counts the number of ThreadsListHandles that have been >> deleted over the life of the VM. It's an always increasing number so >> it's size depends on how long the VM has been running. >> >> _smr_tlh_time_max is the maximum time in millis it has taken to >> delete a ThreadsListHandle. This field was originally a jlong, but >> IIRC the Atomic::cmpxchg() code was not happy on ARM... (might have >> just been Atomic::add() that was not happy) >> >> _smr_tlh_times? accumulates the time in millis that it has taken to >> delete ThreadsListHandles. It's an always increasing number so >> it's size depends on how long the VM has been running.? This field >> was originally a jlong, but IIRC the Atomic::add() code was not >> happy on ARM... (might have just been Atomic::cmpxchg() that was >> not happy) >> >> >> It just dawned on me that I'm not sure whether you think the 'jint' >> fields should be larger or smaller or the same size but a different >> type... :-) >> >> The fact that I had to write so much to explain what these fields >> are for and how they're used indicates I need more comments. See >> below... >> >> >>> 3456 long Threads::_smr_java_thread_list_alloc_cnt = 1; >>> 3457 long Threads::_smr_java_thread_list_free_cnt = 0; >>> >>> long? If you really want 64-bit counters here you won't get them on >>> Windows with that declaration. If you really want variable sized >>> counters I suggest uintptr_t; otherwise uint64_t. >> >> long????????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> long????????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> >> _smr_java_thread_list_alloc_cnt counts the number of ThreadsLists that >> have been allocated over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> _smr_java_thread_list_free_cnt counts the number of ThreadsLists that >> have been freed over the life of the VM. It's an always increasing >> number so it's size depends on how long the VM has been running and how >> many Threads have been created and destroyed. >> >> I can't remember why we chose 'long' and I agree it's not a good choice >> for Win*. >> >> >> Okay so it dawns on me that we haven't written down a description for >> the various new '_cnt', '_max' and '_times" fields so I'm adding these >> comments to thread.hpp: >> > > With this comment format, it's really hard to pick out the name of the > field.? Nobody uses 80 columns anymore.? Can you move the comments > over some spaces so the field names are visible? Yes, I'll update the patch that I have for dholmes CR resolutions. > >> ?private: >> ? // Safe Memory Reclamation (SMR) support: >> ? static Monitor*????????????? _smr_delete_lock; >> ? // The '_cnt', '_max' and '_times" fields are enabled via >> ? // -XX:+EnableThreadSMRStatistics: >> ?????????????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ? static uint????????????????? _smr_delete_lock_wait_cnt; >> ?????????????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ? static uint????????????????? _smr_delete_lock_wait_max; >> ?????????????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ? static volatile uint???????? _smr_delete_notify; >> ?????????????????????????????? // # of threads deleted over VM lifetime. >> ? static volatile uint???????? _smr_deleted_thread_cnt; >> ?????????????????????????????? // Max time in millis to delete a thread. >> ? static volatile uint???????? _smr_deleted_thread_time_max; >> ?????????????????????????????? // Cumulative time in millis to delete >> threads. >> ? static volatile uint???????? _smr_deleted_thread_times; >> ? static ThreadsList* volatile _smr_java_thread_list; >> ? static ThreadsList*????????? get_smr_java_thread_list(); >> ? static ThreadsList* xchg_smr_java_thread_list(ThreadsList* new_list); >> ?????????????????????????????? // # of ThreadsLists allocated over VM >> lifetime. >> ? static uint64_t????????????? _smr_java_thread_list_alloc_cnt; >> ?????????????????????????????? // # of ThreadsLists freed over VM >> lifetime. >> ? static uint64_t????????????? _smr_java_thread_list_free_cnt; >> ?????????????????????????????? // Max size ThreadsList allocated. >> ? static uint????????????????? _smr_java_thread_list_max; >> ?????????????????????????????? // Max # of nested ThreadsLists for a >> thread. >> ? static uint????????????????? _smr_nested_thread_list_max; >> ?????????????????????????????? // # of ThreadsListHandles deleted >> over VM lifetime. >> ? static volatile uint???????? _smr_tlh_cnt; >> ?????????????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ? static volatile jint???????? _smr_tlh_time_max; >> ?????????????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ? static volatile jint???????? _smr_tlh_times; >> ? static ThreadsList*????????? _smr_to_delete_list; >> ?????????????????????????????? // # of parallel ThreadsLists on the >> to-delete list. >> ? static uint????????????????? _smr_to_delete_list_cnt; >> ?????????????????????????????? // Max # of parallel ThreadsLists on >> the to-delete list. >> ? static uint????????????????? _smr_to_delete_list_max; >> >> >> I've also gone through all the new '_cnt', '_max' and '_times" fields >> in thread.cpp and added an impl note to explain the choice of type: >> > > Since this is in the cpp file and there is so much comment text, can > you just make it in column 1 and leave a blank line after each field.? > The indentation style is really hard to read and only useful if the > comment is short. Yes, I'll update the patch that I have for dholmes CR resolutions. > >> // Safe Memory Reclamation (SMR) support: >> Monitor*????????????? Threads::_smr_delete_lock = >> ????????????????????????? new Monitor(Monitor::special, >> "smr_delete_lock", >> ????????????????????????????????????? false /* allow_vm_block */, >> Monitor::_safepoint_check_never); >> // The '_cnt', '_max' and '_times" fields are enabled via >> // -XX:+EnableThreadSMRStatistics: >> ????????????????????? // # of parallel threads in >> _smr_delete_lock->wait(). >> ????????????????????? // Impl note: Hard to imagine > 64K waiting >> threads so >> ????????????????????? // this could be 16-bit, but there is no nice >> 16-bit >> ????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_delete_lock_wait_cnt = 0; >> ????????????????????? // Max # of parallel threads in >> _smr_delete_lock->wait(). >> ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> uint????????????????? Threads::_smr_delete_lock_wait_max = 0; >> ????????????????????? // Flag to indicate when an >> _smr_delete_lock->notify() is needed. >> ????????????????????? // Impl note: See _smr_delete_lock_wait_cnt note. >> volatile uint???????? Threads::_smr_delete_notify = 0; >> ????????????????????? // # of threads deleted over VM lifetime. >> ????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ????????????????????? // use unsigned for more range. Unsigned 64-bit >> would >> ????????????????????? // be more future proof, but 64-bit atomic inc >> isn't >> ????????????????????? // available everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_cnt = 0; >> ????????????????????? // Max time in millis to delete a thread. >> ????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_deleted_thread_time_max = 0; >> ????????????????????? // Cumulative time in millis to delete threads. >> ????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_deleted_thread_times = 0; >> ThreadsList* volatile Threads::_smr_java_thread_list = new >> ThreadsList(0); >> ????????????????????? // # of ThreadsLists allocated over VM lifetime. >> ????????????????????? // Impl note: We allocate a new ThreadsList for >> every >> ????????????????????? // thread create and every thread delete so we >> need a >> ????????????????????? // bigger type than the _smr_deleted_thread_cnt >> field. >> uint64_t????????????? Threads::_smr_java_thread_list_alloc_cnt = 1; >> ????????????????????? // # of ThreadsLists freed over VM lifetime. >> ????????????????????? // Impl note: See >> _smr_java_thread_list_alloc_cnt note. >> uint64_t????????????? Threads::_smr_java_thread_list_free_cnt = 0; >> ????????????????????? // Max size ThreadsList allocated. >> ????????????????????? // Impl note: Max # of threads alive at one >> time should >> ????????????????????? // fit in unsigned 32-bit. >> uint????????????????? Threads::_smr_java_thread_list_max = 0; >> ????????????????????? // Max # of nested ThreadsLists for a thread. >> ????????????????????? // Impl note: Hard to imagine > 64K nested >> ThreadsLists >> ????????????????????? // so his could be 16-bit, but there is no nice >> 16-bit >> ????????????????????? // _FORMAT support. >> uint????????????????? Threads::_smr_nested_thread_list_max = 0; >> ????????????????????? // # of ThreadsListHandles deleted over VM >> lifetime. >> ????????????????????? // Impl note: Atomically incremented over VM >> lifetime so >> ????????????????????? // use unsigned for more range. There will be >> fewer >> ????????????????????? // ThreadsListHandles than threads so unsigned >> 32-bit >> ????????????????????? // should be fine. >> volatile uint???????? Threads::_smr_tlh_cnt = 0; >> ????????????????????? // Max time in millis to delete a >> ThreadsListHandle. >> ????????????????????? // Impl note: 16-bit might be too small on an >> overloaded >> ????????????????????? // machine. Use unsigned since this is a time >> value. Set >> ????????????????????? // via Atomic::cmpxchg() in a loop for >> correctness. >> volatile uint???????? Threads::_smr_tlh_time_max = 0; >> ????????????????????? // Cumulative time in millis to delete >> ThreadsListHandles. >> ????????????????????? // Impl note: Atomically added to over VM >> lifetime so use >> ????????????????????? // unsigned for more range. Unsigned 64-bit >> would be more >> ????????????????????? // future proof, but 64-bit atomic inc isn't >> available >> ????????????????????? // everywhere (or is it?). >> volatile uint???????? Threads::_smr_tlh_times = 0; >> ThreadsList*????????? Threads::_smr_to_delete_list = NULL; >> ????????????????????? // # of parallel ThreadsLists on the to-delete >> list. >> ????????????????????? // Impl note: Hard to imagine > 64K >> ThreadsLists needing >> ????????????????????? // to be deleted so this could be 16-bit, but >> there is no >> ????????????????????? // nice 16-bit _FORMAT support. >> uint????????????????? Threads::_smr_to_delete_list_cnt = 0; >> ????????????????????? // Max # of parallel ThreadsLists on the >> to-delete list. >> ????????????????????? // Impl note: See _smr_to_delete_list_cnt note. >> uint????????????????? Threads::_smr_to_delete_list_max = 0; >> >> >> Yikes! With the additional comments, the additions to thread.hpp and >> thread.cpp grew by a bunch... I've done a test build build on my Mac >> with these changes and I'm about to kick off a Mach5 tier1 job... > > Another reason why I agreed with some earlier comment that this should > be in a new file because it's a new thing. I was somewhat surprised > that it's not in threadSMR.{hpp,cpp}.?? This refactoring could be > deferred but thread.cpp is too big! More refactoring is planned for after the initial push of Thread-SMR... Thanks for chiming in on this part of the review thread. Dan > > thanks, > Coleen > >> >> Dan >> >> >> >>> >>> ---- >>> >>> On 19/11/2017 11:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> > From daniel.daugherty at oracle.com Tue Nov 21 17:36:31 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 12:36:31 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> Message-ID: <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> Thanks for keeping all the OpenJDK aliases! On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: > > > On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >> Hi Coleen! >> >> Thanks for making time to review the Thread-SMR stuff again!! >> >> I have added back the other three OpenJDK aliases... This review is >> being done on _four_ different OpenJDK aliases. >> >> As always, replies are embedded below... >> >> >> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/os/linux/os_linux.cpp.frames.html >>> >>> >>> I read David's comments about the threads list iterator, and I was >>> going to say that it can be cleaned up later, as the bulk of the >>> change is the SMR part but this looks truly bizarre. It looks like >>> it shouldn't compile because 'jt' isn't in scope. >>> >>> Why isn't this the syntax: >>> >>> JavaThreadIteratorWithHandle jtiwh; >>> for (JavaThread* jt = jtiwh.first(); jt != NULL; jt = jtiwh.next()) { >>> } >>> >>> Which would do the obvious thing without anyone having to squint at >>> the code. >> >> See my reply to David's review for the more detailed answer. >> >> For the above syntax, we would need braces to limit the scope of the >> 'jtiwh' variable. With Stefan's propsal, you get limited scope on >> 'jtiwh' for "free". > > Yes, thank you, I see that motivation now. >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.hpp.html >>> >>> >>> As a hater of acronmys, can this file use "Safe Memory Reclaimation" >> >> I'm not sure what you mean by this. Do you mean rename the files? >> >> ? threadSMR.hpp -> threadSafeMemoryReclaimation.hpp >> ? threadSMR.cpp -> threadSafeMemoryReclaimation.cpp >> > > No. > >> >>> and briefly describe the concept in the beginning of the header file, >>> so one knows why it's called threadSMR.hpp? >> >> And then this part of the sentence kind of indicates that you would be >> okay with the threadSMR.{c,h}pp names if a comment was added to the >> header file. >> >> Please clarify. > > Yes.? If you added a comment to the beginning of the threadSMR.hpp > file that said what SMR stood for and what it was, that would be > extremely helpful for future viewers of this file. Yup. I just finished with the comment... > >> >> >>> It doesn't need to be long and include why Threads list needs this >>> Sometimes we tell new people that the hotspot documentation is in >>> the header files. >> >> Yup. When I migrated stuff from thread.hpp and thread.cpp to >> threadSMR.hpp >> and threadSMR.cpp, I should have written a header comment... >> >> I did update a comment in thread.cpp based on Robin W's code review: > > Yes, I think a comment belongs in the SMR file also, or in preference. Wasn't trying to say that I thought the update I did for Robin W was sufficient... >> >>> > src/hotspot/share/runtime/thread.cpp >>> > >>> > 3432 // operations over all threads.? It is protected by its own >>> Mutex >>> > 3433 // lock, which is also used in other contexts to protect thread >>> > >>> > Should this comment perhaps be revised to mention SMR? >>> >>> It definitely needs some updating... Here's a stab at it: >>> >>> // The Threads class links together all active threads, and provides >>> // operations over all threads. It is protected by the Threads_lock, >>> // which is also used in other global contexts like safepointing. >>> // ThreadsListHandles are used to safely perform operations on one >>> // or more threads without the risk of the thread exiting during the >>> // operation. >>> // >>> // Note: The Threads_lock is currently more widely used than we >>> // would like. We are actively migrating Threads_lock uses to other >>> // mechanisms in order to reduce Threads_lock contention. >> >> I'll take a look at adding a header comment to threadSMR.hpp. >> >> >>> 186?? JavaThreadIteratorWithHandle() : _tlh(), _index(0) {} >>> >>> This _tlh() call should not be necessary.? The compiler should >>> generate this for you in the constructor. >> >> Deleted. >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>> >>> >>> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>> _next_list(NULL) { >>> >>> Seems like it should be mtThread rather than mtGC. >> >> Fixed. Definitely an artifact of Erik's original prototype when he >> extracted Thread-SMR from his GC work... Thanks for catching it. >> >> >>> Should >>> >>> ? 62?? if (EnableThreadSMRStatistics) { >>> >>> really be UL, ie: if (log_is_enabled(Info, thread, smr, statistics)) ? >> >> EnableThreadSMRStatistics is used in more places than UL code. >> We use it in Thread::print_*() stuff to control output of >> Thread-SMR statistics info in thread dumps and hs_err_pid file >> generation. > > That sort of thing is also controlled by logging in general. Don't think I want to do that since logging may be be "up" at the time that I need Thread::print_*() or hs_err_pid generation... Something about chickens and eggs... :-) >> >> Currently thread dump and hs_err_pid file output is not generated >> using UL (and probably can't be?) so we need an option to control >> the Thread-SMR statistics stuff in all places. >> > > You can use log options in preference to this new diagnostic option in > these cases too.?? This option looks a lot like logging to me and > would be nice to not have to later convert it. See above reply... > >> >> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java.html >>> >>> >>> Can you use for these tests instead (there were a couple): >>> >>> *@requires (vm.debug == true)* >> >> The test I cloned had this in it: >> >> ??? if (!Platform.isDebugBuild()) { >> ??????? // -XX:ErrorHandlerTest=N option requires debug bits. >> ??????? return; >> ??? } >> >> and you would like me to switch to the newer mechanism? >> >> I have updated the following tests: >> >> ? test/hotspot/jtreg/runtime/ErrorHandling/ErrorHandler.java >> test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java >> >> test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java >> >> >> > Yes, the newer mechanism makes jtreg not bother to run the test, which > makes it faster! More quickly not run the test... Yup... got it... > >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/thread.cpp.udiff.html >>> >>> >>> +// thread, has been added the Threads list, the system is not at a >>> >>> Has "not" been added to the Threads list?? missing "not"? >> >> Nope. If the JavaThread has been added to the Threads list >> and it is not protected, then it is dangling. In other words, >> a published JavaThread (on the Threads list) has to be protected >> by either the system being at a safepoint or the JavaThread has >> to be on some threads's ThreadsList. >> >> >>> >>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>> >>> Can you add a comment about where this number came from? >> >> I'll have to get that from Erik... >> >> >>> I can't find the caller of threads_do_smr. >> >> I'm guessing that's used by the GC code that depends on Thread-SMR... >> > > They? should add this API when the add the use of it then.? I don't > see it in any sources. We'll see what Erik wants to do... > >> >>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >>> inc_smr_deleted_thread_count are only used by thread.cpp, I think >>> they should go in that file and not in the .inline.hpp file to be >>> included and possibly called by other files.? I think they're >>> private to class Threads. >> >> I have a vague memory that some of the compilers don't do inlining when >> an "inline" function is in a .cpp. I believe we want these functions >> to be inlined for performance reasons. Erik should probably chime in >> here. > > I don't see why this should be.? Maybe some (older) compilers require > it to be found before the call though, but that can still be > accomplished in the .cpp file. Again, we'll see what Erik wants to do... >> >> >>> I don't have any in-depth comments. This looks really good from my >>> day of reading it. >> >> Thanks for taking the time to review it again! >> > > Thanks, > Coleen And thanks again... Dan > >> Dan >> >> >>> >>> Thanks, >>> Coleen >>> >>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> >>>> Greetings, >>>> >>>> Testing of the last round of changes revealed a hang in one of the new >>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>> test, and >>>> added another TLH test for good measure. >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>> >>>> Here is the updated delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>>> >>>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>>> no unexpected failures. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Robbin rebased the project last night/this morning to merge with >>>>> Thread >>>>> Local Handshakes (TLH) and also picked up additional changesets up >>>>> thru: >>>>> >>>>>> Changeset: fa736014cf28 >>>>>> Author:??? cjplummer >>>>>> Date:????? 2017-11-14 18:08 -0800 >>>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>>> >>>>>> 8191049: Add alternate version of pns() that is callable from >>>>>> within hotspot source >>>>>> Summary: added pns2() to debug.cpp >>>>>> Reviewed-by: stuefe, gthornbr >>>>> >>>>> This is the first time we've rebased the project to bits that are >>>>> this >>>>> fresh (< 12 hours old at rebase time). We've done this because we >>>>> think >>>>> we're done with this project and are in the final >>>>> review-change-retest >>>>> cycle(s)... In other words, we're not planning on making any more >>>>> major >>>>> changes for this project... :-) >>>>> >>>>> *** Time for code reviewers to chime in on this thread! *** >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>>> >>>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>>> >>>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>>> (and the new baseline also)... >>>>> >>>>> We're expecting this round to be a little noisier than usual because >>>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>>> (Yes, we're playing chase-the-repo...) >>>>>> >>>>>> Here is the updated full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>>> >>>>>> Unlike the previous rebase, there were no changes required to the >>>>>> open code to get the rebased bits to build so there is no delta >>>>>> webrev. >>>>>> >>>>>> These bits have been run through JPRT and I've submitted the usual >>>>>> Mach5 tier[1-5] test run... >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>>> >>>>>>> Here are the updated webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>>> >>>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>>> holiday >>>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>>> closer >>>>>>> look today. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>>> and Coleen) >>>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>>> done as a >>>>>>>> standalone patch and corresponding webrevs: >>>>>>>> >>>>>>>> Here's the mq comment for the change: >>>>>>>> >>>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>>> to use >>>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>>> >>>>>>>> Here is the full webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>>> >>>>>>>> And here is the delta webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Dan, Erik and Robbin >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>>> Greetings, >>>>>>>>> >>>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>>> >>>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>>> >>>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>>> >>>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>>> describe >>>>>>>>> and track the work on this project: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>>> >>>>>>>>> >>>>>>>>> Dan has noticed that the indenting is wrong in some of the >>>>>>>>> code quotes >>>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>>> have a >>>>>>>>> solution for that problem yet. >>>>>>>>> >>>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>>> >>>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>>> tier[2-5] >>>>>>>>> testing, additional stress testing on Dan's Solaris X64 >>>>>>>>> server, and >>>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>>> >>>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>>> >>>>>>>>> Daniel Daugherty >>>>>>>>> Erik Osterlund >>>>>>>>> Robbin Ehn >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From rkennke at redhat.com Tue Nov 21 21:37:40 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 22:37:40 +0100 Subject: RFR: 8191564: Refactor GC related servicability code into GC specific subclasses In-Reply-To: <387d2b93-cb8b-51be-a6e0-3b5f9d6cbb1c@redhat.com> References: <387d2b93-cb8b-51be-a6e0-3b5f9d6cbb1c@redhat.com> Message-ID: <713325a4-3ed8-cd7d-c66d-a1c1767b6d3a@redhat.com> I had some off-band discussions with Erik Helin and re-did most of the changeset: - The GC interface now resides in CollectedHeap, specifically the two methods memory_managers() and memory_pools(), and is implemented in the various concrete subclasses. - Both methods return (by value) a GrowableArray and GrowableArray respectively. Returning a stack-allocated GrowableArray seemed least complicated (avoid explicit cleanup of short-lived array object), and most future-proof, e.g. currently there is an implicit expectation to get 2 GCMemoryManagers, even though some GCs don't necessarily have two. The API allows for easy extension of the situation. http://cr.openjdk.java.net/~rkennke/8191564/webrev.01/ I think this requires reviews from both the GC and Serviceability team. Roman > Currently, there's lots of GC specific code sprinkled over > src/hotspot/share/services. This change introduces a GC interface for > that, and moves all GC specific code to their respective > src/hotspot/share/gc directory. > > http://cr.openjdk.java.net/~rkennke/8191564/webrev.00/ > > > Testing: hotspot_gc and hotspot_serviceability, none showed regressions > > Built minimal and server without regressions > > What do you think? > > Roman > > From jcbeyler at google.com Tue Nov 21 21:50:15 2017 From: jcbeyler at google.com (JC Beyler) Date: Tue, 21 Nov 2017 13:50:15 -0800 Subject: Low-Overhead Heap Profiling In-Reply-To: <1510146425.3155.11.camel@oracle.com> References: <1497366226.2829.109.camel@oracle.com> <1498215147.2741.34.camel@oracle.com> <044f8c75-72f3-79fd-af47-7ee875c071fd@oracle.com> <23f4e6f5-c94e-01f7-ef1d-5e328d4823c8@oracle.com> <5ec70351-910a-96bb-eb03-43ca88bd6259@oracle.com> <1508935388.13554.11.camel@oracle.com> <1510146425.3155.11.camel@oracle.com> Message-ID: Hi all, I have a new webrev here: http://cr.openjdk.java.net/~rasbold/8171119/webrev.15/ With the incremental one here: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/ I think I did most items from Thomans and Robbin. I've especially added a new test: http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a_15/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatObjectCorrectnessTest.java.patch This tests the path of object allocation (as opposed to only testing the array allocation path). I also updated the JEP: https://bugs.openjdk.java.net/browse/JDK-8171119 I'll work now with Robbin on the next steps. Any additional comments/criticisms are as always welcome :) Jc On Wed, Nov 8, 2017 at 5:07 AM, Thomas Schatzl wrote: > Hi JC, > > sorry for the long wait. > > On Wed, 2017-11-01 at 10:46 -0700, JC Beyler wrote: > > Dear all, > > > > Here is the next webrev: > > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14a/ > > > > Incremental since the rebase: > > http://cr.openjdk.java.net/~rasbold/8171119/webrev.14_14a/ > > > > (I'm still not too familiar with hg so I had to do a fresh rebase so > > v14 is once the rebase was done and v14a integrates the changes > > requested from Thomas). > > Yeah, there seem to be something missing in the incremental webrev, but > thanks for the effort. > > > I have also inlined answers to Thomas' email: > > > A few minor issues: > > > > > - in the declaration of CollectedHeap::sample_allocation, it > > > would be nice if the fix_sample_rate parameter would be described - > > > it takes a time to figure out what it's used for. I.e. in case an > > > allocation goes beyond the sampling watermark, this value which > > > represents the amount of overallocation is used to adjust the next > > > sampling watermark to sample at the correct rate. > > > Something like this - and if what I wrote is incorrect, there is > > > even more reason to document it. > > > Or maybe just renaming "fix_sample_rate" to something more > > > descriptive - but I have no good idea about that. > > > With lack of units in the type, it would also be nice to have the > > > unit in the identifier name, as done elsewhere. > > > > Thanks. Could you s/passed/past in that documentation? > > > Done for Robbin's issue and changed it to > > > - some (or most actually) of the new setters and getters in the > > > ThreadLocalAllocBuffer class could be private I think. Also, we > > > typically do not use "simple" getters that just return a member in > > > the class where they are defined. > > > > I removed all that were not used that I could see (not used outside > > the class) moved the ones that are not simple to private if they > > could be. I think it's a bit weird because now some of the setting of > > the tlab internal data is using methods, others are directly setting. > > Let me know what you think. > > That's fine with me. You need to start somewhere I guess. > > > > - ThreadLocalAllocBuffer::pick_next_sample() - I recommend making > > > the first check an assert - it seems that it is only useful to call > > > this with heap monitoring enabled, as is done right now. > > > > Longer conversation below about this, It cannot be an assert (I could > > remove the test altogether though). > > I looked at the description, and you are right. I missed that. Keep it > as is. :) > > > > - HeapMonitoring::next_random() - the different names for the > > > constants use different formatting. Preferable (to me) is > > > UpperCamelCase, but at least make them uniform. > > > > > > > I think done the way you wanted! > > In heapMonitoring.hpp:50-53 the constants still have different format? > > > > > > > - not really convinced that it is a good idea to not somehow > > > guard > > > StartHeapSampling() and StopHeapSampling() against being called by > > > multiple threads. > > > > > > > I added another mutex for the start/stop so that way it will protect > > from that. > > > > Thanks! > > > > > > Otherwise looks okay from what I can see. > > Still okay. I do not need a re-review for the changes suggested in this > email. > > > > > Awesome, what do you think I still need for this before going to the > > next step (which is what by the way? :)). > > I think: > > - look through the JEP if it is still current and fix the descriptions > if required > - add a link to the latest webrev to the JEP as comment > - if not done already, file CSRs [0] for > - the new flag > - JVMTI changes (I think, not sure actually) > - find a sponsor from Oracle to do some internal work (pushing, and > before that there is iirc still some background work related to JEPs > that can only be done by Oracle, mostly shepherding :/). > > I talked to Robbin about this, and he offered to help you with that. > > Thanks, > Thomas > > [0] https://wiki.openjdk.java.net/display/csr/Main > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 22 00:12:49 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 Nov 2017 19:12:49 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> Message-ID: <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Greetings, *** We are wrapping up code review on this project so it is time *** *** for the various code reviewers to chime in one last time. *** In this latest round, we had three different reviewers chime in so we're doing delta webrevs for each of those resolutions: David H's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ ? mq comment for dholmes_CR: ??? - Fix indents, trailing spaces and various typos. ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, ????? add impl notes to document the type choices. ? src/hotspot/share/runtime/globals.hpp change is white-space only so it ? is only visible via the file's patch link. Robin W's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ ? mq comment for robinw_CR: ??? - Fix some inefficient code, update some comments, fix some indents, ????? and add some 'const' specifiers. ? src/hotspot/share/runtime/vm_operations.hpp change is white-space only so ? it is only visible via the file's patch link. Coleen's resolutions: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ ? mq comment for coleenp_CR: ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', ??? - add header comment to threadSMR.hpp file, ??? - cleanup JavaThreadIteratorWithHandle ctr, ??? - make ErrorHandling more efficient. Some folks prefer to see all of the delta webrevs together so here is a delta webrev relative to jdk10-09-full: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ ? src/hotspot/share/runtime/globals.hpp and ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space only ? so they are only visible via the file's patch link. And, of course, some folks prefer to see everything all at once so here is the latest full webrev: http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... The project is currently baselined on Jesper's 2017-11-17 PIT snapshot so there will be some catching up to do before integration... We welcome comments, suggestions and feedback. Dan, Erik and Robbin On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: > Greetings, > > Testing of the last round of changes revealed a hang in one of the new > TLH tests. Robbin has fixed the hang, updated the existing TLH test, and > added another TLH test for good measure. > > Here is the updated full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ > > Here is the updated delta webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ > > Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are > no unexpected failures. > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Robbin rebased the project last night/this morning to merge with Thread >> Local Handshakes (TLH) and also picked up additional changesets up thru: >> >>> Changeset: fa736014cf28 >>> Author:??? cjplummer >>> Date:????? 2017-11-14 18:08 -0800 >>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>> >>> 8191049: Add alternate version of pns() that is callable from within >>> hotspot source >>> Summary: added pns2() to debug.cpp >>> Reviewed-by: stuefe, gthornbr >> >> This is the first time we've rebased the project to bits that are this >> fresh (< 12 hours old at rebase time). We've done this because we think >> we're done with this project and are in the final review-change-retest >> cycle(s)... In other words, we're not planning on making any more major >> changes for this project... :-) >> >> *** Time for code reviewers to chime in on this thread! *** >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >> >> Here's is the delta webrev from the 2017.11.10 rebase: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >> (and the new baseline also)... >> >> We're expecting this round to be a little noisier than usual because >> we did not rebase on a PIT snapshot so the new baseline has not been >> through Jesper's usual care-and-feeding of integration_blockers, etc. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>> (Yes, we're playing chase-the-repo...) >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>> >>> Unlike the previous rebase, there were no changes required to the >>> open code to get the rebased bits to build so there is no delta >>> webrev. >>> >>> These bits have been run through JPRT and I've submitted the usual >>> Mach5 tier[1-5] test run... >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>> >>>> Here are the updated webrevs: >>>> >>>> Here's the mq comment for the change: >>>> >>>> ? Rebase to 2017.10.25 PIT snapshot. >>>> >>>> Here is the full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>> >>>> And here is the delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>> >>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>> look today. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Resolving one of the code review comments (from both Stefan K and >>>>> Coleen) >>>>> on jdk10-04-full required quite a few changes so it is being done >>>>> as a >>>>> standalone patch and corresponding webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>> ??? JavaThreadIteratorWithHandle. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> We have a (eXtra Large) fix for the following bug: >>>>>> >>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>> >>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>> >>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>> and track the work on this project: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>> >>>>>> >>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>> quotes >>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>> have a >>>>>> solution for that problem yet. >>>>>> >>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>> >>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>> tier[2-5] >>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>> additional testing on Erik and Robbin's machines. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Daniel Daugherty >>>>>> Erik Osterlund >>>>>> Robbin Ehn >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From david.holmes at oracle.com Wed Nov 22 04:26:39 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Nov 2017 14:26:39 +1000 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> Message-ID: <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> Hi Dan, On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: > Greetings, > > *** We are wrapping up code review on this project so it is time *** > *** for the various code reviewers to chime in one last time. *** > > In this latest round, we had three different reviewers chime in so we're > doing delta webrevs for each of those resolutions: > > David H's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ > > > ? mq comment for dholmes_CR: > ??? - Fix indents, trailing spaces and various typos. > ??? - Add descriptions for the '_cnt', '_max' and '_times" fields, > ????? add impl notes to document the type choices. src/hotspot/share/runtime/thread.cpp 3466 // range. Unsigned 64-bit would be more future proof, but 64-bit atomic inc 3467 // isn't available everywhere (or is it?). 64-bit atomics should be available on all currently supported platforms (the last time this was an issue was for PPC32 - and the atomic templates should have filled in any previous holes in the allowed types). But if it's always 64-bit then you'd have to use Atomic::load to allow for 32-bit platforms. These counts etc are all just for statistics so we aren't really concerned about eventual overflows in long running VMs - right? --- // # of parallel threads in _smr_delete_lock->wait(). static uint _smr_delete_lock_wait_cnt; // Max # of parallel threads in _smr_delete_lock->wait(). why are the comments indented like that? I thought this is what Coleen previously commented on. Please just start the comments in the first column - no need for any indent. Thanks. > ? src/hotspot/share/runtime/globals.hpp change is white-space only so it > ? is only visible via the file's patch link. > > > Robin W's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ > > > ? mq comment for robinw_CR: > ??? - Fix some inefficient code, update some comments, fix some indents, > ????? and add some 'const' specifiers. > > ? src/hotspot/share/runtime/vm_operations.hpp change is white-space > only so > ? it is only visible via the file's patch link. All looks fine to me. Some good catches there from Robin! > Coleen's resolutions: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ > > > ? mq comment for coleenp_CR: > ??? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', > ??? - add header comment to threadSMR.hpp file, > ??? - cleanup JavaThreadIteratorWithHandle ctr, > ??? - make ErrorHandling more efficient. src/hotspot/share/runtime/threadSMR.hpp + // Thread Safe Memory Reclaimation (Thread-SMR) support. Only one 'i' in Reclamation :) Thanks, David ------ > > Some folks prefer to see all of the delta webrevs together so here is > a delta webrev relative to jdk10-09-full: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ > > > ? src/hotspot/share/runtime/globals.hpp and > ? src/hotspot/share/runtime/vm_operations.hpp changes are white-space only > ? so they are only visible via the file's patch link. > > > And, of course, some folks prefer to see everything all at once so here > is the latest full webrev: > > http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ > > > Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The > prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... > > The project is currently baselined on Jesper's 2017-11-17 PIT snapshot > so there will be some catching up to do before integration... > > We welcome comments, suggestions and feedback. > > Dan, Erik and Robbin > > > On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Testing of the last round of changes revealed a hang in one of the new >> TLH tests. Robbin has fixed the hang, updated the existing TLH test, and >> added another TLH test for good measure. >> >> Here is the updated full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >> >> Here is the updated delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >> >> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >> no unexpected failures. >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Robbin rebased the project last night/this morning to merge with Thread >>> Local Handshakes (TLH) and also picked up additional changesets up thru: >>> >>>> Changeset: fa736014cf28 >>>> Author:??? cjplummer >>>> Date:????? 2017-11-14 18:08 -0800 >>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>> >>>> 8191049: Add alternate version of pns() that is callable from within >>>> hotspot source >>>> Summary: added pns2() to debug.cpp >>>> Reviewed-by: stuefe, gthornbr >>> >>> This is the first time we've rebased the project to bits that are this >>> fresh (< 12 hours old at rebase time). We've done this because we think >>> we're done with this project and are in the final review-change-retest >>> cycle(s)... In other words, we're not planning on making any more major >>> changes for this project... :-) >>> >>> *** Time for code reviewers to chime in on this thread! *** >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>> >>> Here's is the delta webrev from the 2017.11.10 rebase: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>> >>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>> (and the new baseline also)... >>> >>> We're expecting this round to be a little noisier than usual because >>> we did not rebase on a PIT snapshot so the new baseline has not been >>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>> (Yes, we're playing chase-the-repo...) >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>> >>>> Unlike the previous rebase, there were no changes required to the >>>> open code to get the rebased bits to build so there is no delta >>>> webrev. >>>> >>>> These bits have been run through JPRT and I've submitted the usual >>>> Mach5 tier[1-5] test run... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>> >>>>> Here are the updated webrevs: >>>>> >>>>> Here's the mq comment for the change: >>>>> >>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>> >>>>> Here is the full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>> >>>>> And here is the delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>> >>>>> I ran the above bits throught Mach5 tier[1-5] testing over the holiday >>>>> weekend. Didn't see any issues in a quick look. Going to take a closer >>>>> look today. >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> Resolving one of the code review comments (from both Stefan K and >>>>>> Coleen) >>>>>> on jdk10-04-full required quite a few changes so it is being done >>>>>> as a >>>>>> standalone patch and corresponding webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage to use >>>>>> ??? JavaThreadIteratorWithHandle. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>> >>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>> >>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>> >>>>>>> Here's a PDF for the internal wiki that we've been using to describe >>>>>>> and track the work on this project: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>> >>>>>>> >>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>> quotes >>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>> have a >>>>>>> solution for that problem yet. >>>>>>> >>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>> >>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>> tier[2-5] >>>>>>> testing, additional stress testing on Dan's Solaris X64 server, and >>>>>>> additional testing on Erik and Robbin's machines. >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Daniel Daugherty >>>>>>> Erik Osterlund >>>>>>> Robbin Ehn >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > From goetz.lindenmaier at sap.com Wed Nov 22 06:53:18 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Nov 2017 06:53:18 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> Message-ID: Hi Max, while removing the comments from the k-tools, I saw this: --- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java Tue Oct 10 14:39:45 2017 +0200 +++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java Tue Nov 21 13:09:17 2017 +0100 @@ -356,7 +358,6 @@ System.out.println("\t-t \t shows keytab entry timestamps"); System.out.println("\t-K \t shows keytab entry key value"); System.out.println("\t-e \t shows keytab entry key type"); - System.out.println("\nUsage: java sun.security.krb5.tools.Klist " + - "-help for help."); + System.out.println("\n-? -h --help print this help message and exit"); } } I don't think the old comment is in the original program :) and anyways, -help is not supported by Klist. It prints the usage called with the flag, but just because it prints it on any wrong flag. So should I replace the comment here? Or at least remove it? Best regards, Goetz > -----Original Message----- > From: Weijun Wang [mailto:weijun.wang at oracle.com] > Sent: Monday, November 20, 2017 3:49 PM > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > serviceability-dev (serviceability-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > Hi Goetz > > I understand your intention. > > If the reason is that one day every tool will switch to this new style, please at > least do not include kinit, klist and ktab. These Windows-only commands are > meant to emulate MIT krb5 tools with the same names and we need to keep > the option (and maybe the help screen) as similar as possible. > > I am OK with supporting the --help option undocumented. > > Thanks > Max > > > On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz > wrote: > > > > Hi Max, > > > > I think there are so many tools mixing both kinds of > > options, that it's rather a gain if all at least document > > the same, up to date help message, than if the documentation > > is skipped for some. > > > > After my change, all the help messages are quite similar. > > I updated them to use the same wording while trying to > > keep the sentence structure in accordance with the other > > documented flags, see below. > > > > Best regards, > > Goetz. > > > > > > > > -? -h --help display this help message > > -? -h --help display this help message > > -h, --help (Print this help message.) > > -?, --help Print this help message > > -? -h --help Print this help message > > --help, -h, -? Display command line options and exit > > -? -h --help Print this help message > > -h -? --help Print this help message > > -? -h --help > > -? -h --help : display this help message and exit > > -? -h --help : display this help message and exit > > -? -h --help print this help message and exit > > -? | -h | --help to print this help message > > jmap -? -h --help to print this help message > > usage: jps [-? -h --help] > > -? -h --help to print this help message > > -? -h --help Prints this help message. > > -? -h --help print this help message > > -? -h --help Print this synopsis of standard options and exit > > Use "keytool -? -h or --help" for all available commands > > --help print this help message to the output stream > > -?, -h, --help Print this help message > > -h, --help, -? Print this help message > > -?, -h, --help Print this help message > > -? -h --help Print this help message and exit > > -?, -h, --help print this help message > > -?, -h, --help print this help message > > -? -h --help Print this help message > > -?, -h, --help[:compat] Give this, or optionally the compatibility, help > > [-? -h --help] Print this help message > > jstatd -?|-h|--help > > > > > >> -----Original Message----- > >> From: Weijun Wang [mailto:weijun.wang at oracle.com] > >> Sent: Sonntag, 19. November 2017 01:28 > >> To: Lindenmaier, Goetz > >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > >> serviceability-dev (serviceability-dev at openjdk.java.net) >> dev at openjdk.java.net> > >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > >> > >> I am OK with all commands supporting --help, but I am not sure if every > tool > >> should show it on the help screen if the tools's other options are still using > >> the old single-"-" style. It looks like the tools are half-converted. > >> > >> Is there a timetable to add "--" support to all tools? > >> > >> Thanks > >> Max > >> > >>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz > >> wrote: > >>> > >>> Hi, > >>> > >>> please review this change. I also filed a CSR for this: > >>> http://cr.openjdk.java.net/~goetz/wr17/8189102- > >> helpMessage/webrev.02/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > >>> > >>> See the webrev for a detailed description of the changes. > >>> > >>> If required, I'll make break-out changes to be reviewed separately. > >>> > >>> I had posted a RFR before, but improved the change to > >>> give a more complete overview of currently supported flags > >>> for the CSR: > >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- > >> October/028615.html > >>> > >>> Best regards, > >>> Goetz. > >>> > > From weijun.wang at oracle.com Wed Nov 22 07:07:51 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 22 Nov 2017 15:07:51 +0800 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> Message-ID: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com> Hi Goetz I would just remove it. Thanks Max > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz wrote: > > Hi Max, > > while removing the comments from the k-tools, I saw this: > > --- a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java Tue Oct 10 14:39:45 2017 +0200 > +++ b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java Tue Nov 21 13:09:17 2017 +0100 > @@ -356,7 +358,6 @@ > System.out.println("\t-t \t shows keytab entry timestamps"); > System.out.println("\t-K \t shows keytab entry key value"); > System.out.println("\t-e \t shows keytab entry key type"); > - System.out.println("\nUsage: java sun.security.krb5.tools.Klist " + > - "-help for help."); > + System.out.println("\n-? -h --help print this help message and exit"); > } > } > > I don't think the old comment is in the original program :) and anyways, -help > is not supported by Klist. It prints the usage called with the flag, but just because > it prints it on any wrong flag. > > So should I replace the comment here? > Or at least remove it? > > Best regards, > Goetz > >> -----Original Message----- >> From: Weijun Wang [mailto:weijun.wang at oracle.com] >> Sent: Monday, November 20, 2017 3:49 PM >> To: Lindenmaier, Goetz >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; >> serviceability-dev (serviceability-dev at openjdk.java.net) > dev at openjdk.java.net> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help >> >> Hi Goetz >> >> I understand your intention. >> >> If the reason is that one day every tool will switch to this new style, please at >> least do not include kinit, klist and ktab. These Windows-only commands are >> meant to emulate MIT krb5 tools with the same names and we need to keep >> the option (and maybe the help screen) as similar as possible. >> >> I am OK with supporting the --help option undocumented. >> >> Thanks >> Max >> >>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz >> wrote: >>> >>> Hi Max, >>> >>> I think there are so many tools mixing both kinds of >>> options, that it's rather a gain if all at least document >>> the same, up to date help message, than if the documentation >>> is skipped for some. >>> >>> After my change, all the help messages are quite similar. >>> I updated them to use the same wording while trying to >>> keep the sentence structure in accordance with the other >>> documented flags, see below. >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>> -? -h --help display this help message >>> -? -h --help display this help message >>> -h, --help (Print this help message.) >>> -?, --help Print this help message >>> -? -h --help Print this help message >>> --help, -h, -? Display command line options and exit >>> -? -h --help Print this help message >>> -h -? --help Print this help message >>> -? -h --help >>> -? -h --help : display this help message and exit >>> -? -h --help : display this help message and exit >>> -? -h --help print this help message and exit >>> -? | -h | --help to print this help message >>> jmap -? -h --help to print this help message >>> usage: jps [-? -h --help] >>> -? -h --help to print this help message >>> -? -h --help Prints this help message. >>> -? -h --help print this help message >>> -? -h --help Print this synopsis of standard options and exit >>> Use "keytool -? -h or --help" for all available commands >>> --help print this help message to the output stream >>> -?, -h, --help Print this help message >>> -h, --help, -? Print this help message >>> -?, -h, --help Print this help message >>> -? -h --help Print this help message and exit >>> -?, -h, --help print this help message >>> -?, -h, --help print this help message >>> -? -h --help Print this help message >>> -?, -h, --help[:compat] Give this, or optionally the compatibility, help >>> [-? -h --help] Print this help message >>> jstatd -?|-h|--help >>> >>> >>>> -----Original Message----- >>>> From: Weijun Wang [mailto:weijun.wang at oracle.com] >>>> Sent: Sonntag, 19. November 2017 01:28 >>>> To: Lindenmaier, Goetz >>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; >>>> serviceability-dev (serviceability-dev at openjdk.java.net) >>> dev at openjdk.java.net> >>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help >>>> >>>> I am OK with all commands supporting --help, but I am not sure if every >> tool >>>> should show it on the help screen if the tools's other options are still using >>>> the old single-"-" style. It looks like the tools are half-converted. >>>> >>>> Is there a timetable to add "--" support to all tools? >>>> >>>> Thanks >>>> Max >>>> >>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review this change. I also filed a CSR for this: >>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102- >>>> helpMessage/webrev.02/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 >>>>> >>>>> See the webrev for a detailed description of the changes. >>>>> >>>>> If required, I'll make break-out changes to be reviewed separately. >>>>> >>>>> I had posted a RFR before, but improved the change to >>>>> give a more complete overview of currently supported flags >>>>> for the CSR: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- >>>> October/028615.html >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>> > From goetz.lindenmaier at sap.com Wed Nov 22 07:13:39 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Nov 2017 07:13:39 +0000 Subject: RFR: 8189102: All tools should support -?, -h and --help In-Reply-To: <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com> References: <4a021bc072f24c7b9d1bb3b00b774867@sap.com> <907ACA21-BD74-4CAF-B1AE-907D74E456E1@oracle.com> <5143F580-CDB0-4970-AC7A-038608E59FAA@oracle.com> Message-ID: <8f6273ffa9cc4b119f0004052f29c711@sap.com> OK, thanks! Best regards, Goetz. > -----Original Message----- > From: Weijun Wang [mailto:weijun.wang at oracle.com] > Sent: Wednesday, November 22, 2017 8:08 AM > To: Lindenmaier, Goetz > Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > serviceability-dev (serviceability-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > > Hi Goetz > > I would just remove it. > > Thanks > Max > > > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz > wrote: > > > > Hi Max, > > > > while removing the comments from the k-tools, I saw this: > > > > --- > a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl > ist.java Tue Oct 10 14:39:45 2017 +0200 > > +++ > b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl > ist.java Tue Nov 21 13:09:17 2017 +0100 > > @@ -356,7 +358,6 @@ > > System.out.println("\t-t \t shows keytab entry timestamps"); > > System.out.println("\t-K \t shows keytab entry key value"); > > System.out.println("\t-e \t shows keytab entry key type"); > > - System.out.println("\nUsage: java sun.security.krb5.tools.Klist " + > > - "-help for help."); > > + System.out.println("\n-? -h --help print this help message and exit"); > > } > > } > > > > I don't think the old comment is in the original program :) and anyways, - > help > > is not supported by Klist. It prints the usage called with the flag, but just > because > > it prints it on any wrong flag. > > > > So should I replace the comment here? > > Or at least remove it? > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: Weijun Wang [mailto:weijun.wang at oracle.com] > >> Sent: Monday, November 20, 2017 3:49 PM > >> To: Lindenmaier, Goetz > >> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > >> serviceability-dev (serviceability-dev at openjdk.java.net) >> dev at openjdk.java.net> > >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > >> > >> Hi Goetz > >> > >> I understand your intention. > >> > >> If the reason is that one day every tool will switch to this new style, please > at > >> least do not include kinit, klist and ktab. These Windows-only commands > are > >> meant to emulate MIT krb5 tools with the same names and we need to > keep > >> the option (and maybe the help screen) as similar as possible. > >> > >> I am OK with supporting the --help option undocumented. > >> > >> Thanks > >> Max > >> > >>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz > >> wrote: > >>> > >>> Hi Max, > >>> > >>> I think there are so many tools mixing both kinds of > >>> options, that it's rather a gain if all at least document > >>> the same, up to date help message, than if the documentation > >>> is skipped for some. > >>> > >>> After my change, all the help messages are quite similar. > >>> I updated them to use the same wording while trying to > >>> keep the sentence structure in accordance with the other > >>> documented flags, see below. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>> -? -h --help display this help message > >>> -? -h --help display this help message > >>> -h, --help (Print this help message.) > >>> -?, --help Print this help message > >>> -? -h --help Print this help message > >>> --help, -h, -? Display command line options and exit > >>> -? -h --help Print this help message > >>> -h -? --help Print this help message > >>> -? -h --help > >>> -? -h --help : display this help message and exit > >>> -? -h --help : display this help message and exit > >>> -? -h --help print this help message and exit > >>> -? | -h | --help to print this help message > >>> jmap -? -h --help to print this help message > >>> usage: jps [-? -h --help] > >>> -? -h --help to print this help message > >>> -? -h --help Prints this help message. > >>> -? -h --help print this help message > >>> -? -h --help Print this synopsis of standard options and exit > >>> Use "keytool -? -h or --help" for all available commands > >>> --help print this help message to the output stream > >>> -?, -h, --help Print this help message > >>> -h, --help, -? Print this help message > >>> -?, -h, --help Print this help message > >>> -? -h --help Print this help message and exit > >>> -?, -h, --help print this help message > >>> -?, -h, --help print this help message > >>> -? -h --help Print this help message > >>> -?, -h, --help[:compat] Give this, or optionally the compatibility, help > >>> [-? -h --help] Print this help message > >>> jstatd -?|-h|--help > >>> > >>> > >>>> -----Original Message----- > >>>> From: Weijun Wang [mailto:weijun.wang at oracle.com] > >>>> Sent: Sonntag, 19. November 2017 01:28 > >>>> To: Lindenmaier, Goetz > >>>> Cc: core-libs-dev at openjdk.java.net; compiler-dev at openjdk.java.net; > >>>> serviceability-dev (serviceability-dev at openjdk.java.net) >>>> dev at openjdk.java.net> > >>>> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help > >>>> > >>>> I am OK with all commands supporting --help, but I am not sure if every > >> tool > >>>> should show it on the help screen if the tools's other options are still > using > >>>> the old single-"-" style. It looks like the tools are half-converted. > >>>> > >>>> Is there a timetable to add "--" support to all tools? > >>>> > >>>> Thanks > >>>> Max > >>>> > >>>>> On Nov 17, 2017, at 7:23 PM, Lindenmaier, Goetz > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> please review this change. I also filed a CSR for this: > >>>>> http://cr.openjdk.java.net/~goetz/wr17/8189102- > >>>> helpMessage/webrev.02/ > >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102 > >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477 > >>>>> > >>>>> See the webrev for a detailed description of the changes. > >>>>> > >>>>> If required, I'll make break-out changes to be reviewed separately. > >>>>> > >>>>> I had posted a RFR before, but improved the change to > >>>>> give a more complete overview of currently supported flags > >>>>> for the CSR: > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017- > >>>> October/028615.html > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>> > > From sharath.ballal at oracle.com Wed Nov 22 09:23:14 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 22 Nov 2017 01:23:14 -0800 (PST) Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException In-Reply-To: <5A14332D.2060002@oracle.com> References: <84288f14-2283-4ea4-b152-28762c27237b@default> <5A14332D.2060002@oracle.com> Message-ID: <385a9440-6567-4484-89cb-73b2be9d6622@default> Thanks Sundar. Thanks, Sharath From: Sundararajan Athijegannathan Sent: Tuesday, November 21, 2017 7:38 PM To: serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException +1 -Sundar On 21/11/17, 3:26 PM, Sharath Ballal wrote: I have made minor modification to the test (added @bug and removed @modules). The revised webrev is HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8184982/webrev.01/"http://cr.openjdk.java.net/~sballal/8184982/webrev.01/ Thanks, Sharath From: Sharath Ballal Sent: Tuesday, November 21, 2017 12:27 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RE: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Gentle reminder. Thanks, Sharath From: Sharath Ballal Sent: Tuesday, November 14, 2017 10:31 AM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8184982 - SA: Running ClassDump on a simple java program generates NullPointerException Hello, Pls review the code changes and testcase for the following issue. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8184982 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esballal/8184982/webrev.00/"http://cr.openjdk.java.net/~sballal/8184982/webrev.00/ Thanks, Sharath -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed Nov 22 12:51:10 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:51:10 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> Message-ID: <4fd06a59-f6b5-33b2-53f5-7bfc96f866a7@oracle.com> On 11/21/17 11:26 PM, David Holmes wrote: > Hi Dan, > > On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> *** We are wrapping up code review on this project so it is time *** >> *** for the various code reviewers to chime in one last time. *** >> >> In this latest round, we had three different reviewers chime in so we're >> doing delta webrevs for each of those resolutions: >> >> David H's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >> >> >> ?? mq comment for dholmes_CR: >> ???? - Fix indents, trailing spaces and various typos. >> ???? - Add descriptions for the '_cnt', '_max' and '_times" fields, >> ?????? add impl notes to document the type choices. > > src/hotspot/share/runtime/thread.cpp > > 3466 // range. Unsigned 64-bit would be more future proof, but 64-bit > atomic inc > 3467 // isn't available everywhere (or is it?). > > 64-bit atomics should be available on all currently supported > platforms (the last time this was an issue was for PPC32 - and the > atomic templates should have filled in any previous holes in the > allowed types). Hmmm... I ran into this when I merged the project with the atomic templates. I got a JPRT build failure on one of the ARM platforms... Unfortunately, I didn't save the log files so I can't quote the error message from the template stuff... > But if it's always 64-bit then you'd have to use Atomic::load to allow > for 32-bit platforms. What's the official story on 32-bit platforms? Is that what bit me in JPRT? i.e., did we still have a 32-bit ARM build config'ed in JPRT a month or two ago??? > These counts etc are all just for statistics so we aren't really > concerned about eventual overflows in long running VMs - right? Yup these are just statistics... overflow is not a killer. > > --- > > ?????????????????????????????????????? // # of parallel threads in > _smr_delete_lock->wait(). > ? static uint????????????????? _smr_delete_lock_wait_cnt; > ?????????????????????????????????????? // Max # of parallel threads in > _smr_delete_lock->wait(). > > > why are the comments indented like that? I thought this is what Coleen > previously commented on. Please just start the comments in the first > column - no need for any indent. Thanks. Coleen asked for the new comments in thread.cpp to be moved over to column 1. She asked for the new comments in thread.hpp to be indented with more spaces. I started with 2 spaces and the variables still didn't stand out. I tried 4 spaces and they still didn't stand out probably because of the leading _smr_... So I went with 8 spaces... > >> ?? src/hotspot/share/runtime/globals.hpp change is white-space only >> so it >> ?? is only visible via the file's patch link. >> >> >> Robin W's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >> >> >> ?? mq comment for robinw_CR: >> ???? - Fix some inefficient code, update some comments, fix some >> indents, >> ?????? and add some 'const' specifiers. >> >> ?? src/hotspot/share/runtime/vm_operations.hpp change is white-space >> only so >> ?? it is only visible via the file's patch link. > > All looks fine to me. Some good catches there from Robin! Yes, a new pair of eyes on this code is always useful. > >> Coleen's resolutions: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >> >> >> ?? mq comment for coleenp_CR: >> ???? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >> ???? - add header comment to threadSMR.hpp file, >> ???? - cleanup JavaThreadIteratorWithHandle ctr, >> ???? - make ErrorHandling more efficient. > > src/hotspot/share/runtime/threadSMR.hpp > > + // Thread Safe Memory Reclaimation (Thread-SMR) support. > > Only one 'i' in Reclamation :) Will fix. I tried typing both and neither looked right to me. (I might be getting blurry eyed with this stuff)... So I went with the spelling from Coleen's comment... :-) Thanks for taking another look!! Dan > > Thanks, > David > ------ > >> >> Some folks prefer to see all of the delta webrevs together so here is >> a delta webrev relative to jdk10-09-full: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >> >> >> ?? src/hotspot/share/runtime/globals.hpp and >> ?? src/hotspot/share/runtime/vm_operations.hpp changes are >> white-space only >> ?? so they are only visible via the file's patch link. >> >> >> And, of course, some folks prefer to see everything all at once so here >> is the latest full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >> >> >> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >> >> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >> so there will be some catching up to do before integration... >> >> We welcome comments, suggestions and feedback. >> >> Dan, Erik and Robbin >> >> >> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Testing of the last round of changes revealed a hang in one of the new >>> TLH tests. Robbin has fixed the hang, updated the existing TLH test, >>> and >>> added another TLH test for good measure. >>> >>> Here is the updated full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>> >>> Here is the updated delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-delta/ >>> >>> Dan ran the bits thru the usual Mach5 tier[1-5] testing and there are >>> no unexpected failures. >>> >>> We welcome comments, suggestions and feedback. >>> >>> Dan, Erik and Robbin >>> >>> >>> On 11/15/17 3:32 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Robbin rebased the project last night/this morning to merge with >>>> Thread >>>> Local Handshakes (TLH) and also picked up additional changesets up >>>> thru: >>>> >>>>> Changeset: fa736014cf28 >>>>> Author:??? cjplummer >>>>> Date:????? 2017-11-14 18:08 -0800 >>>>> URL:http://hg.openjdk.java.net/jdk/hs/rev/fa736014cf28 >>>>> >>>>> 8191049: Add alternate version of pns() that is callable from >>>>> within hotspot source >>>>> Summary: added pns2() to debug.cpp >>>>> Reviewed-by: stuefe, gthornbr >>>> >>>> This is the first time we've rebased the project to bits that are this >>>> fresh (< 12 hours old at rebase time). We've done this because we >>>> think >>>> we're done with this project and are in the final review-change-retest >>>> cycle(s)... In other words, we're not planning on making any more >>>> major >>>> changes for this project... :-) >>>> >>>> *** Time for code reviewers to chime in on this thread! *** >>>> >>>> Here is the updated full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-full/ >>>> >>>> Here's is the delta webrev from the 2017.11.10 rebase: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-08-delta/ >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing >>>> (and the new baseline also)... >>>> >>>> We're expecting this round to be a little noisier than usual because >>>> we did not rebase on a PIT snapshot so the new baseline has not been >>>> through Jesper's usual care-and-feeding of integration_blockers, etc. >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/14/17 4:48 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I rebased the project to the 2017.11.10 jdk/hs PIT snapshot. >>>>> (Yes, we're playing chase-the-repo...) >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-07-full/ >>>>> >>>>> Unlike the previous rebase, there were no changes required to the >>>>> open code to get the rebased bits to build so there is no delta >>>>> webrev. >>>>> >>>>> These bits have been run through JPRT and I've submitted the usual >>>>> Mach5 tier[1-5] test run... >>>>> >>>>> We welcome comments, suggestions and feedback. >>>>> >>>>> Dan, Erik and Robbin >>>>> >>>>> >>>>> On 11/13/17 12:30 PM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I rebased the project to the 2017.10.26 jdk10/hs PIT snapshot. >>>>>> >>>>>> Here are the updated webrevs: >>>>>> >>>>>> Here's the mq comment for the change: >>>>>> >>>>>> ? Rebase to 2017.10.25 PIT snapshot. >>>>>> >>>>>> Here is the full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-full/ >>>>>> >>>>>> And here is the delta webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-06-delta/ >>>>>> >>>>>> I ran the above bits throught Mach5 tier[1-5] testing over the >>>>>> holiday >>>>>> weekend. Didn't see any issues in a quick look. Going to take a >>>>>> closer >>>>>> look today. >>>>>> >>>>>> We welcome comments, suggestions and feedback. >>>>>> >>>>>> Dan, Erik and Robbin >>>>>> >>>>>> >>>>>> On 11/8/17 1:05 PM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> Resolving one of the code review comments (from both Stefan K >>>>>>> and Coleen) >>>>>>> on jdk10-04-full required quite a few changes so it is being >>>>>>> done as a >>>>>>> standalone patch and corresponding webrevs: >>>>>>> >>>>>>> Here's the mq comment for the change: >>>>>>> >>>>>>> ? stefank, coleenp CR - refactor most JavaThreadIterator usage >>>>>>> to use >>>>>>> ??? JavaThreadIteratorWithHandle. >>>>>>> >>>>>>> Here is the full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-full/ >>>>>>> >>>>>>> And here is the delta webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-05-delta/ >>>>>>> >>>>>>> We welcome comments, suggestions and feedback. >>>>>>> >>>>>>> Dan, Erik and Robbin >>>>>>> >>>>>>> >>>>>>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> We have a (eXtra Large) fix for the following bug: >>>>>>>> >>>>>>>> 8167108 inconsistent handling of SR_lock can lead to crashes >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8167108 >>>>>>>> >>>>>>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on >>>>>>>> Hazard Pointers to manage JavaThread lifecycle. >>>>>>>> >>>>>>>> Here's a PDF for the internal wiki that we've been using to >>>>>>>> describe >>>>>>>> and track the work on this project: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf >>>>>>>> >>>>>>>> >>>>>>>> Dan has noticed that the indenting is wrong in some of the code >>>>>>>> quotes >>>>>>>> in the PDF that are not present in the internal wiki. We don't >>>>>>>> have a >>>>>>>> solution for that problem yet. >>>>>>>> >>>>>>>> Here's the webrev for current JDK10 version of this fix: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full >>>>>>>> >>>>>>>> This fix has been run through many rounds of JPRT and Mach5 >>>>>>>> tier[2-5] >>>>>>>> testing, additional stress testing on Dan's Solaris X64 server, >>>>>>>> and >>>>>>>> additional testing on Erik and Robbin's machines. >>>>>>>> >>>>>>>> We welcome comments, suggestions and feedback. >>>>>>>> >>>>>>>> Daniel Daugherty >>>>>>>> Erik Osterlund >>>>>>>> Robbin Ehn >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> From daniel.daugherty at oracle.com Wed Nov 22 12:53:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:53:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5A153E52.8000704@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <5A153E52.8000704@oracle.com> Message-ID: On 11/22/17 4:07 AM, Erik ?sterlund wrote: > Hi, > > Some replies... > > On 2017-11-21 17:28, Daniel D. Daugherty wrote: >> Hi Coleen! >> >> Thanks for making time to review the Thread-SMR stuff again!! >> >> I have added back the other three OpenJDK aliases... This review is >> being done on _four_ different OpenJDK aliases. >> >> As always, replies are embedded below... >> >> >> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/src/hotspot/share/runtime/threadSMR.cpp.html >>> >>> >>> ? 32 ThreadsList::ThreadsList(int entries) : _length(entries), >>> _threads(NEW_C_HEAP_ARRAY(JavaThread*, entries + 1, mtGC)), >>> _next_list(NULL) { >>> >>> Seems like it should be mtThread rather than mtGC. >> >> Fixed. Definitely an artifact of Erik's original prototype when he >> extracted Thread-SMR from his GC work... Thanks for catching it. >> > > Confirmed. At the time I considered the Threads list overheads GC > overheads, but I agree mtThread is a better fit today. > >> >>> >>> + return (unsigned int)(((uint32_t)(uintptr_t)s1) * 2654435761u); >>> >>> Can you add a comment about where this number came from? >> >> I'll have to get that from Erik... > > Wow, that looks like code I wrote a *very* long time ago. :) That is a > variation of Knuth's multiplicative hash which is outlined in a > comment in synchronizer.cpp and referred to in that comment as a > phi-based scheme. Basically the magic number is 2^32 * Phi (the golden > ratio), which happens to be a useful value for building a reasonably > simple yet pretty good hash function. It is not the optimal hash > function, but seemed to definitely be good enough for our purposes. So a reasonable comment would be: // The literal value is 2^32 * Phi (the golden ratio). If so, then I'll add it in my wrap up round... Dan > > Thanks, > /Erik From daniel.daugherty at oracle.com Wed Nov 22 12:54:51 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 07:54:51 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <5A1547F0.7040206@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> <5A1547F0.7040206@oracle.com> Message-ID: <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> On 11/22/17 4:48 AM, Erik ?sterlund wrote: > Hi, > > Some replies... > > On 2017-11-21 18:36, Daniel D. Daugherty wrote: >> Thanks for keeping all the OpenJDK aliases! >> >> >> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>>> >>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>> >>>>> I can't find the caller of threads_do_smr. >>>> >>>> I'm guessing that's used by the GC code that depends on Thread-SMR... >>>> >>> >>> They? should add this API when the add the use of it then.? I don't >>> see it in any sources. >> >> We'll see what Erik wants to do... > > The new iterators should be more than enough, so that closure-based > API is not going to be missed when removed. I will delete it in the wrap up round. > >> >>> >>>> >>>>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, >>>>> inc_smr_deleted_thread_count are only used by thread.cpp, I think >>>>> they should go in that file and not in the .inline.hpp file to be >>>>> included and possibly called by other files.? I think they're >>>>> private to class Threads. >>>> >>>> I have a vague memory that some of the compilers don't do inlining >>>> when >>>> an "inline" function is in a .cpp. I believe we want these functions >>>> to be inlined for performance reasons. Erik should probably chime in >>>> here. >>> >>> I don't see why this should be.? Maybe some (older) compilers >>> require it to be found before the call though, but that can still be >>> accomplished in the .cpp file. >> >> Again, we'll see what Erik wants to do... > > I don't mind. Either file works for me. For me it's more intuitive if > inline member function definitions are in the .inline.hpp files. But > if there are strong forces to move this to the cpp file, then sure. I prefer inline member function definitions in the .inline.hpp files. (There might even be a style guide note about this...) Coleen, are you okay if we leave them there? Dan > > Thanks, > /Erik > From coleen.phillimore at oracle.com Wed Nov 22 13:02:32 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Nov 2017 08:02:32 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <70cc1311-de55-5502-159b-cd0a3522cfd6@oracle.com> <68b0b2bc-2d26-5442-bafb-5ce21420767b@oracle.com> <5e154ff2-65d4-bad4-db5e-88cf4c733c7d@oracle.com> <5A1547F0.7040206@oracle.com> <6906e0e0-e5cc-a415-6db2-13eff8d76ca8@oracle.com> Message-ID: <50fdb219-4aa2-bdcc-cf69-8f60c935208f@oracle.com> On 11/22/17 7:54 AM, Daniel D. Daugherty wrote: > On 11/22/17 4:48 AM, Erik ?sterlund wrote: >> Hi, >> >> Some replies... >> >> On 2017-11-21 18:36, Daniel D. Daugherty wrote: >>> Thanks for keeping all the OpenJDK aliases! >>> >>> >>> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote: >>>>> >>>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>>> I can't find the caller of threads_do_smr. >>>>> >>>>> I'm guessing that's used by the GC code that depends on Thread-SMR... >>>>> >>>> >>>> They? should add this API when the add the use of it then. I don't >>>> see it in any sources. >>> >>> We'll see what Erik wants to do... >> >> The new iterators should be more than enough, so that closure-based >> API is not going to be missed when removed. > > I will delete it in the wrap up round. > > Thank you. >> >>> >>>> >>>>> >>>>>> If these functions xchg_smr_thread_list, >>>>>> get_smr_java_thread_list, inc_smr_deleted_thread_count are only >>>>>> used by thread.cpp, I think they should go in that file and not >>>>>> in the .inline.hpp file to be included and possibly called by >>>>>> other files.? I think they're private to class Threads. >>>>> >>>>> I have a vague memory that some of the compilers don't do inlining >>>>> when >>>>> an "inline" function is in a .cpp. I believe we want these functions >>>>> to be inlined for performance reasons. Erik should probably chime in >>>>> here. >>>> >>>> I don't see why this should be.? Maybe some (older) compilers >>>> require it to be found before the call though, but that can still >>>> be accomplished in the .cpp file. >>> >>> Again, we'll see what Erik wants to do... >> >> I don't mind. Either file works for me. For me it's more intuitive if >> inline member function definitions are in the .inline.hpp files. But >> if there are strong forces to move this to the cpp file, then sure. > > I prefer inline member function definitions in the .inline.hpp files. > (There might even be a style guide note about this...) > > Coleen, are you okay if we leave them there? Yes, that's fine. Coleen > > Dan > > >> >> Thanks, >> /Erik >> > From daniel.daugherty at oracle.com Wed Nov 22 13:09:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 08:09:16 -0500 Subject: RFR(XL): 8167108 - SMR and JavaThread Lifecycle In-Reply-To: References: <1e50bb73-840c-fc3a-81ad-31f83037093f@oracle.com> <836b5c6c-5eef-9245-c16a-e71372093d9a@oracle.com> <82d0e473-a24f-9feb-82e9-7d04c4d7a91d@oracle.com> <354f7ece-66bc-c065-9ee8-f55abcc1c23e@oracle.com> <0ff8df8e-e93c-02d2-cb97-b13b1ac0f53f@oracle.com> <5365606e-4036-b5d7-9bac-e91e42f38d01@oracle.com> <4d5d448e-3902-8465-197e-18a5607fbd70@oracle.com> <4fd06a59-f6b5-33b2-53f5-7bfc96f866a7@oracle.com> Message-ID: <1e70bbf5-6f52-315d-85ba-fd53a01b66ca@oracle.com> Adding back the other OpenJDK aliases... On 11/22/17 8:01 AM, coleen.phillimore at oracle.com wrote: > > > On 11/22/17 7:51 AM, Daniel D. Daugherty wrote: >> On 11/21/17 11:26 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 22/11/2017 10:12 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> *** We are wrapping up code review on this project so it is time *** >>>> *** for the various code reviewers to chime in one last time. *** >>>> >>>> In this latest round, we had three different reviewers chime in so >>>> we're >>>> doing delta webrevs for each of those resolutions: >>>> >>>> David H's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.0-delta/ >>>> >>>> >>>> ?? mq comment for dholmes_CR: >>>> ???? - Fix indents, trailing spaces and various typos. >>>> ???? - Add descriptions for the '_cnt', '_max' and '_times" fields, >>>> ?????? add impl notes to document the type choices. >>> >>> src/hotspot/share/runtime/thread.cpp >>> >>> 3466 // range. Unsigned 64-bit would be more future proof, but >>> 64-bit atomic inc >>> 3467 // isn't available everywhere (or is it?). >>> >>> 64-bit atomics should be available on all currently supported >>> platforms (the last time this was an issue was for PPC32 - and the >>> atomic templates should have filled in any previous holes in the >>> allowed types). >> >> Hmmm... I ran into this when I merged the project with the atomic >> templates. I got a JPRT build failure on one of the ARM platforms... >> Unfortunately, I didn't save the log files so I can't quote the >> error message from the template stuff... >> >> >>> But if it's always 64-bit then you'd have to use Atomic::load to >>> allow for 32-bit platforms. >> >> What's the official story on 32-bit platforms? Is that what >> bit me in JPRT? i.e., did we still have a 32-bit ARM build >> config'ed in JPRT a month or two ago??? >> >> >>> These counts etc are all just for statistics so we aren't really >>> concerned about eventual overflows in long running VMs - right? >> >> Yup these are just statistics... overflow is not a killer. >> >> >>> >>> --- >>> >>> ?????????????????????????????????????? // # of parallel threads in >>> _smr_delete_lock->wait(). >>> ? static uint????????????????? _smr_delete_lock_wait_cnt; >>> ?????????????????????????????????????? // Max # of parallel threads >>> in _smr_delete_lock->wait(). >>> >>> >>> why are the comments indented like that? I thought this is what >>> Coleen previously commented on. Please just start the comments in >>> the first column - no need for any indent. Thanks. >> >> Coleen asked for the new comments in thread.cpp to be moved >> over to column 1. She asked for the new comments in thread.hpp >> to be indented with more spaces. I started with 2 spaces and >> the variables still didn't stand out. I tried 4 spaces and >> they still didn't stand out probably because of the leading >> _smr_... So I went with 8 spaces... > > Since you have the same but more indepth comments in the .cpp file, > and at least for my sampling the comments in the .hpp file look > redundant, I think you should not have the same comments in the .hpp > file.?? They're really values that the implementation uses, not part > of the interface.? My vote is to remove the comments from the .hpp file. The first line is intended to be a 1-line summary and it is identical between thread.cpp and thread.hpp. My thinking was that someone would look in thread.hpp first to see what the field was for and if they wanted the gory details about the field they could look at the impl notes in thread.cpp... Of course, that creates a maintenance problem in keeping the 1-liners in sync between thread.hpp and thread.cpp. I'm okay with deleting the 1-liners from thread.hpp if folks think they should go... Dan > > Coleen >> >> >>> >>>> src/hotspot/share/runtime/globals.hpp change is white-space only so it >>>> ?? is only visible via the file's patch link. >>>> >>>> >>>> Robin W's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.0,10.10.1-delta/ >>>> >>>> >>>> ?? mq comment for robinw_CR: >>>> ???? - Fix some inefficient code, update some comments, fix some >>>> indents, >>>> ?????? and add some 'const' specifiers. >>>> >>>> ?? src/hotspot/share/runtime/vm_operations.hpp change is >>>> white-space only so >>>> ?? it is only visible via the file's patch link. >>> >>> All looks fine to me. Some good catches there from Robin! >> >> Yes, a new pair of eyes on this code is always useful. >> >> >>> >>>> Coleen's resolutions: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10.1,10.10.2-delta/ >>>> >>>> >>>> ?? mq comment for coleenp_CR: >>>> ???? - Change ThreadsList::_threads from 'mtGC' -> 'mtThread', >>>> ???? - add header comment to threadSMR.hpp file, >>>> ???? - cleanup JavaThreadIteratorWithHandle ctr, >>>> ???? - make ErrorHandling more efficient. >>> >>> src/hotspot/share/runtime/threadSMR.hpp >>> >>> + // Thread Safe Memory Reclaimation (Thread-SMR) support. >>> >>> Only one 'i' in Reclamation :) >> >> Will fix. I tried typing both and neither looked right to me. >> (I might be getting blurry eyed with this stuff)... >> So I went with the spelling from Coleen's comment... :-) >> >> Thanks for taking another look!! >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ------ >>> >>>> >>>> Some folks prefer to see all of the delta webrevs together so here is >>>> a delta webrev relative to jdk10-09-full: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.09,10.10.2-delta/ >>>> >>>> >>>> ?? src/hotspot/share/runtime/globals.hpp and >>>> ?? src/hotspot/share/runtime/vm_operations.hpp changes are >>>> white-space only >>>> ?? so they are only visible via the file's patch link. >>>> >>>> >>>> And, of course, some folks prefer to see everything all at once so >>>> here >>>> is the latest full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-10.10-full/ >>>> >>>> >>>> Dan has submitted the bits for the usual Mach5 tier[1-5] testing. The >>>> prelim Mach5 tier1 (JPRT equivalent) on these bits passed just fine... >>>> >>>> The project is currently baselined on Jesper's 2017-11-17 PIT snapshot >>>> so there will be some catching up to do before integration... >>>> >>>> We welcome comments, suggestions and feedback. >>>> >>>> Dan, Erik and Robbin >>>> >>>> >>>> On 11/18/17 8:49 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Testing of the last round of changes revealed a hang in one of the >>>>> new >>>>> TLH tests. Robbin has fixed the hang, updated the existing TLH >>>>> test, and >>>>> added another TLH test for good measure. >>>>> >>>>> Here is the updated full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09-full/ >>>>> >>>>> Here is the updated delta webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-09