Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen staffan.lar...@oracle.com wrote: It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen staffan.lar...@oracle.com wrote: Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can’t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan kmcgui...@twitter.com wrote: Hi Staffan - It looks good to me. Why is the bug marked closed though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen staffan.lar...@oracle.com wrote: And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen staffan.lar...@oracle.com wrote: The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan -- Keith McGuigan @kamggg kmcgui...@twitter.com
Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen staffan.lar...@oracle.com wrote: It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen staffan.lar...@oracle.com wrote: Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can’t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan kmcgui...@twitter.com wrote: Hi Staffan - It looks good to me. Why is the bug marked closed though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen staffan.lar...@oracle.com wrote: And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen staffan.lar...@oracle.com wrote: The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan -- Keith McGuigan @kamggg kmcgui...@twitter.com
Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
On 25/04/2014 17:36, Staffan Larsen wrote: Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ http://cr.openjdk.java.net/%7Esla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). I just ran into the build issue a few minutes ago. From a quick scan of the patch then it looks to be anti-delta so I think it's good. -Alan
Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
Thanks Joe - fix has been pushed. (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). /Staffan On 25 apr 2014, at 18:43, Joe Darcy joe.da...@oracle.com wrote: Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen staffan.lar...@oracle.com wrote: It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen staffan.lar...@oracle.com wrote: Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can’t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan kmcgui...@twitter.com wrote: Hi Staffan - It looks good to me. Why is the bug marked closed though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen staffan.lar...@oracle.com wrote: And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen staffan.lar...@oracle.com wrote: The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan -- Keith McGuigan @kamggg kmcgui...@twitter.com
Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
what's wrong with pushing them to jdk9/hs-rt? We did this a couple of weeks ago with Erik (Gahlin) changes, it might disrupt nightly, as we still do not have the JPRT changes in place, but that was the agreement we have for jdk9: tightly coupled changes should be pushed through the hotspot repos. had that been pushed this week there, it would be in jdk9/dev next Tuesday Alejandro On 4/25/2014 10:46 AM, Staffan Larsen wrote: Thanks Joe - fix has been pushed. (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). /Staffan On 25 apr 2014, at 18:43, Joe Darcy joe.da...@oracle.com wrote: Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen staffan.lar...@oracle.com wrote: It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen staffan.lar...@oracle.com wrote: Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can’t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan kmcgui...@twitter.com wrote: Hi Staffan - It looks good to me. Why is the bug marked closed though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen staffan.lar...@oracle.com wrote: And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen staffan.lar...@oracle.com wrote: The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan -- Keith McGuigan @kamggg kmcgui...@twitter.com -- Alejandro
Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on all platforms
In this case I think it would have worked ok since the dependency was from jdk - hotspot. If the dependency was the other way (or both ways), then such a push would break nightly testing in hotspot since that testing picks up the latest promoted JDK (instead of the JDK that is in the same forest). This is broken, IMO, and there is work in progress on fixing it. /Staffan On 25 apr 2014, at 19:04, Alejandro E Murillo alejandro.muri...@oracle.com wrote: what's wrong with pushing them to jdk9/hs-rt? We did this a couple of weeks ago with Erik (Gahlin) changes, it might disrupt nightly, as we still do not have the JPRT changes in place, but that was the agreement we have for jdk9: tightly coupled changes should be pushed through the hotspot repos. had that been pushed this week there, it would be in jdk9/dev next Tuesday Alejandro On 4/25/2014 10:46 AM, Staffan Larsen wrote: Thanks Joe - fix has been pushed. (I will now retreat to a dark place and grumble over the impossibility of pushing coordinated changes). /Staffan On 25 apr 2014, at 18:43, Joe Darcy joe.da...@oracle.com wrote: Approved! -Joe On 04/25/2014 09:36 AM, Staffan Larsen wrote: Here is an anti-delta for the broken push. I prepared it using “hg backout”. webrev: http://cr.openjdk.java.net/~sla/8041948/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8041948 If I can get this reviewed quickly I can push the fix soon (and I will spend the weekend in shame). Thanks, /Staffan On 25 apr 2014, at 18:24, Staffan Larsen staffan.lar...@oracle.com wrote: It looks like a completely messed this up by not pushing the hotspot parts first and now I have broken the build in jdk9-dev. Should I push an anti-delta of the patch? I can prepare a review of it in a moment. /Staffan On 25 apr 2014, at 17:16, Staffan Larsen staffan.lar...@oracle.com wrote: Thanks Keith! As far as I can tell there was no good reason for making the bug Confidential, but I can’t undo it. Sorry about that. /Staffan On 25 apr 2014, at 17:02, Keith McGuigan kmcgui...@twitter.com wrote: Hi Staffan - It looks good to me. Why is the bug marked closed though? On Fri, Apr 25, 2014 at 8:56 AM, Staffan Larsen staffan.lar...@oracle.com wrote: Still looking for a Review of this change. Thanks, /Staffan On 7 apr 2014, at 21:19, Staffan Larsen staffan.lar...@oracle.com wrote: And the links: bug: https://bugs.openjdk.java.net/browse/JDK-8033104 webrev: http://cr.openjdk.java.net/~sla/8033104/webrev.00/ Sorry about that, /Staffan On 7 apr 2014, at 20:08, Staffan Larsen staffan.lar...@oracle.com wrote: The problem here is that the code for finding local VMs is not looking for the data in the correct place. When a JVM is started it will create the perf-data file in a user-specific directory inside /tmp (*). The code in the JDK (PerfDataFile.java) that lists all active JVMs looks for the user-specific directory inside java.io.tmpdir. If a user sets -Djava.io.tmpdir on the command line, the code in PerfDataFile will look in the wrong place. (*) It's a little bit more complex. /tmp is used on Linux and Solaris. On OS X and Windows, there are user-specific temp directories that should be used, and so the VM queries the OS for these paths. The solution would be for PerfDataFile to use the same locations as the VM creates them in. The simplest way to guarantee that the same directory is used is to ask the VM to provide the location. Thus I have introduced a new JVM_ function: JVM_GetTemporaryDirectory. (Since this change touches both hotspot and jdk repos I will submit the hotspot part first under a different bug id (provided that the review goes well)). The newly added test starts two VM with all possible combinations of setting and not setting java.io.tmpdir to verify that the mechanism is indeed not looking at that variable. I also removed an if-statement in BasicTests.java which would have found this issue a long time ago had it not been there. Thanks, /Staffan -- Keith McGuigan @kamggg kmcgui...@twitter.com -- Alejandro
