[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Urgent: Broken build. Re: RFR: 8033104 sun/jvmstat/monitor/MonitoredVm/CR6672135.java failing on
From:       Staffan Larsen <staffan.larsen () oracle ! com>
Date:       2014-04-25 17:15:13
Message-ID: 837FBCA9-1047-4689-952C-CA28B3AADAEF () oracle ! com
[Download RAW message or body]

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.murillo@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.darcy@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.larsen@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.larsen@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 <kmcguigan@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.larsen@oracle.com> wrote: Still looking for a Review of this \
> > > > > > > change. 
> > > > > > > Thanks,
> > > > > > > /Staffan
> > > > > > > 
> > > > > > > On 7 apr 2014, at 21:19, Staffan Larsen <staffan.larsen@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.larsen@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
> > > > > > > kmcguigan@twitter.com
> 
> -- 
> Alejandro
> 


[prev in list] [next in list] [prev in thread] [next in thread]