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 >
